# Getting Started (/docs/getting-started)
EQUIRE takes a property document and produces a structured deal record: extracted financials, a tenant roster, resolved conflicts, and a pre-populated DCF model. By the end of this page you will have a deal workspace ready for valuation work.
## Before You Start [#before-you-start]
* An active EQUIRE account with an organization configured
* At least one source document — an OM, rent roll, or T-12 financials in PDF, XLSX, DOCX, or CSV format
* Permission to create deals in your organization (granted by default to all org members)
## Walk Through [#walk-through]
### Create a Deal [#create-a-deal]
From the deals list, open the sidebar create menu and select `New Deal`. The dialog that appears — titled `Create New Deal` — asks for the property name, asset type, and asking price. Fill those in and confirm. EQUIRE creates a deal workspace with all tabs pre-configured and lands you on the Overview.
### Upload Documents [#upload-documents]
Navigate to the `Documents` tab. Drag files anywhere onto the page or use the upload area to browse. EQUIRE accepts PDF, Excel (`.xlsx`), Word (`.docx`), and CSV files. Upload the OM, rent roll, and T-12 in one pass — there is no required order.
### Wait for Extraction [#wait-for-extraction]
Processing typically completes in under 90 seconds per document, depending on file size. EQUIRE auto-classifies each document: OMs, rent rolls, and T-12 statements are identified and routed to the appropriate extraction pipeline without manual tagging. A status indicator on the `Documents` tab updates as each file moves through the pipeline.
Scanned PDFs that are image-only (no embedded text layer) require additional OCR processing and may take longer. Searchable PDFs process fastest.
### Review Extracted Data and Resolve Conflicts [#review-extracted-data-and-resolve-conflicts]
Open the `Review` tab. EQUIRE surfaces every item that requires attention: extracted values with low confidence, fields missing from source documents, and conflicts where two documents disagree on the same value.
Every extracted value links to its source document and page. Selecting a conflict shows both candidates with their provenance so you can choose the correct value or enter a manual override. Resolved items are cleared from the queue; unresolved items remain visible until addressed.
For a granular view of all extracted fields, the `Extracted Data` tab shows the full schema with source attribution and verification state for each value.
### Open the Valuation Tab and Build the Model [#open-the-valuation-tab-and-build-the-model]
Navigate to `Valuation`. If no model exists yet, the blank state shows a `Start Valuation Wizard` button. The wizard runs three steps — Property Details, Investment Params, and Build Model — and uses your extracted data to pre-populate assumptions. EQUIRE runs market research and risk scoring as part of the build, then opens the live DCF dashboard with base, upside, and downside scenarios ready to explore.
If a model already exists (for example, a colleague built it earlier), the dashboard opens directly.
### Generate the IC Memo or a Deliverable [#generate-the-ic-memo-or-a-deliverable]
Navigate to `IC Memo` to draft an Investment Committee memorandum. Select the sections to include; EQUIRE drafts each section from your deal data. Review and edit inline before finalizing.
For external outputs, open `Deliverables` and choose a format: executive summary, risk assessment, or lender package. Each deliverable is audience-scoped — IC internal, LP, lender, or broker — and exports to Word, Excel, or PowerPoint.
### Invite Teammates [#invite-teammates]
Navigate to `Team` to add colleagues to this deal. Each team member is org-scoped and will see only deals within your organization.
## Where to Go Next [#where-to-go-next]
### Document Ingestion [#document-ingestion]
For a detailed look at how EQUIRE processes documents and resolves extraction conflicts, see [Document Ingestion](/docs/workflows/document-ingestion).
### AI Trust and Provenance [#ai-trust-and-provenance]
To understand how extracted values carry source provenance and confidence through the platform, see [AI Trust and Safety](/docs/ai-assistant/trust-and-safety).
### Data Isolation [#data-isolation]
For information on how deal data is isolated between organizations, see [Data Isolation](/docs/security/data-isolation).
---
# Introduction (/docs)
EQUIRE is a deal management workspace built for institutional CRE acquisitions teams. You ingest source documents — offering memoranda, rent rolls, T-12 operating statements, lease abstracts — and EQUIRE extracts structured deal data, runs it through a multi-scenario DCF engine, and surfaces the outputs your IC needs to make a decision. The system carries source provenance through every step, so each assumption traces back to a document or a user override.
## What EQUIRE Produces [#what-equire-produces]
Each deal progresses through a defined artifact chain:
* **Extracted deal record** — property attributes, rent roll, T-12 financials, and debt terms pulled from uploaded documents with field-level confidence scores and conflict flags
* **DCF model** — multi-scenario (base, upside, downside) discounted cash flow with tenant-level cash flow schedules, sensitivity matrices, and assumption audit trail
* **IC memo** — a 12-section Investment Committee memorandum covering deal thesis, risk factors, lease-by-lease analysis, debt structure, and recommendation
* **Deliverables** — formatted exports for different audiences: executive summaries, risk assessments, loan packages, and comparable sales analyses in Word, Excel, and PowerPoint
## How It Fits a Deal [#how-it-fits-a-deal]
1. **Source** — [Prospecting](/docs/workflows/prospecting) and mandates, or add deals directly after intake.
2. **Ingest** — Upload the OM, rent roll, and financial statements. EQUIRE routes each document through the extraction pipeline and populates the deal record.
3. **Review** — Examine flagged conflicts between documents, resolve discrepancies, and clean the [Rent roll & financial data](/docs/workflows/rent-roll-financials) surfaces. Every field shows its source.
4. **Underwrite** — Open the [DCF model](/docs/workflows/valuation). Adjust assumptions, run scenarios, inspect the sensitivity matrix. The model recalculates in real time.
5. **Deliver** — Generate the [IC memo](/docs/workflows/ic-memo) and export [Deliverables](/docs/workflows/deliverables) for each audience — IC internal, LP, lender, or broker.
## Where to Start [#where-to-start]
Ingest your first document and set up a deal workspace.
How EQUIRE extracts data from OMs, rent rolls, and financials.
Clean tenancy and T-12 inputs before you finalize the model.
Audience-specific Word, PDF, and PowerPoint packages from one source of truth.
How AI outputs are bounded, audited, and never auto-applied.
Tenant data boundaries, RLS enforcement, and export controls.
---
# Specialist Agents (/docs/ai-assistant/agents)
{/* LEGAL REVIEW REQUIRED before merge - see docs/documentation-page/docs-site-plan.md legal review status */}
The EQUIRE AI is not one model with one prompt. It is a set of **specialist agents**, each focused on a phase of the deal lifecycle, each with its own prompt, tool set, and model tier. Specialists are invoked from the workflow surfaces that need them — intake fires when a deal is created or an email comes in, lease fires when a lease document is processed, and so on. The chat assistant has access to the same expertise via the per-mode tool sets described in [Chat modes](/docs/ai-assistant/chat-modes).
## How Specialists Fit In [#how-specialists-fit-in]
Every specialist follows the same contract: it returns structured output, it never writes to deal data without your approval, and it is tagged with a feature so its usage is attributable in your AI usage reports. None of the specialists block — they produce a draft, a checklist, or a recommendation, and the deal team decides what to act on.
Where a specialist needs to gather evidence (research and prospect enrichment), it runs a bounded tool loop with a step limit. Where it just analyzes text (intake, lease, legal, diligence, debt, closing), it runs a single structured-output pass.
## Document Specialists [#document-specialists]
These six agents read deal documents and produce structured analysis. They run in the document processing pipeline and are also surfaced through chat tools when relevant.
### Intake Agent [#intake-agent]
**Purpose** — Screens new deals from offering memorandums, teasers, and broker emails. Produces a mandate-fit score (0–100), property and financial summaries, risk flags, and a recommendation: pass, quick look, or full underwrite.
**Inputs** — Raw email or document text plus optional PDF / Excel attachments and the fund's investment criteria (target property types, markets, deal size, return ranges, leverage).
**Output** — A structured intake recommendation with property details, deal economics, sponsor and broker information, mandate-fit drivers and concerns, and missing-data flags.
**When it runs** — On `POST /api/deals/intake` when you create a deal, and on inbound email through the intake webhook.
**Model** — Sonnet (critical tier) by default; configurable to Haiku for high-volume screening. Feature tag: `document-processing`.
### Lease Agent [#lease-agent]
**Purpose** — Reads the rent roll and lease abstracts to produce portfolio-level intelligence: WALT, near-term rollover risk, non-standard clauses, options (renewal, expansion, termination), cross-tenant rent and escalation comparison.
**Inputs** — Lease text (PDFs or extracted) plus optional market context.
**Output** — Per-tenant abstracts, options inventory, rollover-risk summary, non-standard-terms list with deviation risk, and the top recommendations for the underwriting team.
**When it runs** — During document processing on lease and rent roll uploads.
**Model** — Sonnet by default; configurable to Haiku. Feature tag: `document-processing`.
### Legal Agent [#legal-agent]
**Purpose** — Reviews purchase and sale agreements. Extracts key clauses across 13 categories (price, earnest money, contingencies, reps and warranties, etc.), maps title exceptions, generates a first-pass issue list and closing checklist, and flags deviations from an institutional playbook.
**Inputs** — PSA text plus optional title report and survey.
**Output** — PSA summary, key clauses, title exceptions with impact and recommendations, issue list, closing checklist, and a list of deviations from market.
**When it runs** — During the diligence and closing phases when PSA documents are uploaded.
**Model** — Sonnet (critical) by default; configurable to Haiku. Feature tag: `document-processing`.
### Diligence Agent [#diligence-agent]
**Purpose** — Coordinates diligence. Maintains the DD checklist, tracks document request status, generates escalation-tiered follow-up messages, and supports the Diligence Command Center's phase-gate decision: can the deal advance, what blocks it, and who owns the next action?
**Inputs** — Deal context, current phase, property type, and the existing DD item state.
**Output** — Checklist state, Phase Blockers, material risks, outstanding requests, follow-up drafts (with escalation level), findings and red flags, and a phase-readiness assessment.
**When it runs** — When the Diligence Command Center runs a diligence scan, when phase changes, or when a user explicitly asks for a DD update through chat.
**Model** — Sonnet (chat tier) by default — DD is orchestration, not deep analysis. Feature tag: `document-processing`.
### Debt Agent [#debt-agent]
**Purpose** — Builds the lender package and analyzes financing strategy. Produces a property / financial / tenant / market / sponsor summary, compares term sheets across seven lender types (bank, life co, CMBS, agency, bridge, debt fund, other), runs DSCR and LTV sensitivity, and drafts anticipated lender Q\&A.
**Inputs** — Deal context plus optional target lender types and existing term sheets.
**Output** — Lender package, term-sheet comparison, sensitivity scenarios (rate stress ±100–300 bps, NOI stress ±5–15%), Q\&A by category, and a recommendation with alternatives.
**When it runs** — During financing and IC approval workflows.
**Model** — Sonnet by default. Feature tag: `document-processing`.
### Closing Agent [#closing-agent]
**Purpose** — Coordinates the closing. Manages the closing checklist with blocking flags, verifies document completeness, reconciles prorations (taxes, insurance, CAM, rents) and final economics, and generates post-close tasks and lessons learned.
**Inputs** — Deal context plus an optional closing date.
**Output** — Closing checklist, status summary, document completeness check, prorations with buy- and sell-side credits, final cash-to-close reconciliation, post-close tasks with deadlines, and lessons learned.
**When it runs** — When transitioning to the closing phase or generating a closing statement.
**Model** — Sonnet by default. Feature tag: `deliverable`.
## Research Specialists [#research-specialists]
These two agents run multi-step tool loops to gather evidence rather than analyze a fixed document.
### Corbis Research Agent [#corbis-research-agent]
**Purpose** — Performs market research via the Corbis MCP server. Pulls market data, academic papers, economic indicators, and web search results to support DCF assumptions, narrative generation, or ad-hoc analyst questions.
**Inputs** — A research prompt plus a configuration that picks a mode: market, academic, economic, or comprehensive.
**Output** — A structured research report with title, executive summary, key findings (each tagged with source and confidence), data points (metric, value, context), and the full source list.
**Tools** — Corbis MCP tools grouped by mode. Runs as a bounded tool loop (up to 12 steps).
**When it runs** — From the valuation analyst pipeline, from research-driven chat queries, and from origination flows that need market context.
**Requirements** — `CORBIS_MCP_TOKEN` must be configured at the platform level. Without it, the agent returns a clear error rather than guessing.
**Model** — Sonnet (chat tier) by default; configurable to Opus (critical). Feature tag: `corbis-research`.
### Prospect Research Agent [#prospect-research-agent]
**Purpose** — Enriches prospect records during sourcing. Gathers corroborating sources via Tavily, attaches them durably to the prospect, and optionally produces structured findings — owner / debt checks, market snapshots, outreach drafts, or red-team challenges to the mandate fit.
**Inputs** — A prospect search result, a sourcing profile (SearchProfile), the requested action, and the org and user IDs.
**Output** — A markdown summary, durable source attachments (written to `prospect_sources`), structured findings with confidence, remaining gaps, an overall confidence score, and recommended next actions.
**Tools** — Tavily search and a `listExistingSources` lookup that runs as the first step (so the agent never duplicates a source you already have).
**When it runs** — On `POST /api/sourcing/results/[resultId]/agent-runs` during the prospect research workflow.
**Model** — Haiku (fast) for market snapshots; Sonnet for everything else. Feature tag: `origination`.
## How the Assistant Picks a Specialist [#how-the-assistant-picks-a-specialist]
The assistant decides which specialist handles a request based on the surface that originated it, not from a single global router:
* The **intake agent** is invoked by the intake routes and the inbound email webhook. It does not run from the chat assistant.
* The **lease, legal, debt, and closing agents** run inside the document processing pipeline when their target document type is uploaded. The chat assistant can summon their analysis through tool calls but does not re-run them on every message.
* The **diligence agent** runs from the diligence dashboard and is also reachable through deal-mode chat tools.
* The **Corbis research agent** runs from valuation analyst steps, IC memo generation, and on-demand research questions.
* The **prospect research agent** runs from the sourcing workflow when you request enrichment on a search result.
There is also an internal agent registry and routing helper that scores user intent against specialist keywords, deal phase, and capabilities. It is plumbing for future chat routing rather than a user-facing feature today — when a chat message could be answered by any specialist's tools, the chat backend exposes those tools directly rather than handing off to a separate agent process.
## Where to Go Next [#where-to-go-next]
* For the full per-mode tool catalog the chat assistant exposes, see [Tool reference](/docs/ai-assistant/tools-reference).
* For which model handles which feature tag and what attribution looks like, see [Models and routing](/docs/ai-assistant/models).
* For provenance, hallucination handling, and human-in-the-loop checkpoints across all specialists, see [Trust and safety](/docs/ai-assistant/trust-and-safety).
* For implementers: agent registry and factories live under `src/lib/ai/agents/` — confirm AI SDK agent/stream APIs via [AI SDK 7 docs](https://ai-sdk.dev/v7/docs) and `vercel:ai-sdk`, not this product page.
---
# Chat Modes (/docs/ai-assistant/chat-modes)
{/* LEGAL REVIEW REQUIRED before merge - see docs/documentation-page/docs-site-plan.md legal review status */}
The floating chat widget runs in one of three **modes** depending on where you open it. Each mode has its own backend route, system prompt, tool set, and default web toggles. The widget detects mode automatically from the page you are on; you do not switch it manually.
## The Three Modes at a Glance [#the-three-modes-at-a-glance]
| Mode | Where it appears | Backend route | Primary purpose |
| --------------- | ------------------------------------------------- | -------------------------------------- | ---------------------------------------- |
| **Deal** | Inside any deal workspace tab (`/deals/[id]/...`) | `POST /api/assistant/chat` | Analyze, draft, and update one deal |
| **Portfolio** | `/deals` and other org-level pages | `POST /api/assistant/portfolio-chat` | Compare and analyze across the pipeline |
| **Prospecting** | `/prospecting` and mandate dashboards | `POST /api/assistant/prospecting-chat` | Triage prospects against active mandates |
If a page does not pass a mode prop, the widget does not render. On deal routes the widget remounts with a fresh state when the `dealId` changes — there is no cross-deal leakage in conversation history.
## Deal Mode [#deal-mode]
Deal mode is the most capable surface and the only one with write access to deal data. It is bound to the current deal: the system prompt includes the deal name, visible page data, any custom deal-level instructions, and any items you have @-mentioned.
### Tools Available [#tools-available]
Tools are organized by domain. A broader domain reference lives in [Tool reference](/docs/ai-assistant/tools-reference); below is the high-level coverage.
* **Schema, Review, and tenants** — read deal data, read the canonical Review queue, update fields, resolve conflicts, act on source review and field check items, add or delete tenants, update property info, mark documents reviewed
* **Documents** — search documents (`searchDocuments`, deal-scoped only), list, reprocess, delete
* **Valuation** — read the model, run sensitivity, update assumptions and OpEx, export to Excel
* **Health** — read summary and issues, create or resolve issues, run on-demand health analysis
* **Research and market data** — Gateway web search (when enabled), market reports, papers, narratives, economic conditions, comparable properties (deal mode is the only place comps are available)
* **Portfolio comparison from inside a deal** — `compareDealMetrics`, `searchAcrossDeals`
* **Tasks and workflow** — deal task CRUD, transaction-graph queries, intake / lease / legal / diligence / debt / closing specialists
* **Memory** — read the deal memory brief and notebook, search prior notes, compare the deal to reviewed institutional patterns, and propose approval-gated memory entries
* **Overview JSON Render (Overview tab only)** — list saved custom dashboard widgets, create new widgets from explicit creation prompts or the Overview dashboard button, and edit or rebuild existing widgets by id from explicit edit prompts. Create and edit persist immediately (no Allow / Deny). Lease rollover plus DSCR timeline requests use the deterministic `system-lease-rollover-dscr` template.
### Approval-Gated Writes [#approval-gated-writes]
The following high-impact tools require explicit Allow / Deny approval before they run:
* `actOnReviewItem`
* `updatePropertyInfo`
* `updateField`
* `addTenant`
* `addOperatingStatement`
* `markDocumentsReviewed`
* `resolveConflict`
* `deleteDocument`
* `deleteTenant`
* `deleteSuiteInventory`
* `reprocessDocument`
* `resolveAllConflicts`
* `updateAssumption`
* `updateTenantAssumption`
* `updateOpex`
* `updateValuationParams`
* `updateCapitalStack`
* deal work-queue mutations such as `createDealTask`, `updateDealTask`, `completeDealTask`, `snoozeDealTask`, and `scheduleTaskReminder`
* `recordNotebookEntry`
* `proposeInstitutionalMemoryPattern`
* `recordHistoricalDealOutcome`
When two or more approvals are pending at once, a bulk approval bar appears so you can review and confirm them in batch. Single approvals always show inline.
### Web Toggles [#web-toggles]
Deal mode is the only mode where all four web-tool categories are available:
* **Web search** — Vercel AI Gateway Parallel Search (general web search when the toggle is on)
* **Market data** — metro economic and commercial-market metrics (cap rates, occupancy, rents, demographics, employment) plus national macro, across \~1,000 US metros
* **Research** — academic papers and structured research sources
* **Comps** — comparable-property discovery (deal mode only)
All four are on by default in deal mode. Turn one off and the assistant suspends those tools for the rest of the session — the model is informed in the system prompt that the category is unavailable.
### @-Mentions [#-mentions]
Type `@` to autocomplete:
* **Documents** in the current deal (by name)
* **Team members** in the deal team (by name and role)
The mention text appears in your message for readability, but the structured reference is sent separately to the backend so the assistant can ground its response on the correct artifact without parsing the chat string.
### Persistence [#persistence]
Deal-mode conversations are saved per deal in your browser (`equire-chat:v1:{dealId}`). Server-side persistence is per-session — when you start a new conversation, a new session ID is generated. Switching deals unmounts the widget and resets state.
## Portfolio Mode [#portfolio-mode]
Portfolio mode is analysis-first. It is for cross-deal analysis: comparing pipeline metrics, finding deals that match a query, surfacing aggregate analytics, and asking what the organization has learned across prior deals. It has no document-chunk search and no direct deal-field write tools.
### Tools Available [#tools-available-1]
* **Portfolio** — `listAllDeals`, `getDealSummary`, `compareDealMetrics`, `searchAcrossDeals`, `getPipelineAnalytics`
* **Search and market** — web search, market data, market trends, papers, metric definitions
* **Memory** — read institutional patterns, compare a deal profile to reviewed memory, retrieve deal notebooks when a deal id is known, and propose approval-gated memory entries
### Approval Gates [#approval-gates]
Memory write tools such as `recordNotebookEntry`, `proposeInstitutionalMemoryPattern`, and `recordHistoricalDealOutcome` require Allow / Deny approval before they run. Portfolio mode does not expose direct field, tenant, document, or valuation mutation tools.
### Web Toggles [#web-toggles-1]
Web search, market data, and research are on by default. Comps is hidden — it is a property-level concept and only useful in a deal context.
### @-Mentions [#-mentions-1]
Not supported. Portfolio mode has no per-deal documents or team to mention.
### Persistence [#persistence-1]
A single global portfolio conversation is saved to your browser (`equire-chat:v1:portfolio`). Unlike deal mode, there is no per-session split.
## Prospecting Mode [#prospecting-mode]
Prospecting mode is for triaging the prospect inbox against your active mandates. It can read mandate state and prospect sources, generate briefs, and queue up snooze / tag actions for your approval.
### Tools Available [#tools-available-2]
* **Prospecting reads** — `listMandates`, `searchProspects`, `getProspectBrief`, `listProspectSources`, `compareProspects`, `searchMandateMarkets`, `getMandateHealth`, `getProspectOwnerPath`, `listSnoozedProspects`, `getDigestPreview`, `prepareScreeningMemoExport`
* **Prospecting writes (approval-gated)** — `snoozeProspect`, `addProspectTag`, `dismissProspect`, `attachProspectSourceUrl`, `updateProspectSource`, `runProspectResearchAction`, `convertProspectToDeal`, `runSourcingProfile`, `launchScoutReview`, `dispatchBackgroundJob`
* **Search and market** — web search, market data, papers, market trends, metric definitions
### Approval Gates [#approval-gates-1]
Prospecting write tools require Allow / Deny. As with deal mode, the bulk approval bar appears at two or more pending.
### Web Toggles [#web-toggles-2]
Web search, market data, and research are on by default. Comps is hidden by design — even if a stale client sends a comps flag in the request, the prospecting backend drops it before it reaches the model.
### Context the Assistant Sees [#context-the-assistant-sees]
In addition to the standard prompt, prospecting mode appends the current view filters: how many active mandates you have, how many prospects are in the ready state, and any readiness / source / tag filters in effect. This lets the assistant ask clarifying questions like "Do you want me to skip the dismissed prospects?" without you having to restate the filter.
### Persistence [#persistence-2]
A single global prospecting conversation is saved to your browser (`equire-chat:v1:prospecting`). Server-side persistence is org-scoped and not split per session.
## Cross-Mode Behaviors [#cross-mode-behaviors]
These behaviors are the same in every mode.
### Mobile Gestures [#mobile-gestures]
* **Pull down to close** — drag the panel down by 80px from normal size, or 120px from expanded size
* **Pull up to expand** — drag the panel up by 70px to switch to the larger preset
Gestures are touch-only; on desktop, use the resize handle or the close button.
### Resize Handle [#resize-handle]
Desktop only. The handle in the top-left corner is keyboard-accessible (`Tab` to focus, then `Enter` or `Space` to reset to the default size). Drag to resize within the size presets — the widget does not allow arbitrary widths so it can stay readable on every viewport.
### Empty State [#empty-state]
Each mode shows a contextual empty state with four suggested prompts. The suggestions reflect that mode's strengths — deal mode suggests deal analysis, portfolio mode suggests pipeline comparisons, prospecting mode suggests readiness and ownership questions.
### Bulk Approval Bar [#bulk-approval-bar]
When two or more approval-gated actions are pending, a bar appears above the input. You can clear them all in one action after reviewing. With a single pending approval, only the per-tool Allow / Deny is shown.
## Where to Go Next [#where-to-go-next]
* For the full list of tools available in each mode, see [Tool reference](/docs/ai-assistant/tools-reference).
* For how the assistant routes complex requests to specialist agents, see [Agents](/docs/ai-assistant/agents).
* For which model handles which mode and what data-handling guarantees apply, see [Models and routing](/docs/ai-assistant/models).
---
# Models and Routing (/docs/ai-assistant/models)
{/* LEGAL REVIEW REQUIRED before merge - see docs/documentation-page/docs-site-plan.md legal review status */}
EQUIRE runs every AI request through the **Vercel AI Gateway** when configured, with a direct-Anthropic fallback. Each workload is bound to a **model tier** (semantic alias) and a **feature tag** (workflow it originated from). Tier and tag together determine the exact model used, the data-handling guarantees applied, and how the request is attributed to your organization.
Gateway routing is **multi-provider** when a model passes compatibility gates (capabilities, Anthropic-only rules, and — when platform Zero Data Retention is on — Corbis ZDR overlay). Shipped defaults stay on the Claude family below; additional frontier models may appear as **opt-in pilots** (admin or per-run override), not as the platform auto-default.
## Model Tiers [#model-tiers]
The platform exposes five semantic aliases. Code calls a tier by name; the resolver picks the concrete model based on whether the Gateway is in play.
| Tier | Purpose | Gateway model | Direct fallback |
| -------------- | -------------------------------------------------------------------- | ----------------------------- | ------------------- |
| `chat` | General reasoning, deal Q\&A, drafting | `anthropic/claude-sonnet-4.6` | `claude-sonnet-4-6` |
| `fast` | Cheap classification, gap detection, simple summaries | `anthropic/claude-haiku-4-5` | `claude-haiku-4-5` |
| `critical` | Highest-stakes reasoning — IC memo critical sections, expert opinion | `anthropic/claude-opus-4.7` | `claude-opus-4-7` |
| `extraction` | Document extraction with long context (up to 64k tokens) | `anthropic/claude-sonnet-4.6` | `claude-sonnet-4-6` |
| `verification` | Lightweight second-pass verification of extracted values | `anthropic/claude-haiku-4-5` | `claude-haiku-4-5` |
Aliases let admins swap underlying models without touching feature code. Calling `chat` always returns the currently-blessed mid-tier model, even after a version bump.
### Gateway versus Direct Fallback [#gateway-versus-direct-fallback]
* **Gateway** (preferred) — used when `AI_GATEWAY_API_KEY` or a Vercel OIDC token is configured. Adds attribution, optional zero-retention (platform toggle), and unified routing across providers.
* **Direct Anthropic** — used when only `ANTHROPIC_API_KEY` is set. Same Claude models, but no Gateway-side attribution metadata; embeddings are not available on this fallback.
The platform does not silently mix providers on a single request. If you have only Anthropic configured, every request uses Anthropic; if the Gateway is configured, eligible requests use the Gateway.
## How Features Map to Tiers [#how-features-map-to-tiers]
Every workload that calls the AI is tagged with a **feature** (from a closed enum). The tag drives both attribution and the default tier. Admin overrides (below) can change the model behind a feature without changing the tag.
### Chat Surfaces [#chat-surfaces]
| Feature tag | Default tier | Notes |
| ------------------- | --------------- | ---------------------------- |
| `chat` | `chat` (Sonnet) | Deal-mode chat assistant |
| `portfolio-chat` | `chat` (Sonnet) | Portfolio-mode chat |
| `mandate-dashboard` | `chat` (Sonnet) | Mandate-dashboard advisor |
| `digest` | `chat` (Sonnet) | Prospecting digest narrative |
### Documents and Extraction [#documents-and-extraction]
| Feature tag | Default tier | Notes |
| --------------------- | -------------------------------- | ---------------------------------------------------------------------- |
| `document-processing` | `extraction` then `verification` | Sonnet 64k for the extraction pass; Haiku 8k for the verification pass |
`document-processing` is the umbrella tag for the entire ingestion pipeline. Extraction and verification share the same tag so usage reports show one line for the workflow rather than splitting across passes.
### IC Memo [#ic-memo]
`ic-memo` mixes tiers section-by-section based on stakes:
* **Opus (`critical`)** — Executive Summary, Investment Thesis, Market Analysis, Risk Factors
* **Sonnet (`chat`)** — all other narrative sections
* **Haiku (`fast`)** — section classification and gap detection
The mix is fixed in code rather than configurable per memo, so every memo gets the same provenance posture. Admin overrides can swap the model under any tier without changing the section-to-tier mapping.
### Other Workflows [#other-workflows]
| Feature tag | Default tier | Notes |
| ------------------------- | ----------------- | ---------------------------------------------------------------------- |
| `expert-opinion` | `critical` (Opus) | Per-assumption expert commentary |
| `valuation` | `chat` (Sonnet) | Valuation analyst pipeline |
| `deal-health-coherence` | `chat` (Sonnet) | Tier-2 coherence analyzer |
| `deal-health-deep-scan` | `chat` (Sonnet) | Tier-3 deep scan |
| `research` | `chat` or `fast` | Sonnet for narrative, Haiku for filtering |
| `origination` | `chat` (Sonnet) | Origination AI advisor and prospect briefs |
| `organization-enrichment` | `chat` (Sonnet) | Org research cache |
| `corbis-research` | `chat` (Sonnet) | Corbis MCP research agent |
| `deliverable` | `chat` (Sonnet) | Deliverable drafting |
| `image-gen` | n/a | Image generation routes through a separate provider, not the LLM stack |
## Anthropic-Only Features [#anthropic-only-features]
A small set of features is restricted to Anthropic models even when the Gateway has alternatives configured:
* `document-processing`
* `extraction` (legacy alias retained for older usage rows)
* `deal-health-deep-scan`
These features rely on capabilities — native PDF vision, long-context caching, multi-step reasoning depth — that are currently best-served by Anthropic. If an admin tries to override one of these to a non-Anthropic model, the override is silently rejected and the default tier is used. The admin UI shows the same restriction so the constraint is visible up front.
## Additional frontier models (pilot) [#additional-frontier-models-pilot]
EQUIRE can route selected non-Claude models as **opt-in pilots** (admin feature override or per-run model picker). They are **not** the platform auto-default and must not be promoted to the platform-wide default without the promotion gate.
**Grok 4.5** (`xai/grok-4.5`) is the current frontier pilot: listed on the Gateway, surfaced in Admin Model Config via frontier pilots, and selectable when platform ZDR is off. With ZDR on, Grok appears with a `not ZDR` badge but cannot be saved as an override — the Gateway has no ZDR route for this model (`NoZdrProvidersError`), and Corbis marks `gatewaySupportsZeroDataRetention=false`. Never used for Anthropic-only extraction/document-processing/deal-health-deep-scan. Server-side reasoning effort is pinned for cost and latency; UI streams set `sendReasoning: false` (AI SDK 7 default is `true`) — effort pin does **not** stream chain-of-thought to the UI.
## Admin Overrides [#admin-overrides]
Platform admins can override the model behind any feature tag without changing application code. Overrides live in Supabase (`credeals.platform_ai_config`) and are read with a 60-second in-memory cache.
The admin UI draws candidates from the **live Gateway catalog**, filtered by feature compatibility (capability tags, ZDR policy when enabled, and Anthropic-only rules). Frontier pilots (e.g. Grok 4.5) stay visible under ZDR-on with a `not ZDR` badge; saving a non–ZDR-compliant override returns **409** until platform ZDR is off or the model gains a ZDR route. Toggle ZDR at **Admin → Model Config → Gateway controls → Zero Data Retention** (`/admin?tab=model-config`). Clearing an override returns the feature to its default tier on the next cache refresh.
Override changes take effect within 60 seconds; there is no application restart required.
## Gateway Attribution [#gateway-attribution]
Every AI call goes out with attribution metadata so usage reports, audit trails, and cost analytics line up with the workflow that triggered the call.
### What Gets Sent [#what-gets-sent]
* **`feature`** — the workflow tag (e.g. `ic-memo`, `valuation`, `chat`)
* **`org`** — your organization ID, omitted only for system-level calls with no org context
* **`user`** — the user who initiated the action, when available
* **`zeroDataRetention`** — follows the platform ZDR toggle (`credeals.platform_ai_settings.gateway_zero_data_retention`); default on, super-admin can disable. Document-processing may omit ZDR when prompt-cache is enabled for that feature.
### Telemetry Allowlist [#telemetry-allowlist]
EQUIRE writes telemetry events to its own observability layer alongside the Gateway. The allowed metadata keys are limited to a closed set including `feature`, `orgId`, `surface`, `documentType`, `documentId`, `attachmentCount`, `pdfPageCount`, `tenantCount`, `confidence`, `verificationMode`, `readiness`, `mandateCount`, `steps`, and `hitStepLimit`. Anything outside the allowlist is dropped before being recorded.
Crucially, prompts and completions are **never** persisted in telemetry. `recordInputs` and `recordOutputs` are hard-coded to `false`.
## Zero Data Retention [#zero-data-retention]
When platform ZDR is **on** (code/env default ON; super-admins toggle at **Admin → Model Config → Gateway controls → Zero Data Retention** — currently **off** in the shared platform as of 2026-07-09 for Grok pilots), eligible Gateway requests carry `zeroDataRetention: true`, which the Gateway honors by short-circuiting request-body logging or training-set capture on upstream providers that expose a ZDR route.
When ZDR is **off**, requests omit the ZDR flag and non–ZDR-qualified models (e.g. `xai/grok-4.5`) can be selected for pilot overrides. Models without a Gateway ZDR route or with Corbis `gatewaySupportsZeroDataRetention=false` cannot pass ZDR-on compatibility checks regardless of catalog presence.
In practical terms (when ZDR is on and the model is ZDR-qualified):
* Prompts and completions are not retained by the Gateway after the response is delivered.
* They are not used to train any model.
* They are not visible in cross-org analytics.
EQUIRE's own database stores the **outputs** of AI work (extracted fields, IC memo text, valuation assumptions, audit log entries) where they are needed for the product. Those outputs live under your org's RLS scope and are deleted when you delete the underlying deal or scheduled account-level deletion runs.
## Timeouts [#timeouts]
Every AI call carries an explicit timeout drawn from a small set of presets. Total timeout is the upper bound for the whole call; chunk timeout is the maximum gap between streamed tokens before the call is aborted.
| Preset | Total | Chunk | Used for |
| ----------------- | ----- | ----- | ------------------------------------------------------------------------------------------ |
| `quick` | 25s | 8s | Lightweight classification, gap checks |
| `standard` | 90s | 20s | Most chat, narrative, and deal-tool calls |
| `verification` | 90s | 20s | Haiku verification pass on extracted documents |
| `pdfVerification` | 240s | 60s | PDF vision verification — vision TTFT can be 20–60s for 30–100 page OMs before tokens flow |
| `extraction` | 480s | 90s | Long-context document extraction (up to 64k output tokens) |
| `icMemo` | 180s | 45s | IC memo section generate/refine |
`pdfVerification` is the longest preset by design. Native-PDF vision ingestion has a long time-to-first-token before any streaming starts, so a shorter preset would abort valid calls mid-think.
## Embeddings [#embeddings]
When the Gateway is configured, embeddings use **`openai/text-embedding-3-small`** (1536 dimensions). They carry the same `feature`, `orgId`, and `userId` attribution as LLM calls.
Direct Anthropic does not provide an embeddings endpoint. When only the Anthropic fallback is in place, embedding calls fail soft — the helper returns an empty array and any features that require embeddings degrade gracefully (text search falls back to keyword matching, research narratives skip the semantic-similarity stage). Production deployments should always configure the Gateway so embeddings are available.
## Where to Go Next [#where-to-go-next]
* For the data-handling and human-in-the-loop posture of every AI surface, see [Trust and safety](/docs/ai-assistant/trust-and-safety).
* For which tools each chat mode exposes, see [Tool reference](/docs/ai-assistant/tools-reference).
* For specialist agents that drive the bulk of `document-processing` and `corbis-research` traffic, see [Specialist agents](/docs/ai-assistant/agents).
* For implementers: model resolution lives in `src/lib/ai/` (`resolveModelCall`, profiles). Confirm AI SDK / Gateway call shapes via [AI SDK 7 docs](https://ai-sdk.dev/v7/docs), `vercel:ai-sdk`, and `vercel:ai-gateway` — not this product page.
---
# AI Assistant Overview (/docs/ai-assistant/overview)
This page summarizes where AI surfaces appear and how they behave. For human-in-the-loop controls and safeguards, see [AI Trust and Safety](/docs/ai-assistant/trust-and-safety). Deeper technical references for the platform are expanded over time alongside the product.
The EQUIRE AI assistant is a deal-context-aware analyst embedded throughout the platform. It is powered by models routed through the Vercel AI Gateway (Claude family defaults; optional frontier pilots when enabled for your deployment).
## Where the Assistant Appears [#where-the-assistant-appears]
| Surface | Purpose |
| ---------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
| Deal chat (every tab) | Answer deal-specific questions, run comparisons against the pipeline (`searchAcrossDeals`, `compareDealMetrics`), draft text |
| Prospect advisor | Structured mandate-fit review on origination workflows (distinct from conversational chat) |
| Prospecting chat | Conversational assistant in the prospecting workspace with prospecting-focused tools |
| Valuation analyst | Multi-step pipeline to infer DCF assumptions from extracted data and market benchmarks |
| IC memo generation | Draft all 12 memo sections from deal data via streaming section endpoints |
| Document processing pipeline | Background extraction and verification of uploaded documents (not the same UX as floating chat; feeds deal data that other surfaces consume) |
## What the Assistant Can Do [#what-the-assistant-can-do]
### Deal Analysis and Q & A [#deal-analysis-and-q--a]
* Answer questions about your deal's data: "What is the in-place rent vs market?"
* Run portfolio comparisons from deal chat: "How does this deal's cap rate compare to others in the pipeline?"
* Flag missing data and suggest next steps
* Explain the Review queue from the same canonical categories shown in the Review tab: data conflict items, source review items, and field check items.
* Navigate valuation work by reading the current DCF first, then making approval-gated updates to assumptions, OpEx, purchase/SF parameters, or the structured capital stack when you ask it to change underwriting inputs.
* On the **Deal Overview** tab, list, create, edit, or rebuild saved custom dashboard widgets from chat when you ask explicitly (or use the Overview dashboard button to create). These writes persist immediately without a separate Allow / Deny step; factual questions stay read-only.
* In **deal chat**, search processed documents **for the current deal** (`searchDocuments`); when you @-mention a document, the assistant is guided to search that file. Portfolio and prospecting chat do not expose per-deal document chunk search—they use other org- or mandate-scoped tools instead.
### Drafting and Generation [#drafting-and-generation]
* Draft IC memo sections and deliverables from deal data
* Produce executive summaries, risk assessments, and research narratives on demand
## Deal and Institutional Memory [#deal-and-institutional-memory]
EQUIRE memory is governed product state, not hidden model memory. The assistant reads compact memory summaries in the prompt and retrieves raw history through tools when it needs provenance.
### Deal Memory [#deal-memory]
Each deal can have a durable notebook of source-linked entries: facts, decisions, assumption changes, risks, diligence findings, task updates, agent runs, human notes, open questions, lessons, and outcomes. The assistant uses a compact **deal memory brief** before acting so it can see the current thesis, validated facts, prior decisions, blockers, next actions, data-release state, and recent changes without loading the entire history into every message.
When you ask "what have we already done?" or "why did we make that decision?", the assistant can read the deal brief first, then search the notebook for supporting entries.
### Institutional Memory [#institutional-memory]
Institutional memory captures reviewed cross-deal patterns for your organization: preferences, decision rules, recurring risk patterns, underwriting variance, diligence sensitivities, IC feedback, market precedents, and memo-style lessons. These patterns help the assistant compare a new deal against what the firm has learned from prior deals.
Historical pre-EQUIRE deals can be imported from reviewed IC memos and underwriting models. Those imports create deal outcomes, notebook entries, and draft institutional patterns for human review. Reviewed memory can influence future analysis; draft memory stays visible only when explicitly requested or during review workflows.
## Organization Company Profile [#organization-company-profile]
Organization admins can review public business context generated from the firm's website, including firm type, investment mandate, underwriting preferences, sourcing preferences, and memo style. Once the profile is marked **reviewed**, EQUIRE includes its bounded, sanitized summary in organization-aware chat prompts and can retrieve the current profile when you ask about the firm's preferences.
Draft and rejected profiles are withheld from AI prompts and tool responses. If the profile service is temporarily unavailable, the assistant reports that it cannot verify availability; it does not assume the firm has no profile. Company Profile context is advisory and complements, rather than replaces, deal evidence and reviewed institutional memory.
## What the Assistant Cannot Do [#what-the-assistant-cannot-do]
### Boundaries by Design [#boundaries-by-design]
* Access data outside your organization's deals
* Submit offers, sign documents, or transact on your behalf
* Reach live web sources or certain external APIs unless you enable the corresponding tool categories in the chat UI (for example web search or market-data toggles)—defaults may vary by surface
## Approval-Gated Actions [#approval-gated-actions]
### Explicit Confirmation Required [#explicit-confirmation-required]
Certain AI actions require explicit approval before execution (AI SDK tool approval flows: Allow / Deny). Examples include **adding a prospect tag** and **snoozing a prospect** from prospecting chat. The assistant prompts for confirmation; no mutation occurs without a user action. Many deal-level write tools in deal chat follow the same pattern.
Deal chat answers with final text and tool results — it does **not** stream internal model reasoning / chain-of-thought into the chat UI.
Review-item actions in deal chat use the same Review queue contract as the UI. The assistant reads `getReviewQueue` before stating counts, then uses approval-gated `actOnReviewItem` for source review and field check items. Data conflicts still route through conflict-resolution tools, and direct corrections route through field-update tools.
Valuation mutations are also approval-gated. For financing structure changes, the assistant should inspect `getValuation` first and then use `updateCapitalStack` for all-cash, senior debt, bridge or construction future funding, mezzanine debt, preferred equity, and custom multi-layer capital stacks.
### Web Search, Research Toggles, and External Integrations [#web-search-research-toggles-and-external-integrations]
In **deal**, **portfolio**, and **prospecting** chat, optional tools (such as web search, market data, academic paper search when the research category is on, and comparable-property discovery where applicable) are controlled by **in-chat category toggles** the user enables; enabled tools appear in that chat UI.
The **EQUIRE MCP connector** (for external clients) is separate from these in-app chat tools—it exposes connector-scoped capabilities such as excerpt search (`documents:search`) rather than duplicate the floating chat toolbox. Optional **Corbis deep research** can be enabled from the in-chat research toggles when your deployment has `CORBIS_MCP_TOKEN` configured; it is not on by default.
---
# Tool Reference (/docs/ai-assistant/tools-reference)
{/* LEGAL REVIEW REQUIRED before merge - see docs/documentation-page/docs-site-plan.md legal review status */}
This page is the human-facing reference for the tools the chat assistant can call on your behalf. Each tool is one capability: a query, a calculation, or a mutation. The assistant chooses tools based on your message, the active chat mode, and the web-toggle categories you have enabled. Source code remains the canonical runtime inventory.
For implementers: tool factories live under `src/lib/ai/tools/` (see `src/lib/ai/tools/README.md` and `CLAUDE.md`). AI SDK tool/stream APIs — use `vercel:ai-sdk` and [AI SDK 7 docs](https://ai-sdk.dev/v7/docs), not this page.
## How to Read This Page [#how-to-read-this-page]
* **Modes** — which chat surfaces expose this tool. *Deal* is per-deal chat, *Portfolio* is the org-level chat at `/deals` and similar, *Prospecting* is the chat in mandate workspaces.
* **Type** — *Read* tools fetch information; *Write* tools mutate deal, prospect, or task state.
* **Approval** — a checkmark means the tool prompts Allow / Deny before running.
For mode behavior and toggle defaults, see [Chat modes](/docs/ai-assistant/chat-modes). For who governs each tool's data and provenance, see [Trust and safety](/docs/ai-assistant/trust-and-safety).
## Deal Data and Property [#deal-data-and-property]
| Tool | Description | Modes | Type | Approval |
| ----------------------- | ----------------------------------------------------------------------------------------------- | --------------- | ----- | -------- |
| `getDealData` | Read deal overview, property, tenants, financials, environmental, appraisal, pricing, financing | Deal, Portfolio | Read | — |
| `updatePropertyInfo` | Modify property name, address, city, state, type, square footage, year built | Deal | Write | ✓ |
| `updateField` | Update any deal schema field; resolves single conflicts and dated fields | Deal | Write | ✓ |
| `addTenant` | Create a new rent roll tenant record | Deal | Write | ✓ |
| `deleteTenant` | Remove a tenant from the rent roll | Deal | Write | ✓ |
| `deleteSuiteInventory` | Remove duplicate or incorrect suite inventory / vacancy schedule records | Deal | Write | ✓ |
| `addOperatingStatement` | Append a T-12 or custom operating statement to financials | Deal | Write | ✓ |
| `getDealActivityLog` | Fetch the deal audit log with timestamps, actions, user attribution | Deal | Read | — |
## Documents [#documents]
| Tool | Description | Modes | Type | Approval |
| ----------------------- | --------------------------------------------------------------------------------------------------------- | ----- | ----- | -------- |
| `searchDocuments` | Search processed documents in the current deal; supports @-mention scoping | Deal | Read | — |
| `listDocuments` | List uploaded documents with metadata, type, status, extraction status | Deal | Read | — |
| `reprocessDocument` | Trigger re-extraction and verification on a document | Deal | Write | ✓ |
| `deleteDocument` | Remove a document from the deal | Deal | Write | ✓ |
| `markDocumentsReviewed` | Clear the needs-review flag on documents | Deal | Write | ✓ |
| `getReviewQueue` | Read the canonical Review tab queue: total label, all category rows, ranked decisions, document summaries | Deal | Read | — |
| `actOnReviewItem` | Apply an approved action to a source review or field check item from the Review queue | Deal | Write | ✓ |
| `getConflicts` | List open extraction conflicts with source priority and confidence | Deal | Read | — |
| `resolveConflict` | Accept a source as canonical for a single conflicted field, or set a manual override | Deal | Write | ✓ |
| `resolveAllConflicts` | Bulk-accept the preferred source for every open conflict in a deal | Deal | Write | ✓ |
| `getOpenFindings` | List validation findings — arithmetic, consistency, missing fields | Deal | Read | — |
## Valuation [#valuation]
| Tool | Description | Modes | Type | Approval |
| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----- | ----- | -------- |
| `getValuation` | Fetch the built DCF model with scenarios, assumptions, and outputs (value, IRR, MoIC, cash flows) | Deal | Read | — |
| `analyzeValuation` | Narrative analysis of assumptions, drivers, and investment thesis | Deal | Read | — |
| `sensitivityAnalysis` | Generate one- and two-variable sensitivity tables for IRR, MoIC, value | Deal | Read | — |
| `updateAssumption` | Modify a base-year or growth assumption (rent, NOI, cap rate, discount rate, exit) | Deal | Write | ✓ |
| `updateTenantAssumption` | Modify tenant-level renewal, downtime, landlord work, TI, or blowout assumptions | Deal | Write | ✓ |
| `updateOpex` | Update operating expense line items | Deal | Write | ✓ |
| `updateValuationParams` | Modify model parameters such as purchase price and square footage | Deal | Write | ✓ |
| `updateCapitalStack` | Update structured financing: all-cash, senior debt, bridge/construction future funding, senior + mezzanine, senior + preferred equity, or custom multi-layer stacks | Deal | Write | ✓ |
| `exportValuationExcel` | Generate a formula-based Excel workbook with live model formulas | Deal | Read | — |
## Deal Overview JSON Render [#deal-overview-json-render]
Available only on the **Deal Overview** tab when deal chat page context matches Overview. These tools manage saved custom dashboard widgets on the Overview canvas (read-only JSON Render panels grounded in live deal state).
| Tool | Description | Modes | Type | Approval |
| --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | -------------------- | ----- | -------- |
| `listJsonRenderDashboards` | List saved custom dashboard widgets with ids and titles | Deal (Overview only) | Read | — |
| `createJsonRenderDashboard` | Create and save a custom dashboard, chart, panel, or visualization from an explicit creation prompt or the Overview dashboard button | Deal (Overview only) | Write | — |
| `editJsonRenderDashboard` | Edit, rebuild, or regenerate an existing saved widget by `widgetId` from an explicit edit prompt | Deal (Overview only) | Write | — |
`createJsonRenderDashboard` and `editJsonRenderDashboard` persist immediately after an explicit user request (or the visible Overview dashboard affordance for creation). They do not show Allow / Deny approval prompts. Factual or analytical questions must no-op and stay on read-only deal tools. Lease rollover plus DSCR timeline requests use the deterministic `system-lease-rollover-dscr` template (`RolloverDscrTimeline`).
## Market and Research [#market-and-research]
The assistant reads two precomputed market datasets covering roughly 1,000 US metros (CBSAs). Both are available in every chat mode when **Market data** is enabled in the chat settings.
* An **economic and demographic** layer (`getMarketData`, `compareMarkets`, `searchMarkets`, `getMarketTrends`, `getNationalMacro`) — about 166 metrics drawn from roughly 22 government and research sources (BLS, Census, FHFA, HUD, BEA, IRS, FAA, FEMA, FDIC, Zillow, and others): employment, population, income, housing supply and prices, affordability, migration, lending conditions, and climate risk.
* A **commercial real-estate** layer (`getCREMarket`, `getCRETrend`, `getCREComps`) — cap rate, occupancy, NOI per SF, price per SF, DSCR, and asking rents by metro and property type, blending recent securitized (CMBS) transactions with current listings, plus year-by-year trends and the individual property comparables behind each market.
All values are precomputed and read-only. For commercial figures the assistant reports the underlying sample size, leads with the pooled median (such as the most current cap-rate measure), and keeps residential (Zillow/HUD) data separate from commercial rents.
| Tool | Description | Modes | Type | Approval |
| ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------- | ---- | -------- |
| `getMarketData` | Economic and demographic profile for a US metro — \~166 metrics (employment, population, income, housing, prices, affordability, migration, lending, climate risk) with a narrative, peer metros, and a composite score | Deal, Portfolio, Prospecting | Read | — |
| `compareMarkets` | Side-by-side comparison of metrics across two or more metros | Deal, Portfolio, Prospecting | Read | — |
| `searchMarkets` | Rank or search \~1,000 metros by any metric, region, state, or market tier | Deal, Portfolio, Prospecting | Read | — |
| `getNationalMacro` | US macro context — GDP, CPI, Treasury yields, 30-year mortgage rate, Fed Funds rate | Deal, Portfolio, Prospecting | Read | — |
| `getMarketTrends` | Historical time series for a metro from 11 federal sources | Deal, Portfolio, Prospecting | Read | — |
| `getMetricDefinitions` | Glossary of market data fields and calculation methods | Deal, Portfolio, Prospecting | Read | — |
| `getCREMarket` | Commercial real-estate market by metro and property type — cap rate, occupancy, NOI/SF, and price/SF as low/median/high ranges, plus DSCR and asking rent | Deal, Portfolio, Prospecting | Read | — |
| `getCRETrend` | Year-by-year history of a CRE metric for a metro (for example, how office cap rates moved from 2015 to 2025) | Deal, Portfolio, Prospecting | Read | — |
| `getCREComps` | Individual securitized-property (CMBS) comparables behind a market's aggregates | Deal, Portfolio, Prospecting | Read | — |
| `searchPapers` | Query academic papers (OpenAlex) on CRE, markets, and asset performance | Deal, Portfolio, Prospecting | Read | — |
| `getResearchSources` | List research sources linked to the deal | Deal | Read | — |
| `getResearchBenchmarks` | Externally sourced benchmarks — rents, cap rates, occupancy by asset class and market | Deal | Read | — |
| `getMarketNarrative` | Synthesized narrative of market conditions from collected research | Deal | Read | — |
| `getEconomicConditions` | Economic context relevant to the deal — labor, construction costs, credit availability | Deal | Read | — |
| `searchMarketReports` | Retrieve market reports (broker reports, research, local intel) for a property or market | Deal | Read | — |
| `searchBusinessContext` | Find business context — tenant background, competitive landscape, regulatory | Deal | Read | — |
| `analyzeMarketReports` | Synthesize insights from collected research and market reports | Deal | Read | — |
| `generateMarketNarrative` | Generate a cohesive market narrative for IC memo or deliverable inclusion | Deal | Read | — |
## Comparable Properties [#comparable-properties]
| Tool | Description | Modes | Type | Approval |
| ----------- | ------------------------------------------------------------------------- | ----- | ---- | -------- |
| `findComps` | Search for comparable sales and active listings near the subject property | Deal | Read | — |
Comps are intentionally restricted to deal mode because they are property-level. The comps toggle is hidden in portfolio and prospecting chat.
## Deal Health [#deal-health]
| Tool | Description | Modes | Type | Approval |
| -------------------- | --------------------------------------------------------------------------------------- | ----- | ----- | -------- |
| `getHealthSummary` | Overall deal-health score, severity counts, category breakdown, last-analyzed timestamp | Deal | Read | — |
| `getHealthIssues` | List health issues with filters (severity, type, status, category, search) | Deal | Read | — |
| `getHealthIssue` | Fetch details of a single health issue | Deal | Read | — |
| `createHealthIssue` | Create a new health issue for manual problem tracking | Deal | Write | — |
| `updateHealthIssue` | Modify health issue status, severity, owner, or notes | Deal | Write | — |
| `resolveHealthIssue` | Mark a health issue resolved | Deal | Write | — |
| `runHealthAnalysis` | Trigger a deep health scan (validators, data quality, consistency) | Deal | Write | — |
## Portfolio and Cross-Deal [#portfolio-and-cross-deal]
| Tool | Description | Modes | Type | Approval |
| ---------------------- | ------------------------------------------------------------------------------------------- | --------------- | ---- | -------- |
| `listAllDeals` | List all portfolio deals with status filters and metrics | Portfolio | Read | — |
| `getDealSummary` | Deep summary of a single deal — property, tenants, documents, valuation status | Portfolio | Read | — |
| `compareDealMetrics` | Side-by-side comparison of financial and operational metrics across deals | Deal, Portfolio | Read | — |
| `searchAcrossDeals` | Full-text search across all deals — documents, memos, issues | Deal, Portfolio | Read | — |
| `getPipelineAnalytics` | Portfolio-wide pipeline insights — deal counts by stage, average metrics, funnel throughput | Portfolio | Read | — |
## Prospecting [#prospecting]
| Tool | Description | Modes | Type | Approval |
| ---------------------------- | ------------------------------------------------------------------------------------- | ----------- | ----- | -------- |
| `listMandates` | List active search mandates with criteria and funnel counts | Prospecting | Read | — |
| `searchProspects` | Query prospects against active mandates with readiness and ownership filters | Prospecting | Read | — |
| `getProspectBrief` | Fetch a prospect summary — property, listing data, ownership signals, readiness score | Prospecting | Read | — |
| `listProspectSources` | List data sources attached to a prospect | Prospecting | Read | — |
| `compareProspects` | Compare readiness, metrics, and mandate fit across prospects | Prospecting | Read | — |
| `searchMandateMarkets` | Find prospects across all mandates in specified markets | Prospecting | Read | — |
| `getMandateHealth` | Mandate performance — sourcing velocity, readiness distribution, conversion rate | Prospecting | Read | — |
| `getProspectOwnerPath` | Trace the ownership chain — entity relationships and decision-makers | Prospecting | Read | — |
| `listSnoozedProspects` | List prospects currently snoozed with their wake dates | Prospecting | Read | — |
| `getDigestPreview` | Preview the daily or weekly prospect digest before sending | Prospecting | Read | — |
| `prepareScreeningMemoExport` | Prepare a screening memo export for a prospect | Prospecting | Read | — |
| `snoozeProspect` | Defer a prospect to the queue until a date or shortcut (tomorrow, next week) | Prospecting | Write | ✓ |
| `addProspectTag` | Assign a custom tag to a prospect for tracking and filtering | Prospecting | Write | ✓ |
| `dismissProspect` | Dismiss a prospect from the active review queue | Prospecting | Write | ✓ |
| `attachProspectSourceUrl` | Attach a source URL to a prospect record | Prospecting | Write | ✓ |
| `updateProspectSource` | Update metadata or status on a prospect source | Prospecting | Write | ✓ |
| `runProspectResearchAction` | Start a targeted prospect research action | Prospecting | Write | ✓ |
| `convertProspectToDeal` | Convert a prospect into a deal workspace | Prospecting | Write | ✓ |
| `runSourcingProfile` | Run a sourcing profile against available prospecting sources | Prospecting | Write | ✓ |
| `launchScoutReview` | Launch an AI scout review for a prospect or mandate | Prospecting | Write | ✓ |
| `dispatchBackgroundJob` | Dispatch an approved enrichment or review job | Prospecting | Write | ✓ |
## Tasks and Work Queue [#tasks-and-work-queue]
| Tool | Description | Modes | Type | Approval |
| ---------------------- | ------------------------------------------------------------------------------ | ----- | ----- | -------- |
| `getDealNextActions` | Prioritized action items derived from health, tasks, and diligence context | Deal | Read | — |
| `listDealTasks` | Query the persistent work queue with status, priority, and type filters | Deal | Read | — |
| `createDealTask` | Create a new work item with title, description, priority, due date, assignment | Deal | Write | ✓ |
| `updateDealTask` | Modify task status, priority, assignee, or dates | Deal | Write | ✓ |
| `completeDealTask` | Mark a task complete | Deal | Write | ✓ |
| `snoozeDealTask` | Snooze a task until a date; hides it from the queue until then | Deal | Write | ✓ |
| `scheduleTaskReminder` | Set a reminder notification for a task | Deal | Write | ✓ |
## Specialist Workflow Tools [#specialist-workflow-tools]
These tools wrap deeper specialist agents (lease, debt, legal, diligence, intake, closing, LOI). The chat assistant invokes them when your message is in their domain. For more on the agents themselves, see [Specialist agents](/docs/ai-assistant/agents).
### Lease Intelligence [#lease-intelligence]
| Tool | Description | Modes | Type | Approval |
| ------------------- | -------------------------------------------------------------------------- | ----- | ----- | -------- |
| `abstractLeases` | Extract key lease terms per tenant — rent, dates, escalations, TI, options | Deal | Write | — |
| `compareLeaseTerms` | Compare rent spreads, escalations, and concessions across tenants | Deal | Read | — |
### Debt Placement [#debt-placement]
| Tool | Description | Modes | Type | Approval |
| ---------------------- | ------------------------------------------------------------------------ | ----- | ---- | -------- |
| `prepareLenderPackage` | Tailor the lender package — financials, tenants, market — by lender type | Deal | Read | — |
| `compareTermSheets` | Side-by-side comparison of loan terms; highlights best rate or leverage | Deal | Read | — |
| `lenderSensitivity` | DSCR and LTV sensitivity tables for hypothetical loan changes | Deal | Read | — |
### Legal Review [#legal-review]
| Tool | Description | Modes | Type | Approval |
| -------------------- | --------------------------------------------------------------------- | ----- | ---- | -------- |
| `reviewPSA` | Extract and flag PSA terms; identify deviations from market standards | Deal | Read | — |
| `mapTitleExceptions` | Categorize title exceptions; assess impact and cure recommendations | Deal | Read | — |
| `generateIssueList` | First-pass legal issue list compiled from all documents | Deal | Read | — |
### Diligence Management [#diligence-management]
| Tool | Description | Modes | Type | Approval |
| ---------------------------- | ----------------------------------------------------------------------- | ----- | ----- | -------- |
| `createDiligenceRequest` | Generate a prioritized DD document request list | Deal | Write | — |
| `chaseDeliverables` | Generate escalation-tiered follow-up messages for outstanding documents | Deal | Read | — |
| `verifyDocumentCompleteness` | Verify required closing documents are received and executed | Deal | Read | — |
### Intake and Screening [#intake-and-screening]
| Tool | Description | Modes | Type | Approval |
| ----------------- | ----------------------------------------------------------------------- | ----- | ---- | -------- |
| `screenDeal` | Rapid triage from raw text (OM, teaser, email) with mandate-fit scoring | Deal | Read | — |
| `scoreMandateFit` | Score deal fit against fund criteria (0–100) with drivers | Deal | Read | — |
### Closing [#closing]
| Tool | Description | Modes | Type | Approval |
| -------------------------- | --------------------------------------------------------- | ----- | ----- | -------- |
| `generateClosingChecklist` | Standard closing checklist plus deal-specific obligations | Deal | Write | — |
### LOI [#loi]
| Tool | Description | Modes | Type | Approval |
| -------------------- | -------------------------------------------------------------------------------- | ----- | ---- | -------- |
| `draftLOI` | Generate an LOI with buyer entity, price, contingencies, timeline from deal data | Deal | Read | — |
| `compareLOIVersions` | Side-by-side version comparison highlighting price and term changes | Deal | Read | — |
### Transaction Graph [#transaction-graph]
The transaction graph tracks parties, milestones, and obligations across the deal lifecycle.
| Tool | Description | Modes | Type | Approval |
| ------------------ | ---------------------------------------------------------------------------- | ----- | ----- | -------- |
| `listParties` | List all deal parties — buyer, seller, broker, lender, legal — with contacts | Deal | Read | — |
| `addParty` | Register a new party in the transaction graph | Deal | Write | — |
| `listMilestones` | List deal milestones (DD close, financing approval, closing) | Deal | Read | — |
| `addMilestone` | Create a deal milestone | Deal | Write | — |
| `updateMilestone` | Modify a milestone's date, status, or owner | Deal | Write | — |
| `listObligations` | List open obligations — seller deliverables, lender conditions | Deal | Read | — |
| `addObligation` | Create an obligation | Deal | Write | — |
| `updateObligation` | Modify an obligation's status, owner, or due date | Deal | Write | — |
## Institutional Memory [#institutional-memory]
| Tool | Description | Modes | Type | Approval |
| ----------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------- | ----- | -------- |
| `getDealMemoryBrief` | Read the compact working-memory brief for a deal: thesis, validated facts, decisions, blockers, next actions, and recent changes | Deal, Portfolio | Read | — |
| `getDealNotebook` | Retrieve governed notebook entries for a deal, including facts, decisions, risks, questions, lessons, outcomes, and human / agent notes | Deal, Portfolio | Read | — |
| `searchDealNotebook` | Search the deal notebook by topic with provenance-linked results | Deal, Portfolio | Read | — |
| `getOrganizationCompanyProfile` | Read the latest reviewed, bounded public-business context for the organization; draft and rejected profiles remain withheld | Deal, Portfolio, Prospecting, Listings | Read | — |
| `findRelevantInstitutionalPatterns` | Find reviewed institutional patterns relevant to a deal profile, such as preferences, risk patterns, IC feedback, or diligence sensitivities | Deal, Portfolio | Read | — |
| `compareDealToInstitutionalMemory` | Compare a deal profile against reviewed institutional memory and return the patterns that should shape analysis | Deal, Portfolio | Read | — |
| `recordNotebookEntry` | Record an approved deal notebook entry for durable facts, decisions, risks, open questions, or lessons | Deal, Portfolio | Write | ✓ |
| `proposeInstitutionalMemoryPattern` | Save a draft cross-deal memory pattern for later human review | Deal, Portfolio | Write | ✓ |
| `recordHistoricalDealOutcome` | Import a reviewed historical deal packet from IC memos and underwriting models into outcomes, notebook entries, and draft patterns | Deal, Portfolio | Write | ✓ |
Memory tools are org-scoped and only exposed when an organization context is in place. Deal-specific tools use the current deal automatically in deal chat; in portfolio chat, the assistant must identify or receive a `dealId`. Reviewed institutional memory can enter compact prompt context, while raw notebook entries and draft patterns are retrieved by tools on demand.
## Web Search [#web-search]
| Tool | Description | Modes | Type | Approval |
| ----------- | -------------------------------------------------------------------------------- | ---------------------------- | ---- | -------- |
| `webSearch` | Search the web for current CRE market info, news, tenant credit, and comparables | Deal, Portfolio, Prospecting | Read | — |
Web search runs only when the **Web search** category toggle is enabled in the chat input footer. The provider order falls back gracefully across configured services (Perplexity → Bing); failures are non-blocking.
## Approval-Gated Tools at a Glance [#approval-gated-tools-at-a-glance]
These tools always prompt for Allow / Deny before running. When two or more are pending, a bulk approval bar appears.
* **Deal mode** — `actOnReviewItem`, `updatePropertyInfo`, `updateField`, `addTenant`, `deleteTenant`, `deleteSuiteInventory`, `addOperatingStatement`, `reprocessDocument`, `deleteDocument`, `markDocumentsReviewed`, `resolveConflict`, `resolveAllConflicts`, valuation mutation tools, and deal work-queue mutations. Overview JSON Render create/edit (`createJsonRenderDashboard`, `editJsonRenderDashboard`) are **not** in this list; they persist immediately after an explicit creation or edit/rebuild prompt (or the Overview dashboard button for creation).
* **Prospecting mode** — all prospecting write tools, including snooze, tag, dismiss, source update, research action, conversion, sourcing-profile run, scout review, and background-job dispatch
## Where to Go Next [#where-to-go-next]
* For how the assistant decides which tools to expose in each mode, see [Chat modes](/docs/ai-assistant/chat-modes).
* For specialist agents that wrap many of these tools into multi-step flows, see [Specialist agents](/docs/ai-assistant/agents).
* For data-handling and human-in-the-loop guarantees on the writes, see [Trust and safety](/docs/ai-assistant/trust-and-safety).
---
# AI Trust and Safety (/docs/ai-assistant/trust-and-safety)
{/* LEGAL REVIEW REQUIRED before merge — see docs/documentation-page/docs-site-plan.md §5 */}
This page describes governance, data handling, and human-in-the-loop expectations for AI in EQUIRE. For a concise map of surfaces and behaviors, see [AI Assistant Overview](/docs/ai-assistant/overview).
EQUIRE uses AI to accelerate CRE deal analysis: extracting rent roll data from documents, reasoning through DCF assumptions against market comps, drafting IC memo sections from extracted evidence, and surfacing prospecting research. AI augments the work — the acquisitions professional, underwriter, or general counsel remains accountable for every consequential decision.
**Human review and initiation.** The product is designed so that consequential changes to deal records, valuation models, and deliverables rely on explicit human checkpoints: extraction review and conflict resolution, assumption acceptance, IC memo section completion, and user-initiated export. Many deal-chat mutations that alter stored data run through **approval prompts** (allow / deny) before they execute — the same pattern described for prospecting chat on the overview page.
Not every automation in the platform is gated behind a separate click on that specific downstream action. Background jobs (for example document processing) persist extracted artifacts for review when conflicts exist or confidence is low, and **opt-in notifications** — such as email when processing completes or a scheduled prospecting digest that may include AI-generated narrative — are sent **without requiring a separate manual "send"** for each message by the recipient. Nothing in AI output **signs, commits investment decisions, or transacts on a user's behalf**.
## What AI Does [#what-ai-does]
The following capabilities are powered by AI within EQUIRE:
### Data Extraction and Verification [#data-extraction-and-verification]
* **Document extraction** — parses rent roll data, lease terms, operating statements, and property financials from PDF and XLSX documents uploaded to a deal.
* **Extraction verification** — runs a secondary model pass over extracted values to flag suspect data before it reaches the review surface.
### Analysis and Reasoning [#analysis-and-reasoning]
* **Valuation reasoning** — evaluates DCF assumptions (cap rates, rent growth, vacancy, expenses) against market comparables and fund benchmarks; surfaces a reasoning trace alongside each suggested value.
* **Deal health analysis** — performs coherence and deep-scan checks across extracted data to surface missing fields, contradictions, and diligence gaps.
* **Prospecting research** — enriches property and sponsor records with market data, owner path signals, and debt maturity information; summarizes findings in the daily mandate digest.
### Drafting and Generation [#drafting-and-generation]
* **IC memo drafting** — generates narrative sections for the Investment Committee memorandum using extracted deal data, valuation outputs, and research findings as source material.
* **Deliverable generation** — drafts executive summaries, risk assessments, loan packages, and comp analyses from deal data on demand.
* **Deal assistant** — answers deal-context questions and runs ad-hoc analysis; **persisted mutations** (assumptions, fields, annotations, conflict resolution paths exposed to the model) typically require **acceptance in the chat approval UI or a downstream review surface** rather than silently changing the ledger without human involvement.
## What AI Does Not Do [#what-ai-does-not-do]
* Does not sign, commit, or submit anything on behalf of a user.
* Does not **initiate unsolicited outreach** as an autonomous broker of email or outreach campaigns. The platform **may** deliver **transactional or opt-in emails** — for example "document processed" notices for uploads you kicked off, prospecting summaries for users who enable digests — without a distinct per-email compose action by the recipient; those channels are bounded by tenant settings and product flows, not by the model acting independently as a correspondent.
* Does not make or record an investment decision.
* Does not modify a source document after upload.
* Does not overwrite a value that a user has manually entered without surfacing a conflict for resolution.
* Does not share deal data across organizations. {/* LEGAL: verify that cross-org isolation holds at the AI Gateway layer in addition to the DB layer */}
* Does not retain deal content for model training. {/* LEGAL: verify this claim against the current Vercel AI Gateway and Anthropic data processing agreements in the EQUIRE master agreement */}
## Provenance and Citations [#provenance-and-citations]
### How Extracted Values Are Stored [#how-extracted-values-are-stored]
Every value EQUIRE extracts from a document is stored as a source-linked record that carries the originating document, the extraction confidence, and the verification state. In the EQUIRE interface this is called a `TrackedValue`.
### Conflict Surfacing [#conflict-surfacing]
When two or more documents disagree on a value — for example, when an OM states a different rent than the lease abstract — EQUIRE surfaces the conflict in the Review tab with both candidates and their source documents. The system does not silently resolve the conflict or pick a winner through the canonical Review flow. The user selects the authoritative value, or enters a manual override.
### Confidence Labeling [#confidence-labeling]
Values with low extraction confidence are labeled accordingly in the Deal Data tab. AI-generated narrative in the IC memo and deliverables carries no direct citation authority; numeric claims in that narrative must trace back to source-linked extracted values in the deal record.
## Models and Providers [#models-and-providers]
EQUIRE routes AI requests through the Vercel AI Gateway when Gateway credentials are configured. Shipped defaults use Anthropic Claude family models; frontier providers (e.g. xAI Grok 4.5) are **opt-in pilots** via admin or per-run override — never the platform auto-default. Pilot eligibility depends on capability gates and platform Zero Data Retention: with ZDR on, models without a Gateway ZDR route stay visible but cannot be saved as overrides. Deployments configured for **Anthropic-only** access (without the Gateway) do not attach the same Gateway-side option bundle; contractual and retention posture follows the deployment's provider path and your agreements.
Different workflows use different tiers: lighter models for verification and classification; more capable models for valuation reasoning, IC memo generation, and multi-step research agents. Document extraction and related Anthropic-only features stay on Claude. UI streams set `sendReasoning: false` — server reasoning effort is pinned separately and chain-of-thought is not shown in the product UI.
## Data Handling [#data-handling]
### Document Storage [#document-storage]
Documents you upload to EQUIRE are stored in your organization's encrypted database. Access is scoped to your organization via row-level security enforced at the database layer — see [Data Isolation](/docs/security/data-isolation) for the enforcement model. If you expose an IC memo or deliverable via a **public share link**, anyone with that URL can view it — see the warning on [Data Isolation](/docs/security/data-isolation).
### AI Inference and Retention [#ai-inference-and-retention]
When platform Zero Data Retention is **on** (super-admin toggle at **Admin → Model Config → Gateway controls**), eligible Gateway requests carry `zeroDataRetention: true` in `providerOptions` — confirm against your contractual terms. ZDR can be turned off for pilots that require models without a Gateway ZDR route (e.g. `xai/grok-4.5`).
**Nuances:**
* Gateway options do not attach to inference that bypasses Gateway (direct provider setup).
* Non–ZDR-qualified models are excluded from ZDR-on overrides even if listed in the Gateway catalog.
* **Embedding** workloads that power search and retrieval also use Gateway models where configured; we are aligning attribution so auxiliary embedding traffic carries the same Gateway option bundle as conversational and extraction workloads. Until that rollout is uniform, treat embedding traffic as separately confirmed in diligence. {/* LEGAL: verify embedding + batch + streaming parity */}
This page describes product behavior — the **EQUIRE master agreement** and supplier DPAs determine legal retention and processing terms. {/* LEGAL: verify that "zero data retention" reflects current contractual terms between EQUIRE, Vercel, and Anthropic across all routed request shapes */}
## Human Checkpoints [#human-checkpoints]
The following workflow steps require explicit human action before AI output lands in authoritative deal state or a final deliverable:
### Extraction and Conflicts [#extraction-and-conflicts]
* **Conflict resolution** — the Review tab surfaces extraction conflicts; a user selects the authoritative value before values are finalized in the deal schema.
### Valuation [#valuation]
* **Valuation assumption confirmation** — AI-suggested assumptions appear alongside their source and confidence; a user accepts, overrides, or dismisses each before the DCF runs with them.
### Memo and Deliverables [#memo-and-deliverables]
* **IC memo section completion** — AI-drafted memo sections advance to **`ready`** when you run generation; sections move to authoritative **`complete`** and the memo moves toward **`approved`** only through workflow rules that enforce review completeness.
* **Deliverable export** — generating and exporting a deliverable (executive summary, loan package, risk assessment) is a user-initiated action; EQUIRE does not email deliverables externally unless **you or your org workflows** initiate that separately.
### No Auto-Apply Rule Summary [#no-auto-apply-rule-summary]
The design intent is summarized at the **top of this page**: human checkpoints plus approval-gated chat mutations wherever that pattern is enforced in code. Operational channels (cron digests, job-completion mail) operate under opt-in/product settings and are scoped in **What AI does not do** above.
## Hallucination Handling [#hallucination-handling]
Extracted values that lack a source citation are marked low-confidence and flagged in the Review tab. EQUIRE does not promote unsourced values into the DCF model or IC memo without user confirmation paths appropriate to that workflow.
AI-generated narrative — IC memo sections, research summaries, advisor commentary — is advisory. It is produced from deal data and market research, but it is not verified against an external ground truth. Numeric values cited in AI narrative must correspond to source-linked extracted values in the deal record; reviewers should verify that correspondence before sharing output with an IC or counterparty.
## Related [#related]
* [AI Assistant Overview](/docs/ai-assistant/overview) — where the assistant appears and day-to-day behavior
* [Data Isolation](/docs/security/data-isolation) — org scoping and share-link precautions
Always review AI-generated IC memo sections before sharing with your IC. EQUIRE drafts; humans approve.
---
# Context Vault (/docs/firm-memory/context-vault)
## What the Context Vault does [#what-the-context-vault-does]
The Context Vault stores firm institutional memory: investment criteria, underwriting discipline, and IC decision rationale from past deals. Reviewed patterns synthesize into a Firm DNA profile that injects into every deal analysis, IC memo draft, and AI response across EQUIRE.
## Patterns [#patterns]
Patterns are the core unit of institutional memory. Each captures a specific piece of investment judgment:
* **Buy box**: property types, markets, and deal sizes your firm targets
* **Underwriting discipline**: conservative assumption frameworks and analytical standards your IC has repeatedly enforced
* **IC decision rationale**: why specific deals were approved, including conditions attached
* **Pass criteria**: deal characteristics that disqualify an investment before diligence begins
Patterns go through a governance workflow before they influence AI outputs. Draft patterns, including AI-authored ones, are invisible to the assistant until a human promotes them.
| State | Meaning |
| ---------- | ---------------------------------------------------------------------------------- |
| `draft` | Newly created; not active. Does not influence AI outputs or Firm DNA. |
| `reviewed` | Approved by an org admin; actively shapes deal analysis, IC memo drafts, and chat. |
| `rejected` | Archived and excluded from synthesis and AI context. |
## Firm DNA Synthesis [#firm-dna-synthesis]
Firm DNA is your investment thesis in a structured, AI-readable form. EQUIRE assembles it by distilling reviewed patterns into a coherent profile covering buy-box criteria, underwriting discipline, IC preferences, and pass filters.
Run synthesis after reviewing a batch of new patterns. The resulting DNA injects automatically into deal chat, IC memo drafts, and the deal fitness view, giving the AI a calibrated picture of your firm's revealed preferences rather than a generic CRE benchmark.
## Auto-Capture from IC Decisions [#auto-capture-from-ic-decisions]
When you record an IC decision in EQUIRE, firm memory updates automatically:
* **Approved deals**: underwriting assumptions at the time of decision are locked and preserved as a notebook entry sourced to the IC memo
* **Rejected deals**: the pass criteria driving the rejection are captured as draft patterns for review
Both writes are idempotent. Recording the IC decision IS the memory action; no separate post-mortem is required.
## Historical Ingestion [#historical-ingestion]
Use **Historical Ingestion** to backfill memory from past IC memos already stored in EQUIRE. The system extracts outcome types, key assumptions, and decision rationale from each memo and creates draft patterns for review. No draft patterns become active until an org admin promotes them.
Access it under **Settings > Context Vault > Historical Ingestion**.
## Getting the Most from Context Vault [#getting-the-most-from-context-vault]
* Review patterns in batches after each IC cycle, not ad hoc
* Run synthesis after every three to five newly reviewed patterns
* Write patterns in specific, quantitative language: "We require a minimum 1.25x DSCR on senior debt at 75% LTV" outperforms "We are conservative on leverage"
* Reject patterns that no longer reflect your current thesis; they are archived, not deleted, and can be audited later
## Related [#related]
* [Deal Memory and Outcomes](/docs/firm-memory/deal-memory) — how IC decisions and deal outcomes accumulate over time.
* [IC Memo](/docs/workflows/ic-memo) — the workflow that generates IC decisions and feeds memory.
* [AI assistant overview](/docs/ai-assistant/overview) — how Firm DNA shapes AI responses across the platform.
---
# Deal Memory and Outcomes (/docs/firm-memory/deal-memory)
## What deal memory records [#what-deal-memory-records]
Deal memory records the results of past investment decisions: what you acquired, passed on, and why. These records feed back into Firm DNA synthesis and surface as context in deal analysis and IC memo drafts.
## Deal Outcomes [#deal-outcomes]
Each deal outcome captures the terminal state of an investment evaluation and the reasoning behind it.
| Outcome | Meaning |
| ---------- | ----------------------------------------------------------------------------------------------------- |
| `acquired` | Deal closed. Underwriting assumptions at the time of decision are locked and preserved. |
| `passed` | Reviewed but not pursued. Pass rationale is captured as a draft pattern for review. |
| `killed` | Advanced into diligence but terminated by the IC. Reason is recorded with a reference to the IC memo. |
| `lost` | Submitted an offer but the deal was awarded to another buyer. |
Outcome records carry the exact governed source of the judgment: IC memo ID, release version, and the specific review decisions that were resolved at the time of the decision. This provenance prevents fabricated or reconstructed history.
## Notebook Entries [#notebook-entries]
Notebook entries are structured notes on specific aspects of a deal. EQUIRE creates them automatically when IC decisions are recorded. Org members can also add entries manually from the **Institutional Memory** panel on the deal overview page.
Types of notebook entries:
* **decision**: Records the IC go/no-go with rationale and conditions
* **insight**: Captures a market, property, or sponsor observation for future reference
* **assumption**: Documents a key underwriting assumption and the evidence behind it
Notebook entries are sourced to a specific document, IC memo, or user action. They are not LLM summaries; they carry citations that can be audited.
## How Memory Accumulates [#how-memory-accumulates]
1. IC memo approvals create deal outcomes with recorded underwriting assumptions
2. IC memo rejections create draft patterns capturing the pass rationale
3. **Historical Ingestion** extracts knowledge from past IC memos in batches
4. Org admins and members can add manual notebook entries from the deal overview
All AI-generated patterns start as `draft` and require explicit review before they influence AI responses. No knowledge enters the active context without a human approval step.
## Viewing Institutional Memory on a Deal [#viewing-institutional-memory-on-a-deal]
The **Institutional Memory** panel appears on every deal overview page. It surfaces:
* Firm DNA facets relevant to the current deal's asset type and market
* Precedent deals with similar profiles and how they were decided
* Recurring IC questions raised on comparable past deals
The panel is read-only. It does not write memory; it consumes what has been reviewed and approved in the Context Vault.
## Privacy and Access [#privacy-and-access]
All memory is scoped to your organization. No patterns, outcomes, or notebook entries are shared across organizations.
* **Org admins**: can create patterns, run synthesis, review or reject draft patterns, and trigger Historical Ingestion
* **All members**: can view the Institutional Memory panel on deal overview pages and reference memory in AI-assisted chat
## Related [#related]
* [Context Vault](/docs/firm-memory/context-vault) — pattern governance and Firm DNA synthesis.
* [IC Memo](/docs/workflows/ic-memo) — the workflow that generates IC decisions and feeds memory automatically.
* [Data isolation](/docs/security/data-isolation) — tenant boundaries that scope memory to your organization.
---
# Firm Memory (/docs/firm-memory)
## What is Firm Memory? [#what-is-firm-memory]
Firm Memory is EQUIRE's system for storing your firm's investment knowledge and applying it to new deal analysis. Instead of starting each deal from a generic CRE benchmark, the AI reasons through your firm's own buy box, underwriting standards, and IC decision history.
Firm Memory has two layers:
* **Org-level memory** shapes AI analysis across all deals: patterns, Firm DNA, and the Firm Vault
* **Deal-level memory** records what happened on specific investments: outcomes, notebook entries, and IC decision rationale
## Org-Level Memory [#org-level-memory]
### Memory Patterns [#memory-patterns]
Patterns are structured, reviewable units of investment knowledge. Each one captures a specific piece of your firm's judgment:
| Pattern type | Example |
| ----------------------- | -------------------------------------------------------------------------------------------- |
| Buy box | "Target suburban office in the Sun Belt, 50K–500K SF, Class B or better" |
| Underwriting discipline | "Require minimum 1.25x DSCR at 65% LTV on all acquisitions" |
| IC preference | "IC has rejected every deal with a single tenant above 40% of NRI without a long-term lease" |
| Pass criteria | "Do not pursue deals with deferred capex above $15/SF without a renovation budget" |
Patterns go through a governance workflow before they influence AI outputs. Draft patterns are invisible to the assistant until an org admin promotes them to reviewed.
Run **Firm DNA Synthesis** after reviewing a batch of new patterns. The resulting profile injects automatically into deal chat, IC memo drafts, and the deal fitness view.
### Firm Vault [#firm-vault]
The Firm Vault stores full-text institutional documents: IC meeting transcripts, investment policy statements, partner decks, and research reports. Vault documents are indexed for semantic recall, so the AI can surface relevant precedents, policies, or prior analysis during deal review and chat.
Documents added to the vault are private to your organization and are never shared across tenants.
### Underwriting Discipline [#underwriting-discipline]
Underwriting Discipline tracks compliance across your last 10 closed deals. Reviewed patterns that define specific, measurable rules (DSCR thresholds, LTV caps, cap rate floors) generate a compliance rate. A "Clean" status means recent deals have been consistent with your stated discipline; drift signals where standards may be eroding.
## Deal-Level Memory [#deal-level-memory]
Each deal accumulates its own memory as it moves through the workspace:
* **Outcomes**: the terminal IC decision, including underwriting assumptions at the time
* **Notebook entries**: structured notes on market observations, key assumptions, and IC rationale
* **Precedent links**: connections to similar past deals surfaced in the Institutional Memory panel on the deal overview
## Governance Model [#governance-model]
All AI-generated memory starts as `draft` and requires an org admin to promote it before it influences AI responses. No knowledge enters the active context without a human approval step.
| Layer | Who writes | When it becomes active |
| -------------------- | ----------------------------------------------- | -------------------------------- |
| Memory patterns | Org admins (manual or AI-assisted distillation) | After admin promotes to reviewed |
| Firm Vault documents | Org admins | Immediately on upload |
| Deal outcomes | IC memo workflow (automatic) | Immediately on IC decision |
| Notebook entries | Org members (manual); IC workflow (auto) | Immediately on creation |
## Related [#related]
* [Context Vault](/docs/firm-memory/context-vault) — pattern governance, Firm DNA synthesis, and historical ingestion.
* [Deal Memory and Outcomes](/docs/firm-memory/deal-memory) — how IC decisions and outcomes accumulate over time.
* [IC Memo](/docs/workflows/ic-memo) — the workflow that generates IC decisions and feeds memory automatically.
---
# Data Isolation (/docs/security/data-isolation)
{/* LEGAL REVIEW REQUIRED before merge — see docs/documentation-page/docs-site-plan.md §5 */}
EQUIRE is a multi-tenant platform where tenant records are scoped to an organization. For **organization members** under ordinary authenticated use, there are no paths to read, modify, or enumerate another organization's deal-room data—the database and API layers enforce the same boundary together.
**Platform operators.** Authorized super-administrator accounts (internal engineering and support, contractually constrained) may use administrative tools that can reach across tenants—for example viewing another organization's pipeline when diagnosing an incident or validating a migration. Those capabilities are intentionally narrow; tenant users signing in day-to-day do not bypass organization membership.
## Organization Scope [#organization-scope]
Every deal, document, valuation model, IC memo, prospecting record, extracted data point, conflict, and audit event is owned by exactly one organization. Users belong to one or more organizations and have a role — admin, manager, analyst, or viewer — within each. Switching the active organization changes the entire visible record set: deals, documents, rent roll data, sourcing results, audit logs, and team membership all reflect the selected organization and nothing else.
## How Isolation Is Enforced [#how-isolation-is-enforced]
### Database-Layer Row Security [#database-layer-row-security]
Database-level row security policies tie tenant rows to **your active organization**. Many tables store an explicit `org_id`; others inherit scope through their **deal** (the deal carries the org, and child rows inherit access via joins in policy definitions). Postgres evaluates these policies when the API uses cookie-authenticated sessions that respect Row Level Security—so ordinary sessions cannot widen the tenant boundary purely in application code.
**Operational jobs.** Automated tasks (cron, webhooks, and similar) run with privileged server contexts that intentionally bypass tenant session semantics; they operate only on narrowly scoped payloads and guarded routes—not on arbitrary browser sessions.
### Application-Layer Checks [#application-layer-checks]
Application-level checks add a second layer for authenticated product routes. Organization- and deal-scoped endpoints verify membership and deal access **before** returning or mutating data. Public routes (`/docs`, OAuth discovery, cron with secrets, authenticated party uploads, etc.) follow separate contracts documented on those flows.
Platform super-administrator accounts may bypass some membership gates for cross-tenant troubleshooting; tenant users remain bound to memberships and roles.
### Independence of the Two Layers [#independence-of-the-two-layers]
Together, Postgres RLS and these API checks provide defense in depth: a buggy filter in one route does not **by itself** mean the tenant database will serve another customer's rows through a cookie-bound Supabase client. Operational service paths are a deliberate exception layered on top—not something a normal user's browser session inherits.
{/* LEGAL: verify that the description of the RLS layer as independently enforceable from the application layer is accurate for all current production tables, and that no table in the credeals schema is missing org_id scoping */}
## Authentication and Access [#authentication-and-access]
### Login and Signup [#login-and-signup]
EQUIRE uses email and password login. New accounts are created through an OTP-verified signup flow: after submitting an email and password, users confirm their address via a one-time code before any organization or deal data is provisioned. Password reset is handled by a recovery email sent to the registered address.
### Session and Invite Scoping [#session-and-invite-scoping]
Login sessions are scoped to one user. Invite flows are scoped to one organization: an invitation is issued for a specific organization and can only be accepted by the invited email address. Invitations expire after seven days.
## What Is and Is Not Shared [#what-is-and-is-not-shared]
### Not Shared Across Organizations [#not-shared-across-organizations]
Nothing specific to your organization's work is shared across organizations. The following are not shared across organizations: deals, documents, extracted data, valuation models, assumptions, IC memos, deliverables, rent roll data, prospecting results, sourcing profiles, origination briefs, audit logs, comments, team membership, organization roles, and invite records.
### Shared Infrastructure [#shared-infrastructure]
What is shared is the underlying platform infrastructure — application code, the database cluster, hosting, and upstream services (including retrieval used by AI features within the safeguards described under [AI Trust and Safety](/docs/ai-assistant/trust-and-safety)). Another organization's authenticated session cannot see your records unless you explicitly share outside the tenant boundary (such as publishable URLs in the callout below).
**Deal share links** (overview vs. full snapshots) and **deliverable share links** expose read-only payloads to whoever holds the URL—no login required. Treat the URL as secret: anyone who receives it within the expiry window can retrieve the preview the link was generated for.
Revoke links from authenticated deal/workspace flows (deal-level sharing controls and the Deliverables workspace for packaged outputs). Disabled or expired links stop working at the edge; rotating or deleting tokens is safer than resharing casually.
{/* LEGAL: verify that AI model providers used by EQUIRE (accessed via Vercel AI Gateway) do not train on submitted data under current agreements, and confirm appropriate contractual protections are in place for customer data submitted to third-party AI providers */}
## Audit and Observability [#audit-and-observability]
Many material actions are recorded in an append-only audit trail scoped to your organization. Typical entries include deal creation and deletion, document upload and processing, data export, team membership changes, organization switches, account deletion requests, and share-link lifecycle events. Audit records carry a timestamp, user identifier where applicable, organization identifier, and action type. Opening a publishable share link increments **analytics on that link row** (for example view counts); those opens are **not necessarily** mirrored one-for-one into the audit trail. Organization admins review audit activity for their tenant in product surfaces designed for compliance visibility.
### Immutability [#immutability]
Audit rows are inserted, not rewritten after the fact—they are tamper-evident records of what the system logged, not editable history.
## Account and Data Deletion [#account-and-data-deletion]
### EQUIRE-Only Deletion [#equire-only-deletion]
An immediate deletion removes the user's identity and access from EQUIRE while leaving the organization and its deals intact — any remaining org members retain access to the existing records.
### Full Deletion [#full-deletion]
A full deletion removes the user's identity from all connected platforms and goes through a seven-day grace period before executing; the grace period allows the user to cancel if the request was made in error. The grace period applies only to the full deletion path; the EQUIRE-only deletion is immediate.
### Removing a Member [#removing-a-member]
Organization admins can remove members from their organization at any time. Removing a member does not delete the organization's records.
{/* LEGAL: verify whether the seven-day grace period and the specific deletion scope descriptions are contractually accurate and consistent with any privacy policy or DPA language currently in use */}
---
# Privacy & Deletion (/docs/security/privacy-deletion)
{/* LEGAL REVIEW REQUIRED before merge — see docs/documentation-page/docs-site-plan.md §5 */}
This page summarizes **account-level deletion and retention at a glance**. For **tenant isolation**, row security, publishable links, and AI handling, see [Data isolation](/docs/security/data-isolation) and [AI Trust and Safety](/docs/ai-assistant/trust-and-safety).
EQUIRE distinguishes between **your user account** (identity, memberships, credentials) and **organization-owned records** (deals, documents, valuations, workflows). Closing your account affects the first; deal-level data stays with the organization unless admins take separate org-level actions.
## Organization-Owned Deal Data [#organization-owned-deal-data]
**Deals and their contents belong to your organization**, not to an individual login. Removing a person's access does not delete historical deal artifacts the org still needs for compliance or continuity — other members with appropriate roles keep working normally.
That means:
* **Leaving or losing access** to EQUIRE typically removes *your ability to view and act*, not necessarily every row of business history the org retains.
* **Org admins** manage membership; they can remove a member without deleting deals or documents.
If you believe data should be purged beyond these defaults, escalate through your organization's administrator or formal data-rights request channels per your agreements with Agentic Assets.
## Removing a Member [#removing-a-member]
An organization administrator can revoke a user's membership **at any time**. That user's session loses access to the org immediately. **This action does not delete** the organization's deals, documents, or audit history.
## EQUIRE-Only Account Deletion [#equire-only-account-deletion]
**EQUIRE-only** deletion is designed for situations where someone should stop using EQUIRE altogether while **the organization keeps operating**.
What it does (plain language):
* Removes your memberships and profile from **EQUIRE** for your account.
* **Does not delete** organizational deal rooms, uploads, valuations, IC memos, deliverables, or similar org-scoped artifacts.
* **Does not necessarily remove** identifiers from every historical diagnostic row everywhere in the tenant database where engineering audit patterns apply — product surfaces are rebuilt so you cannot return under the same linkage.
This path completes **promptly once confirmed** — there is **no grace period** for EQUIRE-only deletion.
Depending on tenancy rules at the moment you request deletion, **you cannot use this option** if doing so would leave an organization without a valid administrator pathway; the product prompts you to **transfer responsibilities or resolve the organization** before continuing.
## Full Account Deletion [#full-account-deletion]
**Full** deletion aligns with broader **identity erasure**: your ability to authenticate is removed from the coordinated stack, alongside **controlled cleanup** tied to our cross-platform deletion program (shared identity plane with sibling products).
What to expect:
* **Scheduling and grace period.** When you confirm a full deletion request, the product queues the work behind a **multi-day grace window** during which you remain able to cancel. The grace applies **here**, not twice across platforms initiating the handshake.
* **After the window.** The pipeline removes access and scrubs linkage according to shipped deletion logic — still subject to organizational ownership rules below.
* **Org-owned assets persist.** As with EQUIRE-only removal, deal rooms and attachments **remain with the organization** where your contract and product design treat those as organizational records unless your master agreement spells out an exception.
If you initiate from EQUIRE while another linked profile has conflicting admin constraints, routing may halt with remediation instructions — analogous checks exist on reciprocal platforms.
{/* LEGAL: confirm grace-period length and copy match privacy policy / DPA; confirm permissible description of coordinated identity deletion without overstating purge of business records owned by tenants */}
## What This Page Does Not Cover [#what-this-page-does-not-cover]
Operational details intended for engineers — cryptographic service authentication between platforms, webhook contracts, exhaustive table maps, and remediation runbooks — live in internal documentation and are typically shared **under NDA** for diligence.
## Related [#related]
* [Data isolation](/docs/security/data-isolation) — tenancy, share links, audits
* [Subprocessors & AI](/docs/security/processing-ai-data) — AI routing and contractual posture
* [AI Trust & Safety](/docs/ai-assistant/trust-and-safety) — human checkpoints for AI-mediated outcomes
---
# Subprocessors & AI (/docs/security/processing-ai-data)
{/* LEGAL REVIEW REQUIRED before merge — see docs/documentation-page/docs-site-plan.md §5 */}
Workflow behavior — **what humans must approve**, **chat guardrails**, and **provenance (`TrackedValue`)** — stays on [**AI Trust and Safety**](/docs/ai-assistant/trust-and-safety). Use this page for **security questionnaires** focused on ingress/egress, subprocessors, and retention posture.
Tenant boundaries and ordinary product isolation are summarized on [**Data isolation**](/docs/security/data-isolation).
EQUIRE executes AI workloads primarily through **hosted inference endpoints** routed by **our application configuration**. The exact contractual stack — Vercel, Supabase, model vendors, ancillary email or search tooling — attaches to **your order form**, **Master Agreement**, and **Data Processing Agreements (DPAs)** with Agentic Assets. **Published marketing copy cannot replace those instruments.**
## AI Routing Snapshots [#ai-routing-snapshots]
### Vercel AI Gateway Path [#vercel-ai-gateway-path]
Deployments that supply **Gateway credentials** send eligible model traffic via the **Vercel AI Gateway** using EQUIRE-controlled **`providerOptions`**. Where that bundle includes **zero-retention-aligned** Gateway settings (`zeroDataRetention` in application wiring), procurement teams routinely map this to questionnaire answers about ephemeral Gateway handling — subject to verifying the **matching request shapes** actually attach the bundle in production telemetry.
### Direct Provider Path [#direct-provider-path]
Some deployments deliberately talk to **Anthropic** (and potentially other vendors) **without** traversing Gateway. Those paths **do not inherit** the same Gateway option bundle automatically; diligence must reference the **effective provider routing** stamped for that environment and align answers with Anthropic/supplier contractual terms supplied under NDA.
{/* LEGAL: verify Gateway vs direct matrix for prod + staging; reconcile with master agreement representations */}
## Auxiliary AI-Related Processing [#auxiliary-ai-related-processing]
* **Embedding and retrieval workloads** may follow different code paths today; parity with conversational traffic is **a stated engineering goal**. Treat embeddings as **explicitly validated** items in questionnaires until uniformity is evidenced.
* **Document storage** referenced by retrieval remains **tenant-scoped** per [Data isolation](/docs/security/data-isolation).
### Not Used for Discretionary Model Training [#not-used-for-discretionary-model-training]
Across standard routes documented for customers, payloads are exchanged for inference — **not offered to improve foundation models**. Contractual exclusions and SOC reports from vendors underpin precise wording supplied under NDA rather than summarized here verbatim.
{/* LEGAL: align with actual Anthropic/OpenAI/Gateway DPAs — public page must not overstate exclusions */}
## Representative Subprocessors [#representative-subprocessors]
Institutional SaaS footprints evolve; always request the **live subprocessor register** packaged with onboarding or compliance questionnaires. Typical categories surfaced in diligence decks include:
| Category | Representative vendors referenced internally |
| ------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Hosting & edge runtime | **Vercel** |
| Database / auth backbone | **Supabase** |
| Inference (Gateway route) | **Vercel AI Gateway** bridging to Claude and, when enabled, opt-in frontier pilots (e.g. xAI Grok 4.5 — selectable when platform ZDR is off; no Gateway ZDR route while ZDR is on) |
| Inference (direct route) | **Anthropic**, others per deployment |
| Org BYOK (optional) | Customer-supplied **Anthropic** or **OpenAI** API keys only — not xAI; Grok (when enabled) uses managed Gateway credentials |
Payment processors (**Stripe**) and ancillary tooling (**email delivery**, observability vendors) attach to ancillary flows unrelated to conversational AI routing but still merit subprocessor questionnaires.
Vendor certification snapshots, framework mappings, and customer-specific security questionnaire packets are maintained as refreshed **customer security packets** shared under NDA. Agentic Assets does not claim a certification unless the corresponding completed report or certificate exists.
## Contractual Supremacy [#contractual-supremacy]
If anything on this web page differs from negotiated terms, **your executed agreements and vendor DPAs prevail**. Procurement teams needing audit-grade artifacts — subprocessors appendix, questionnaires, SOC reports — should engage **[security@agenticassets.ai](mailto:security@agenticassets.ai)**.
## Related [#related]
* [AI Trust & Safety](/docs/ai-assistant/trust-and-safety) — human checkpoints and product narrative for AI-assisted workflows
* [Privacy & deletion](/docs/security/privacy-deletion) — account scopes, grace periods, org-owned deals
* [Data isolation](/docs/security/data-isolation) — org scoping and deliberate sharing mechanics
---
# Comparables (/docs/workflows/comparables)
The **Comparables** tab (under *Market Research* on a deal) shows two lanes of evidence for the subject property side by side:
* **Sold — CMBS:** transacted comps from securitized deals (SEC EDGAR ABS‑EE filings) — i.e. what properties *actually sold for*.
* **Asking — Listings:** active broker listings from EQUIRE's global indexed inventory — i.e. what comparable properties are *currently asking*.
Each lane shows its median cap rate and price per square foot, and the header surfaces the **asking‑vs‑sold cap spread** (asking median − sold median, in basis points) so you can see at a glance whether the market is asking above or below where comparable deals traded.
Click any comparable's name to open a detail popup with everything EQUIRE has on it — pricing, size, NOI, occupancy, parties, provenance, the source listing link, and the full match‑score breakdown. Use **Pin** to add a comp to the deal's **Comparable Sales** deliverable.
## How the comparable score is calculated [#how-the-comparable-score-is-calculated]
Comps are matched in **two stages**. Both are deterministic — there is no AI or black‑box similarity model, so every score is explainable.
### Stage 1 — candidate selection [#stage-1--candidate-selection]
Before scoring, each lane pulls candidates that already share the subject's **geography and property type**:
* **Sold (CMBS)** is anchored to the subject's metro (CBSA, falling back to state) and filtered to the subject's canonical property type.
* **Asking (Listings)** is anchored to the subject's state and filtered to the same canonical property type (only priced for‑sale listings qualify).
### Stage 2 — the 0–100 match score [#stage-2--the-0100-match-score]
Every candidate is scored against the subject. The total (the **Match** chip in the table) is the sum of five weighted factors:
| Factor | Max | How it scores |
| ---------------- | --- | ---------------------------------------------------------------------------------- |
| **Location** | 25 | same city **25** · same state **15** · otherwise **5** |
| **Size (SF)** | 25 | within 10% **25** · within 25% **20** · within 50% **12** · otherwise **5** |
| **Type** | 20 | same property type **20** · otherwise **3** |
| **Age** | 15 | within 5 yrs **15** · within 10 yrs **10** · within 20 yrs **5** · otherwise **2** |
| **Price ($/SF)** | 15 | within 15% **15** · within 30% **10** · within 50% **5** · otherwise **2** |
Lanes are sorted by total score, duplicates are removed, and the top comps are shown. The per‑factor values appear in each comp's detail popup.
### When a factor has no data [#when-a-factor-has-no-data]
A factor whose inputs are missing scores a **neutral default** (not zero), so it neither helps nor hurts the match:
* Location 10 · Size 12 · Type 10 · Age 7 · Price 7
This is why the score is only as discriminating as the subject's known attributes. A deal that has a city, state, and property type but **no building size, year built, or contract price** will see most comps cluster at a similar score (location + type carry the result). Once the deal carries size, year built, and price, the size/age/price factors engage and the scores spread out — a 1.2M‑SF tower no longer ties a 40k‑SF building.
## Notes and limits [#notes-and-limits]
* **Geography is metro/state, not radius.** Same‑metro lifts the Location factor to its max; there is no true distance‑weighted proximity yet.
* **The Type factor is effectively pass/fail** (20 for a match, 3 otherwise) — there is no partial credit for adjacent types such as office vs. medical office.
* Cap rates throughout the Comparables surface are stored and displayed as decimal fractions (6.5% = `0.065`).
---
# Deliverables (/docs/workflows/deliverables)
Deliverables are **stakeholder-specific outputs** built from the same underwriting stack as the IC memo, with explicit **audience modes** that change tone and emphasis.
## Deliverable types [#deliverable-types]
* Executive Summary
* Risk Assessment
* Loan Package
* Comparable Sales Report
## Audience modes [#audience-modes]
* **IC / Internal**
* **LP**
* **Lender**
* **Broker / Seller**
Audience selects tone, emphasis, and what to exclude — without maintaining four separate manual documents from scratch.
## Build flow [#build-flow]
### Create [#create]
Pick **type**, **audience**, and a **name**. The app materializes a **section template** for that combination.
### Generate sections [#generate-sections]
For each section: status moves **pending → generating → generated** (or **error**). The platform assembles a data bundle from deal schema, valuation, market context, and optional research, then runs type- and audience-specific prompts.
### Refine [#refine]
Submit natural-language refinements per section. Refined content becomes the active version (prior text may be versioned depending on product state).
### Edit and finalize [#edit-and-finalize]
Manual edits and section-level review happen in the builder UI before export.
### Export [#export]
Supported formats include **DOCX**, **PDF**, and **PPTX**. Export requires at least one generated section with content.
## Operating standard [#operating-standard]
Refresh high-impact sections (**financials**, **risk**, **recommendation-class** language) after major valuation updates or conflict-resolution passes on extracted data.
## How this differs from the IC memo [#how-this-differs-from-the-ic-memo]
The **IC Memo** tab produces the twelve-section committee narrative without a per-memo audience switch. Deliverables reuse the same facts but optimize packaging and tone for each external reader. See [IC Memo](/docs/workflows/ic-memo).
## Related [#related]
* [Valuation DCF](/docs/workflows/valuation) — numbers underlying financial sections.
* [Document ingestion](/docs/workflows/document-ingestion) — provenance for extracted facts cited in deliverables.
---
# Document Ingestion (/docs/workflows/document-ingestion)
EQUIRE accepts supported file types (see below) and runs each document through a processing pipeline. Extracted values — occupancy, rent, NOI, tenant names, loan terms — link back to source documents and text snippets so you can verify without hunting through originals.
## Supported uploads and limits [#supported-uploads-and-limits]
Accepted extensions match the upload policy: `.pdf`, `.xlsx`, `.xls`, `.docx`, `.doc`, `.pptx`, `.ppt`, `.txt`, `.csv`, `.zip`. **PDFs** can be up to **100 MB**; **ZIP archives** can be up to **500 MB** (the container limit — document members use per-type caps: PDF **100 MB**, other supported docs **50 MB**, **500 MB** total extracted documents); other accepted types are capped at **50 MB** per file. **Images** (PNG, JPEG, WebP) dropped on the Documents page or extracted from ZIPs route to **Property Photos** (up to **12** per deal, **15 MB** each). Large multipart payloads may use direct-upload paths when the client exceeds the small form-data threshold (4 MB).
ZIP archives expand to supported CRE formats and property photos; nested zips and unsupported types are skipped per policy.
## Document types you can ingest [#document-types-you-can-ingest]
| Document type | Typical formats |
| ---------------------------- | --------------- |
| Offering memorandum | PDF |
| Rent roll | PDF, Excel, CSV |
| Operating statement / T-12 | PDF, Excel |
| Lease abstracts | PDF, Word |
| Loan and debt schedules | PDF |
| Purchase and sale agreements | PDF |
| Broker packages | PDF |
| Comp sheets | PDF, Excel |
| Presentations | PDF, `.pptx` |
## What gets extracted [#what-gets-extracted]
### Offering memorandum [#offering-memorandum]
Property identity (address, asset class, year built, total SF), asking price, in-place NOI, cap rate, occupancy, and tenant or lease abstracts included in the package.
### Rent roll [#rent-roll]
Tenant name, suite or unit, leased square footage, rents, lease commencement and expiration, renewal options, and recovery structure. Summary or aggregate rows (floorplan averages, grand totals) are filtered where the pipeline treats them as non-tenant rows.
### Operating statement / T-12 [#operating-statement--t-12]
Effective gross revenue, operating expenses by line item, NOI, and occupancy by period.
### Debt and loan schedules [#debt-and-loan-schedules]
Loan amount, rate, IO period, amortization, maturity, and lender where present.
## Pipeline flow (orchestration) [#pipeline-flow-orchestration]
Processing is driven by the document process route. At a high level, after **classification** and **extraction** (including verification substages), the run continues with:
1. **Reconciliation** — merge into the deal schema, detect conflicts, persist merged state.
2. **Artifacts and validation** — persist field candidates, decisions, and validation issues.
3. **Property sync** — align property metadata across documents where applicable.
4. **Valuation projection** — deterministic assumption seeding from the merged schema (`populateAssumptions` with AI inference skipped in this step). Full AI-heavy valuation work still happens when you open the **Valuation** tab and run the model builder; see [Valuation DCF](/docs/workflows/valuation).
5. **Chunking and embeddings** — text is chunked and embedded into `document_chunks` for retrieval after reconciliation (not between extraction and merge).
6. **Finalization** — document status, review issues, and downstream staleness (e.g. IC memo) are updated.
If wall-clock processing approaches the soft time budget, non-critical continuation work (**projection** and **embedding**) may be deferred to a follow-up job recorded on the ingestion payload rather than blocking the first response.
## Processing stages you may see [#processing-stages-you-may-see]
Document processing stages (enum `DocumentProcessingStage`) include, in order of progression:
`queued` → `classification` → `extraction` → `verification_deterministic` → `verification_llm` → `verification_evidence` → `reconciliation` → `projection` → `completed` (or `failed`). Ingestion jobs can also schedule continuation stages `embedding` and `projection` on the job payload when work is split across runs.
## Classification, extraction, and verification [#classification-extraction-and-verification]
Classification uses filename signals, content keywords, and model-based fallback when needed. Extraction uses native PDF handling or text parsing by format. Verification passes check extracted values against source evidence before reconciliation.
## Conflict detection [#conflict-detection]
When two documents disagree on the same field, EQUIRE records a **conflict** and routes it to the **Review** tab instead of silently merging. You choose the winning value or enter a manual override.
Documents are processed and stored within your organization's account. Do not upload material non-public information you are not authorized to handle in this environment. For how AI is used in processing, see [Processing AI data](/docs/security/processing-ai-data).
## Source provenance [#source-provenance]
### Field-level attribution [#field-level-attribution]
Fields in the deal record reference originating documents. On **Extracted Data**, opening a value shows the source document and the snippet that supported it.
### Manual overrides [#manual-overrides]
User-entered values take highest precedence in downstream valuation precedence and are marked as user-sourced.
## Reviewing conflicts [#reviewing-conflicts]
The **Review** tab lists open review items: data conflict items, source review items, and field check items. Field checks include low-confidence values, missing fields, clarifications, diligence confirmations, and financial verification work. Resolving them updates the deal schema and valuation inputs. Document review status is recomputed when conflicts are cleared (including auto-heal paths when issues are resolved).
The workbench lanes (`Blocking Data`, `Source Review`, and `Supporting Checks`) are a recommended order of operations over the same queue, not a second set of totals.
## Worker dispatch and admins [#worker-dispatch-and-admins]
Background workers can invoke processing with `x-worker-secret` validated against `PIPELINE_WORKER_SECRET` (and related internal headers). Preview deployments should set this secret if worker dispatch is required; ops details live in internal pipeline documentation, not in this user guide.
## Email and intake (optional path) [#email-and-intake-optional-path]
Inbound email with attachments can create or enrich deals via the intake pipeline (webhook-verified, org-resolved). User-facing surfaces include pending-attach flows (`GET /api/intake/pending-attach`, `PATCH /api/intake/[recordId]/dismiss`). Operational email setup is documented for admins in the repo's `docs/operations/email-setup.md`; it is not duplicated here.
## Limits and known gaps [#limits-and-known-gaps]
* **Non-English documents**: extraction targets English.
* **Scanned PDFs**: low-quality scans may yield partial extraction; higher-quality scans or alternative formats help. Vision-style reading may be attempted when the pipeline classifies a scan.
* **Rent roll summary rows**: aggregates may be filtered; restore missed real rows manually on **Extracted Data**.
* **Large documents**: processing continues in the background; watch the **Documents** tab for status.
### Reclassifying a misclassified document [#reclassifying-a-misclassified-document]
Reclassify and reprocess from the **Documents** tab without re-uploading when the type was wrong.
## After ingestion [#after-ingestion]
Resolved data feeds [Rent roll & financial data](/docs/workflows/rent-roll-financials) cleanup, then [Valuation DCF](/docs/workflows/valuation), [IC Memo](/docs/workflows/ic-memo), and [Deliverables](/docs/workflows/deliverables). For the full workspace tour, see [Getting started](/docs/getting-started).
---
# IC Memo (/docs/workflows/ic-memo)
## What an IC memo is here [#what-an-ic-memo-is-here]
An Investment Committee memorandum is the primary narrative for internal approvers. In EQUIRE, **one memo per deal** is composed from **twelve ordered sections** in the workspace: deal and valuation context, **AI streaming** where allowed, **structured team input** where required, and **Word export** when readiness gates pass.
## Twelve sections (canonical order) [#twelve-sections-canonical-order]
Product order matches the memo workspace:
1. **Executive Summary**
2. **Transaction Overview**
3. **Investment Thesis**
4. **Market Analysis**
5. **Property & Physical Condition**
6. **Tenancy & Lease Analysis**
7. **Financial Analysis**
8. **Financing Structure**
9. **Risk Factors & Mitigants**
10. **Operational Plan**
11. **Fund & Investor Considerations**
12. **Proposed Resolution**
### Sections that gate review [#sections-that-gate-review]
Five sections must be in a reviewable state for export readiness: **Executive Summary**, **Transaction Overview**, **Investment Thesis**, **Financial Analysis**, and **Risk Factors & Mitigants**.
## Team-authored vs AI-streamed [#team-authored-vs-ai-streamed]
Three sections require **team input before** any AI streaming runs:
* **Investment Thesis**
* **Risk Factors & Mitigants**
* **Operational Plan**
For these sections, streamed AI **generation** is disabled: the memo routes return **400** on generate attempts and do **not** open an SSE draft stream, even though the internal section config records a model name for other purposes.
The other nine sections are **AI-streamed** when you choose **Generate** (or **Regenerate** when stale), subject to gap detection.
### Model routing when streaming actually runs [#model-routing-when-streaming-actually-runs]
Internal `SECTION_CONFIGS` assigns **`opus`** to **Executive Summary** and **Market Analysis** and **`sonnet`** to the remaining streamable sections (including **Financing Structure**, **Financial Analysis**, and **Proposed Resolution**). During SSE, the UI phase text reflects that choice (“Writing with Claude Opus…” vs “…Sonnet…”). Section streams use `TIMEOUTS.icMemo` (`totalMs` / `chunkMs`) in the shared IC memo LLM client so long sections stay within reliable abort windows.
Because team-authored sections never hit the generate stream, their configured model label does **not** mean those sections are drafted via the streaming endpoint.
### Market analysis tooling [#market-analysis-tooling]
Only **Market Analysis** enables **web search** and **academic paper** tooling in the section streaming route — other sections do not get that bundle by default.
## Workflow in the deal workspace [#workflow-in-the-deal-workspace]
1. Open the **IC Memo** tab; the app loads or creates the memo for the deal.
2. Clear **data gaps** that block generation.
3. Complete **team input** for thesis, risk, and operational plan.
4. **Generate** each AI-eligible section; **mark sections reviewed** as QA completes.
5. Advance **memo status** through your process (submit, in review, approved) using header actions.
6. When deal or valuation data changes, affected sections may become **stale** and need regeneration.
## Export [#export]
* **Word (.docx)** is the supported export from the IC Memo tab. Options such as table of contents and summary table are passed through to the exporter per request/API shapes.
* **PDF** export is **not** implemented; use DOCX and convert externally if you need PDF.
Export is gated on approval and readiness: critical sections addressed, no sections stuck in the wrong review state, no stale sections, and no unresolved **critical** gaps.
## Citations [#citations]
Drafted content may include `[Source: …]` markers. In DOCX export, those become numbered references with a **References** appendix when citations exist.
Treat numeric and narrative claims as **draft** until verified against extracted data, valuation, and primary materials.
## Audience [#audience]
There is **no per-memo audience selector** in the IC Memo UI today. Tone comes from prompts, fund configuration, and your edits. Use [Deliverables](/docs/workflows/deliverables) when you need audience-specific external packages with explicit IC / LP / lender / broker modes.
## Related [#related]
* [Valuation DCF](/docs/workflows/valuation) — numbers behind financial and risk sections.
* [AI assistant overview](/docs/ai-assistant/overview) and [Trust and safety](/docs/ai-assistant/trust-and-safety) — how AI outputs are bounded in the product.
* [Data isolation](/docs/security/data-isolation) — tenant boundaries for memo content.
---
# Prospecting & Origination (/docs/workflows/prospecting)
## What prospecting is [#what-prospecting-is]
The Prospecting workspace discovers and triages acquisition opportunities against your mandate (asset type, geography, size, pricing, thesis) and converts qualified rows into **Screening** deal workspaces.
## In the app [#in-the-app]
Open **Prospecting** at `/prospecting`. Four tabs:
* **Decision Queue** — Ranked saved candidates, table/card layout, filters, snooze, dismiss, tags, source evidence, selected review, and convert.
* **Mandates** — Create, activate, tune, and run sourcing mandates. Mandate detail lives at `/prospecting/mandates/[mandateId]`.
* **Scout** — Deeper review for a selected queue prospect, plus temporary External Prospect Review for off-platform ideas.
* **Agent Ops** — Durable run stream, run history, recovery controls, and compact workflow diagnostics. Deeper workflow contracts live in Admin.
If no mandates exist, Prospecting starts with a brief first-run guide instead of dense queue metrics: create a mandate, review saved candidates in the Decision Queue, use Scout for evidence and gaps, then convert only prospects worth moving into Screening.
URL state can carry `profile`, `readiness`, `source`, `view`, snooze, and tag parameters for shareable views.
## Workflow [#workflow]
1. Define **Sourcing Mandates** (markets, property type, size, thesis, signals, exclusions).
2. Run active mandates; results deduplicate before the **Decision Queue**.
3. Triage with the queue toolbar; inspect each prospect’s **evidence ledger** and validation state.
4. Use **Scout** or **Prospecting Analyst** chat for structured answers.
5. When server conversion checks pass, **Convert to Deal** creates a **Screening** deal seeded from the prospect.
## Sourcing and evidence [#sourcing-and-evidence]
Runs follow mandate configuration. Evidence types include listings, broker OMs, public records, and filings for consistent filters and copy. Primary prospect sources anchor the ledger; if durable reads fail, the inspector may enter a read-only degraded mode with a synthetic primary — refresh or attach sources when that happens.
## Scoring and ranking [#scoring-and-ranking]
A deterministic **brief** and **prospect review** feed **validation gates** (identity, evidence, fit, timing). The Feed ranks using **`qualityScore`**, blending brief signals with gate outcomes (**warn** / **fail**). **Readiness** is a lane (e.g. ready for outreach vs needs validation), not a single numeric score.
| Concept | Role |
| ------------------- | ----------------------------------------------- |
| Brief-derived score | Heuristic 0–100 from fields and listing context |
| Mandate fit | Alignment with geography, type, size, thesis |
| Readiness | Gate-driven workflow lane |
| qualityScore | Feed ranking combining brief + gates |
## Acquisition mandate [#acquisition-mandate]
Mandates control asset types, geographies, size and pricing bands, thesis, required signals, and exclusions. Edits apply to subsequent runs and evaluations.
## Prospecting Analyst (`POST /api/assistant/prospecting-chat`) [#prospecting-analyst-post-apiassistantprospecting-chat]
Workspace-aware chat (feature attribution **`origination`** / surface **`prospecting-chat`**). Tools available to the model include:
`listMandates`, `searchProspects`, `getProspectBrief`, `listProspectSourcesTool`, `compareProspects`, `searchMandateMarkets`, `getMandateHealth`, `getProspectOwnerPath`, `listSnoozedProspects`, `getDigestPreview`, `snoozeProspect`, `addProspectTag`
**Mutations** (`snoozeProspect`, `addProspectTag`) use the AI SDK **approval** flow — confirm in the UI before they execute.
For how chat modes and approvals work across the app, see [Chat modes](/docs/ai-assistant/chat-modes), [Tools reference](/docs/ai-assistant/tools-reference), and [Trust and safety](/docs/ai-assistant/trust-and-safety).
### Scout Review advisor [#scout-review-advisor]
Optional advisor after deterministic material is available — useful for thesis, risks, and outreach framing. Rule-based fallback may show as **Rule-based Review** when the agent path is unavailable.
## Convert to deal — server enforcement [#convert-to-deal--server-enforcement]
**POST** `/api/sourcing/results/[resultId]/convert` rebuilds **brief → review → `conversionBlockersFor`** on the server. The API is the **source of truth**; client-side `canConvertProspect()` is UX-only.
* **409** if the prospect is **dismissed**.
* **409** with `{ error, blockers }` if validation blockers remain (e.g. prospect needs validation before conversion).
Resolve blockers from the response, refresh data, and retry. **PATCH** `/api/sourcing/results/[resultId]` rejects unsafe status downgrades (e.g. `deal_created → new`) with **409**.
## Digest and crons [#digest-and-crons]
* **Digest preview:** `GET /api/origination/digest/preview`
* **Preferences:** `GET` / `PATCH /api/account/digest-preferences` (`digestEnabled`)
* **Daily digest cron:** `GET /api/cron/prospecting-digest` — Vercel cron schedule `0 12 * * *` (UTC), bearer `CRON_SECRET`.
* **Unsnooze:** `GET /api/cron/unsnooze-prospects` — hourly (`0 * * * *`).
Turn the email digest on in **account / notification** settings, not inside Prospecting.
## Keyboard shortcuts (desktop) [#keyboard-shortcuts-desktop]
Wide layouts; suppressed while typing in inputs:
| Shortcut | Action |
| --------- | ------------------- |
| `g` `f` | Decision Queue tab |
| `g` `s` | Scout tab |
| `g` `m` | Mandates tab |
| `g` `o` | Agent Ops tab |
| `j` / `k` | Move cursor in feed |
| `Enter` | Open inspector |
| `c` | Convert selected |
| `x` | Dismiss |
| `s` | Snooze |
| `t` | Tags |
| `?` | Help |
## Related workflows [#related-workflows]
* [Document ingestion](/docs/workflows/document-ingestion) — first documents after conversion.
* [Valuation DCF](/docs/workflows/valuation) and [IC Memo](/docs/workflows/ic-memo) — later-stage work in the same deal.
* [AI assistant overview](/docs/ai-assistant/overview)
---
# Rent roll & financial data (/docs/workflows/rent-roll-financials)
After [Document ingestion](/docs/workflows/document-ingestion), most teams spend time in **Rent Roll** and **Extracted Data** normalizing what the pipeline extracted. Quality here directly drives [Valuation DCF](/docs/workflows/valuation) assumptions and [IC Memo](/docs/workflows/ic-memo) credibility.
## Questions this workflow answers [#questions-this-workflow-answers]
* Who pays rent, how much, and when do leases roll?
* How concentrated is cash flow by tenant?
* Is headline occupancy masking weak credit or near-term rollover?
* What does in-place T-12 performance imply for stabilized NOI and risk?
## Rent Roll tab [#rent-roll-tab]
* Loads tenant rows from the canonical deal schema.
* Sort by tenant, suite, SF, rent, start date, end date.
* **Inline edits** for quick cleanup; delete spurious duplicate rows from bad extraction.
* Spreadsheet export for offline review or sharing.
Edits flow: **inline edit → schema patch API → schema update → valuation / overview refresh**.
## Extracted Data tab (financial inputs) [#extracted-data-tab-financial-inputs]
Operating-statement coverage typically includes:
* Revenue lines (base rent, reimbursements, other income, EGI)
* Expense lines (taxes, insurance, utilities, repairs, management, total OpEx)
* NOI and related below-the-line fields when present
Use this surface to align T-12/T-3 periods with the documents you trust most.
## Link to valuation [#link-to-valuation]
The model consumes tenancy and T-12 signals for, among other things:
* Market rent and growth
* Stabilized occupancy
* Expense ratio and expense growth
* Leasing and downtime assumptions
**Re-run valuation** (or relevant analyst steps) after material rent-roll or NOI corrections so downstream assumptions and memos stay coherent.
## QA checklist before IC [#qa-checklist-before-ic]
1. Top tenants by rent / SF match source docs.
2. Major tenant lease expirations are correct.
3. Vacant vs occupied labeling is honest (no false occupancy).
4. Total SF and occupied SF tie out.
5. Operating period and NOI look reasonable for the vintage and quality story.
6. After large edits, refresh valuation and re-check scenarios.
## Common failure modes [#common-failure-modes]
* Duplicate tenants from multi-document merges.
* Missing lease ends from thin abstracts.
* Monthly vs annual rent unit confusion on manual fixes.
* Vacancy or pseudo-tenant rows mis-labeled as named tenants.
Fix in **Rent Roll** / **Extracted Data**, then re-run affected valuation work — see [Valuation DCF](/docs/workflows/valuation) for sensitivity and scenario behavior.
## Related [#related]
* [Document ingestion](/docs/workflows/document-ingestion) — extraction, conflicts, and review.
* [IC Memo](/docs/workflows/ic-memo) — narrative consumes these numbers.
---
# Valuation DCF (/docs/workflows/valuation)
EQUIRE's valuation workflow turns extracted deal data and market context into a transparent property-level DCF: assumption provenance, scenario comparison, sensitivity grids, and formula-based Excel export for institutional underwriting review.
## Model overview [#model-overview]
The DCF engine supports:
* Unlevered and levered returns (IRR, equity multiple, MoIC)
* Hold period 1–10 years
* Base, upside, and downside scenarios
* Structured capital stacks: all-cash, senior debt, bridge/construction future funding, senior + mezzanine, senior + preferred equity, and custom multi-layer financing
* Tenant-level lease schedules for office, retail, industrial, and similar income-property engines (hospitality maps through supported rent-roll paths)
* Unit-mix schedule for multifamily
* Other property types route through the platform’s classification rules (including mixed-use)
## Capital stack control [#capital-stack-control]
Valuation models store a structured capital stack alongside legacy financing assumptions. The structured stack is the source for senior debt, mezzanine debt, preferred equity, future funding draws, common-equity proceeds, DSCR, debt yield, and related covenant metrics.
Deal chat can help navigate and update this layer. For valuation financing questions, the assistant should call `getValuation` first so it can see the current stack and covenant outputs. For financing mutations, it uses approval-gated `updateCapitalStack` rather than a generic assumption edit. The tool accepts dollar amounts in millions and rates as decimals, then recalculates the base DCF and syncs the primary senior loan back to legacy financing assumptions.
Use `structureType="custom"` for combined senior + mezzanine + preferred equity stacks or other multi-layer structures that do not fit a single preset. Use `all_cash` to clear debt and preferred equity.
## Starting the model [#starting-the-model]
### Valuation Wizard [#valuation-wizard]
If no model exists, the **Valuation** tab offers **Start Valuation Wizard**. The wizard runs **Property Details**, **Investment Params**, and **Build Model**, pre-populating from extracted deal data.
### Analyst pipeline (10 steps) [#analyst-pipeline-10-steps]
During **Build Model**, `runModelBuilder()` runs ten sequential **AnalystStepId** steps. Progress streams in the UI. Step ids and labels (from `ANALYST_STEPS` in code) are:
| Step id | Label |
| ------------------ | -------------------- |
| `data_inventory` | Data Inventory |
| `tenant_deep_dive` | Tenant Deep Dive |
| `normalize_t12` | Normalize Financials |
| `reconcile` | Cross-Document Check |
| `market_context` | Market Assumptions |
| `tenant_cashflows` | Tenant Cash Flows |
| `stabilized_noi` | Stabilized NOI |
| `construct_dcf` | Final DCF |
| `risk_assessment` | Risk Assessment |
| `synthesis` | Synthesis |
The DCF recalculates several times during the build (after key milestones) so you can watch the model converge.
## Assumption inference and `SOURCE_PRIORITY` [#assumption-inference-and-source_priority]
Pipeline and UI respect a single precedence order (canonical `SOURCE_PRIORITY` tuple):
**`user` → `doc` → `analyst` → `research` → `fund` → `ai`**
* **User** edits always win.
* **Document extraction** outranks analyst and AI fills.
* **Fund** defaults outrank raw **AI** when both exist (fund policy should not be clobbered by a model guess).
Pipeline updates typically tag new fields as **analyst** or **research** where applicable.
### Typical inferred levers [#typical-inferred-levers]
* Market rent and rent growth — from T-12, rent roll, and market context
* Exit cap rate — from in-place cap, benchmarks, and asset quality
* Vacancy and credit loss — from occupancy and comparables
* Operating expense ratio — from normalized T-12
## Scenarios and reads [#scenarios-and-reads]
Three scenarios (**base**, **upside**, **downside**) ship by default. Scenario deltas apply at **read time** against the stored assumption set. Scenario-sensitive calculations in the product and export routes use `calculateScenarioDCF` / `resolveScenarioAssumptions` — do not assume “base-only” snapshots for exports.
### Hydration guardrails [#hydration-guardrails]
Treat **`hasModel: false`** or **missing/null model slices** in API responses as a hard signal to **reset** local valuation state (tenant schedule, T-12 slices, etc.), not to keep stale UI from a prior model. See `docs/valuation/valuation-contract.md` for the full contract.
## Sensitivity matrix: in-app vs Excel export [#sensitivity-matrix-in-app-vs-excel-export]
* **In-app** two-way sensitivity (`runSensitivityMatrix` in `dcf-engine.ts`) fills cells with **levered** IRR (`returns.irr`) and equity multiple — suited for quick scanning in the dashboard.
* **Formula Excel export** uses institutional conventions on the workbook’s sensitivity sheets: **Sensitivity Matrix 1** (exit cap × rent growth) drives **unlevered** IRR via the workbook’s `Ret_UnlevIRR` output — **not** the same IRR definition as the default in-app matrix corners.
Always label which surface you are looking at when comparing IRRs.
## Pre-configured scenarios [#pre-configured-scenarios]
| Scenario | Description |
| -------- | -------------------------------------------------------------------------------------------------------------- |
| Base | Central case from inferred and document-backed assumptions |
| Upside | Compressed exit cap, stronger rent growth and occupancy |
| Downside | Stretched cap, weaker growth, elevated vacancy, and related stresses (including debt pricing where applicable) |
## Excel export [#excel-export]
EQUIRE exports a formula-based Excel workbook (live formulas, not static dumps). Typical sheets include **Cover**, **Assumptions**, **Rent Roll**, **Operating Expenses**, **Cash Flow**, **Debt Schedule**, **Returns**, **Sensitivity**, **Sources** (and uses), plus internal **`_Schema`** and **`_Checks`** sheets. Named ranges connect assumptions to outputs.
### ORI and limits [#ori-and-limits]
Export preflight enforces row and structure guardrails (e.g. ORI rent-roll caps for non-multifamily types). Consult `valuation-contract.md` for current limits.
## Related workflows [#related-workflows]
* [Document ingestion](/docs/workflows/document-ingestion) — seeds extracted fields and runs pipeline projection before valuation work.
* [Rent roll & financial data](/docs/workflows/rent-roll-financials) — QA tabular inputs before finalizing the model.
* [IC Memo](/docs/workflows/ic-memo) — consumes valuation outputs for narrative sections.