Your deal and firm data
What EQUIRE stores from your documents, what your organization accumulates across deals, and the order in which both feed the DCF.
Everything on this page belongs to your organization. It is created by your uploads and your decisions, it is scoped to your organization, and it is never pooled into the shared market data described elsewhere in this section. See Data isolation for the boundary itself.
Your deal record
Extracted from your documents
One canonical record per deal holds what the extraction pipeline read out of your source documents:
- Property attributes: type, address, size, year built, and the rest of the physical record.
- Rent roll and lease terms: tenant by tenant, with suite inventory.
- Operating statement: the T-12 income and expense lines.
- Debt terms where a loan document was supplied.
- Unresolved conflicts between documents, carried inside the same record rather than filed separately, so a disagreement between the OM and the rent roll travels with the field it affects.
Every field carries the document it came from and a verification state. That is what makes the provenance indicators in Rent roll and financial data possible, and what a [Source: ...] citation in an IC memo resolves against.
Source documents
The files themselves, their classification and processing status, and a searchable text index built from their contents. searchDocuments runs a similarity search over that index and returns the passage, not a summary of it. The normalized deal record is searchable through the same tool and is labelled as the deal record rather than as one of your documents, because it is reconciled data and not any single contract's own words.
Records your work creates
| Record | What it holds |
|---|---|
| Valuation model | Saved assumptions with provenance, scenarios, tenant overrides, capital stack, and cached returns |
| Review queue and decisions | Every accept, correct, attest, and risk-accept, durably, with who decided |
| Open findings | Extraction and validation issues still outstanding |
| Risk register and deal health | The computed register and the issues behind the health score |
| Market research runs | The run ledger, its sources, the confirmed scope, and the resulting figures |
| Comparables | Comps you saved to the deal |
| Screening runs and briefs | Infinity run history and each run's verdict |
| Deliverables and IC memo | Generated sections and their version history |
| Notebook, tasks, and audit trail | Analyst entries, task state, and the record of who did what |
The released snapshot
When you release deal data, EQUIRE writes an immutable snapshot: the canonical record as it stood, the assumption ledger behind it, and the release gate result. Preliminary work continues against the live record. Anything reading released data reads the snapshot, which is why an export can state its basis honestly months later. See Review and release.
Your firm's memory
Organization-scoped records that outlive any one deal: fund defaults and target returns, the approved house view, reviewed memory patterns, closed and passed deal outcomes, the Context Vault and its searchable contents, and an organization-wide search corpus.
How these are authored, governed, and promoted is covered in Firm Memory. What matters for this catalog is where they enter the analysis, which is next.
What feeds the DCF, and in what order
The DCF engine derives returns from assumptions rather than storing its own copy of them. Every persisted assumption carries a source, and when two sources supply the same field a fixed precedence decides which one the model uses. The order is the point.
Your own entry wins. A value you typed into the model outranks every other source, including the documents. An analyst who overrides a figure is making a decision, and the model records it as one.
Document values come next. Figures extracted from your source documents, each carrying the document it was read from.
Analyst-assigned and accepted-research values follow. Values assigned through analyst workflows, then figures you accepted from a market research proposal.
Fund defaults sit beneath those. Your organization's configured defaults for the property type and class, where your organization has enabled default seeding.
Inference fills what is left, narrowly. AI inference is the last resort, used only where nothing above it supplied a value. Keys your organization has resolved are excluded from inference entirely, so a failed inference call can never replace firm policy with a generic benchmark.
Every assumption displays its source, so you can see which rung any figure came from rather than inferring it.
Two things sit deliberately outside that ladder:
The house view is an overlay, not a source. Where your organization has enabled it, it is evaluated when you read the model and shown as a difference against your firm's conviction. It writes no assumption and changes no scenario.
Market research proposes and never applies. Findings from market evidence arrive as proposals you accept or decline in Valuation. Nothing sourced from research enters the model on its own.
The expense side of the model comes from the extracted operating statement rather than from any separate financial ledger, and property tax is re-priced at read time when a reassessment applies.
Related
- Data isolation for tenant boundaries, roles, and export controls.
- Privacy and deletion for what closing an account removes.
- Processing and AI data for sub-processors and model training posture.
Last updated on