Methodology

How DealVeto Screens Deals

DealVeto produces a screening directive in five steps: Land, Units, Revenue, Costs, Decision. Each step uses a constrained, deterministic engine — the same inputs always produce the same outputs.

Cost basis

Each cost estimate identifies its source, effective date, market, confidence, and saved version. Review the scope and assumptions alongside your project budget before relying on the result.

Customer-verified actuals are the preferred basis. Public references may support calibration, and modeled values are clearly marked as unsourced until validated. AI may explain the basis; it cannot author or silently change provenance.

Reference hierarchy & quarterly releases

Cost evidence is labeled by source class so a market signal cannot masquerade as a contractor-validated installed cost. DealVeto uses the following hierarchy:

1. Customer-verified actuals. Preferred calibration basis when the customer has authorized the project history for use.
2. Licensed references. Used only when separately contracted and identified; never implied to be DealVeto-owned data.
3. Official public signals. Used for context and escalation. BLS PPI indicates trend; it is not a local installed-cost source.
4. DealVeto screening benchmark. A directional multifamily screening band with geography, effective date, and confidence disclosed.
5. Modeled assumption. A visible placeholder requiring professional or customer validation before reliance.

During the pilot, Cost Basis Quarterly is the governance cadence for reviewing benchmark, escalation, geography, and methodology changes. Each release is intended to carry an effective date, version, change log, and validation notes. BLS Producer Price Index data is used only as escalation context—not as a local subcontractor bid, unit price, or installed-cost source.

No silent rebasing: Existing deal versions keep their original cost basis until a user explicitly adopts a newer release.

Organization knowledge & AI data policy

DealVeto's preferred architecture is approved-source retrieval, not shared-model training: Retrieve from approved organization sources at answer time instead of training a shared model on raw customer files. The deterministic screening engine remains the calculation authority; AI can explain a result, surface a cited internal reference, or draft a memo, but it cannot silently rewrite a cost basis or approve a change.

Customer deal data is not used to train a shared cross-customer DealVeto model by default.

Roadmap, not a current entitlement. Customer-specific organization knowledge will not be represented as generally available until workspace isolation, admin-approved sources, source-level audit, retention, deletion, and export controls are production-enforced. Any future fine-tuning would be opt-in, customer-specific, versioned, evaluated, and reversible.

Key metrics & formulas

Yield on Cost (YOC)

Stabilized NOI ÷ Total Development Cost. The development's unlevered return on cost; compared against the exit cap to read the development spread.

Total Development Cost per unit (TDC/unit)

Total Development Cost ÷ unit count. All-in cost (land + hard + soft + contingency + fees + financing) per residential unit.

Hard cost per GSF

Hard construction cost (shell + sitework + structured parking) ÷ gross square feet — the benchmark-comparable construction intensity.

Cost basis glossary

Cost overrides in Deal Repair are per-line total dollars (they replace a line's baseline total — never a $/unit or $/GSF input). The progression runs DealVeto Baseline → Development Override → Precon Leveled → Current Basis.

DealVeto Baseline

The system-generated cost basis from regional product/structure benchmarks. It is never mutated by an override — it is preserved for comparison and audit.

Dev Override Total $

A development-side total-dollar override applied to a single cost line (e.g. a re-traded land basis or a repriced shell).

Precon Leveled Total $

A preconstruction-reviewed total-dollar value for a line; it takes precedence over a development override when present.

Current Basis

The resolved per-line basis (Precon Leveled → Dev Override → Baseline) that the economics and verdict read from.

Invalid Cost Basis / Review Required

When an override fails a sanity floor (e.g. a line collapsed to an implausible value, a large TDC drop, or a cost/unit below the floor), the basis is flagged Review Required and the verdict is held — it can never upgrade out of an invalid basis.

Override safety & report basis disclosure

Override safety: overrides are entered as drafts and must be explicitly applied; suspicious moves (a multi-million-dollar line dropped to a sub-$1M total) prompt a confirmation, and the DealVeto Baseline is never overwritten. An invalid current basis can never upgrade the recommendation to Proceed.

Report basis disclosure: reports and IC memos disclose the cost basis they rest on — applied-override count, an exact override audit, and a Review Required banner when the basis is invalid — and preserve the DealVeto Baseline recommendation separately. The on-screen economics are always shown; only the recommendation label is gated.

Site Fit caveats

Site Fit produces a conceptual program and massing for screening — acreage, unit yield, and parking are directional, not survey- or code-verified. DealVeto does not confirm the following; validate each independently before relying on it:

• Zoning / entitlement compliance — confirm with the jurisdiction and the approved entitlement set.
• Survey boundaries and acreage of record — confirm with an ALTA survey; drawn/site-fit acreage is conceptual until verified.
• Civil, grading, and utility layout — confirm with a civil engineer.
• Parking count and parking-code compliance — confirm against the zoning code and a parking study.

Methodology foundation — standards & references

DealVeto's screening framework aligns with building and general construction estimating practice. We document a Basis of Estimate, preserve the original concept baseline, and record each approved change without silently restating an older decision — we do not license proprietary cost data.

• Estimate classifications. A DealVeto directive is an early feasibility read. Estimate class and expected accuracy depend on the maturity of project definition; DealVeto follows the building and general-construction framing in AACE 56R-08 rather than borrowing ranges from process industries.
• Cost band methodology. Baseline ranges are calibrated from customer-authorized project actuals and permitted public references. Proprietary third-party cost tables are not presented as DealVeto provenance.
• CSI MasterFormat and Uniformat. Cost structure supports decision-level Uniformat rollups and CSI trade detail. The estimate hierarchy can later be mapped into an approved project or ERP structure without forcing the screening model to imitate an execution system.
• Estimate control. The original concept baseline, current applied basis, delta, contingency, status, and approval history remain distinguishable. This preserves the useful construction-control discipline of an enterprise system without bringing procurement, billing, or field controls into the MVP.

What screening output is and is not

A DealVeto directive is a conceptual screening estimate and decision memo, not a bid or cost commitment. It exists to decide which deals deserve full underwriting and preconstruction attention, which need structural adjustment, and which should be declined.

Outputs are not a substitute for:

• A contractor bid or GMP
• A complete capital underwriting model
• A signed investment-committee authorization

All DealVeto outputs require professional validation before IC, DD, GMP, or lender reliance.

What the screening engine does not do

• It does not run on open-ended AI generation. The engine is constrained and auditable.
• It does not recompute on tab changes, tier switches, or section collapses. Only an explicit Run Screening action triggers calculation.
• It does not store inputs that have not been explicitly saved by the user.

Product navigation & information architecture

DealVeto keeps the daily workflow intentionally small. Advanced and legacy routes remain available for internal validation, but they do not compete with the primary decision journey.

• New Deal — capture the site, program, and starting assumptions.
• Budget — review and repair the cost and operating basis for the selected deal.
• Underwrite — screen, validate, and prepare the selected deal for a decision.
• My Deals — active pursuits, decision state, and the deals that need attention.

Not primary destinations (reachable from the deal, Help, the footer, or direct URL): Review Queue (/queue), Deal Repair (/workspace), reports (/reports), and Cost Methodology Lab (/cost-evm). Veto is the one shared assistant shell; /assistant is only a compatibility launcher into that shell.

Future consolidation path

• Review Queue → a My Deals filter
• Deal Repair → a Budget module
• Cost Methodology → Help / Methodology
• Legacy assistant links → Veto compatibility launcher