Process & methodology, end to end

What it is

The set of rule files and templates that govern how DDs are done — the twelve acquisition criteria, the ten-layer review template, the comp database, the charge sheet, every SKILL.md our skills run from. Lives under project-starter/.claude/skills/. Current release version: v3.0.0.

What gets recorded at run start

• The git commit SHA of the methodology repo at run-start moment.
• A SHA-256 hash manifest of every rule file the run will read.
• A full copy of those rule files into the deal's 01_methodology/ subfolder.
• The FX-rate snapshot for the analyst's chosen target currency (see sub-step 2 below). The FX rate is fetched before the methodology snapshot is sealed; the manifest hash incorporates the FX-rate-snapshot file so any change to the rate (or the source it came from) invalidates the snapshot. A re-run under the same methodology version reproduces the exact same rate.

Why a copy AND a hash AND a SHA

Three layers because each fails differently. The git SHA tells you what was committed. The hash manifest tells you what was actually loaded (catches mid-run edits, hot-reloads, mis-syncs). The file copy means the rule files survive even if the repo is rewritten later. Version labels alone (v3.0.0) are a name, not a snapshot — if anyone edits the rule files later, v3.0.0 no longer means what it meant when the run ran. The point of versioning is to be able to re-run an old deal under its original rulebook; that needs the rulebook itself, not the rulebook's name.

Where the stamp lives

In the runs table as structured columns (methodology_version, methodology_git_sha, methodology_manifest_hash), and as an immutable 01_methodology/manifest.json file in the deal's Drive folder. Both are written before any analytical phase fires.

The methodology is documented inline above (Commitments through HITL gate). This page is the canonical methodology + process document.

What gets recorded

• The analyst's identity (Google OAuth subject — only @ecomma.co emails are allowed past login).
• Run start time in UTC.
• The HubSpot deal ID the analyst attached at intake — mandatory. Phase 0 refuses to start without one because the recall step depends on it.
• The target slug — lowercase, hyphen-joined slug of the legal name. Collisions on (date, target) get suffixed with the run ID short hash.
• The analyst-chosen target currency for this run — selected on the New DD form at intake. Every numerical threshold and every financial figure produced downstream is normalised to this currency. The system never picks the currency on the analyst's behalf; it must be specified per run.

Currency normalisation policy

Currency normalisation is mandatory but never a system decision. Four rules:

• The analyst chooses the target currency at intake — USD, EUR, GBP, AUD, or any ISO 4217 code Ecomma operates against. The engine surfaces this as a required field on the New DD form; there is no default.
• Every monetary figure is persisted in both the original currency and the normalised currency, with the FX rate and FX source recorded on the claim. Source-tier is [derived] on the normalised figure with the conversion shown.
• The FX rate is captured before the methodology snapshot is sealed — Phase 0 sub-step 1's manifest hash includes the FX-rate-snapshot file. This means the FX rate is part of the immutable run baseline, not a side effect: a re-run six months later under the same methodology version uses the same FX rate, not the spot rate at re-run time. Runs are reproducible.
• If the FX source is unreachable at run start, the run does not proceed silently — Phase 0 surfaces the FX-fetch failure on the deal page and the analyst chooses (a) retry, (b) supply the rate manually with explicit source citation, or (c) abort the run. There is no fallback to a stale cached rate; reproducibility requires that the rate's source is named at the time it was captured.

Concurrent-run guard

Before Phase 0 proceeds, the engine checks for any in-flight run on the same HubSpot deal ID. If one exists, the analyst chooses: abort the new run, force-start anyway (logged with reason), or resume the in-flight run. Two analysts diligenceing the same target at the same moment is rare but the failure mode is silent double-spend on API quota and contradictory artefact files — better caught here than in Phase 12.

File-naming convention this anchors

What HubSpot is

HubSpot is the database where Ecomma tracks every deal it has ever looked at — name, founder, status, prior verdict, reason codes, notes.

Token preflight first

Before the recall query, the engine validates the HubSpot OAuth token is still live. A revoked or expired token is a recoverable error — the analyst is asked to refresh the connection. If recall ultimately fails (token cannot be refreshed, API persistently down), the analyst chooses: abort the run, or proceed-without-recall. The choice is recorded in the run metadata as a known gap.

Match logic — three keys in order

1. Primary domain, canonicalised (strip www., lowercase, no trailing slash).
2. Founder email, exact match.
3. Fuzzy legal-name match, threshold-bound. Any candidate above threshold is presented to the analyst for confirmation, not auto-merged.

Multi-match cases are surfaced before the run proceeds — silent merge is a worse failure than asking.

Engine-own recall as the second source

HubSpot only knows about deals that made it into the CRM. The engine's own runs table knows about every run it ever started, including aborted ones. Phase 0 queries both — domain match, founder match, slug match — and joins the results. A target that aborted at Phase 1 four months ago and never made it into HubSpot still gets surfaced.

Aging the prior verdict

Prior verdicts are stamped with months-since-issued at recall time. A HARD PASS from 18 months ago is not the same signal as one from three weeks ago — past a threshold (provisionally six months) the verdict is marked stale — re-review recommended and does not block the new run on its own.

Re-engagement triggers

If the most recent prior verdict was HARD PASS within the freshness window, the engine checks re-engagement-triggers.md — one rule per reason code, listing the conditions that would unblock a re-pitch. If conditions are not all met, the engine flags it and the analyst gates the proceed.

What the HubSpot call looks like

The Drive folder URL

Provided by the analyst at intake — either the seller-shared folder or an Ecomma-side mirror. The engine cannot start without one.

OAuth scope discipline

The Drive token is scoped to read on this specific folder and its descendants — nothing broader. The engine refuses to start if the token has wider scope; the analyst is asked to re-authorise with a narrower grant. This is non-negotiable: the engine reads financials, contracts, and trademark certs in this phase, and broader scope is a confidentiality risk we don't accept.

Volume guard

Before ingestion, the engine counts files and bytes. If the folder contains more than the threshold (provisionally 2,000 files or 5 GB), the analyst is asked to confirm. Often this means the seller accidentally shared their entire Drive. The threshold is tunable; the guard exists so we don't burn quota classifying junk.

Rate-limit awareness

Drive API calls are paginated and back-off aware. Sustained 429s pause the ingest with a clear status on the deal page rather than aborting the run.

Chain-of-custody hashing

Every file gets SHA-256'd before any mutation — before classification, before OCR, before translation, before re-filing. The hash is stored in the run record alongside the file's Drive ID and Drive's reported modified-time. Six months later, if a question arises about what the seller originally provided, the hash is authoritative. Two files with the same SHA-256 are treated as the same file: ingested once, referenced twice. The seller's duplicate uploads don't double-count downstream.

What's rejected at intake

• Zero-byte files (logged, not ingested).
• Files whose format the engine doesn't handle (logged with reason, surfaced to the analyst).
• Malformed PDFs (detected on header parse; analyst notified).
• Encrypted or password-protected files (engine cannot proceed without the password — analyst is asked to supply it or remove the file).

Classifier mechanism — two layers

Layer one is deterministic: filename heuristics, MIME type, and content keyword matches against a catalogue of known patterns (e.g. "P&L" / "Profit and Loss" / "Income Statement" for financials; "Supplier" / "MOQ" / "Lead time" for operations). Layer two is an AI fallback for files that fail the deterministic pass — a small Claude call that returns category + confidence. Layer two is an AI cost in Phase 0; it's bounded to ambiguous files and each call is logged in the audit trail with token cost.

Classification failure mode

If a file cannot be classified by either layer with sufficient confidence, it's quarantined in 00_intake/_unclassified/ and surfaced on the deal page for manual classification. If any high-value file (a candidate P&L, audit, or balance sheet that the deterministic pass tagged ambiguous) appears unclassified, the run does not proceed past Phase 0 until the analyst resolves it. Silent classification failure is the worst possible outcome — a P&L misclassified as "marketing" never reaches Phase 2 and the financial model is built from incomplete data.

OCR and translation

Image-based PDFs and screenshots are OCR'd. Files in supported non-English languages are translated to English: Dutch, French, German, Spanish, Italian, Portuguese for initial scope. Languages outside this list are flagged for analyst review — the engine does not silently auto-translate languages it isn't calibrated for.

Service failure modes

If the OCR or translation service is transiently unavailable, the engine retries with exponential backoff. If the failure persists past the retry budget, Phase 0 aborts with an explicit error rather than silently skipping the affected files. A skipped translation means Phase 2 would later try to extract numbers from Dutch text and produce nonsense.

What is NOT verified in Phase 0

OCR confidence and translation accuracy on numeric content are not Phase 0's job. Phase 0 captures and preserves; Phase 2 verifies. The handoff is concrete: the original-language file is kept immutable under 00_intake/ with its hash; the OCR'd or translated file is written to 00_intake/_processed/ with provenance metadata (which OCR engine, which translation service, when). Phase 2 cross-checks numeric tokens between the original and processed versions before trusting either for the financial model.

Copy, never move

Classified files are copied from 00_intake/ into the typed folders. The intake folder is the immutable chain-of-custody record of what the seller actually provided. On a shared Drive folder where the seller has visibility, copying instead of moving also avoids reorganising the seller's own view of their files mid-conversation.

Multi-category files

A vendor MSA with payment terms is both legal and financial. The schema places each file in one canonical folder by tie-breaker (contracts go to legal > financial > operations) with a secondary-category metadata tag for retrieval. The taxonomy is single-folder but the metadata is multi-tag.

No graveyard category

The old 08_other/ bucket is gone. Files that don't fit the typed folders are quarantined in 00_intake/_unclassified/, forcing a manual classification decision rather than disappearing into a catch-all.

One-click reclassify

From the deal page, an analyst can reclassify any file. The reclassify action removes the prior typed-folder copy, writes a new copy to the correct folder, updates the file's category in the run record, logs the action in the audit trail (analyst identity + timestamp + before/after category), and re-fires any downstream phase that already consumed the file under the wrong category. The system is built to be corrected, not blindly followed.

Standard deal folder structure

Schema version

Folder Schema v1.0, introduced under methodology v3.0.0. Schema changes follow semver: minor versions add optional fields; major versions require an explicit migration script and re-classification of any affected runs. There is no silent breaking change.

Valid primary categories (closed enum)

• financials → 02_financials/
• commerce → 03_commerce/
• operations → 04_operations/
• legal → 05_legal/
• marketing → 06_marketing/
• crm → 07_crm/
• unclassified → 00_intake/_unclassified/ (quarantine; transient — not a permanent category)

The engine refuses to write a file with a category outside this enum. There is no catch-all bucket — files that don't classify go to unclassified for manual resolution, not into a permanent "other" folder.

Required fields per file record

• drive_file_id — Drive's authoritative ID
• sha256 — hash captured at ingest, before any mutation
• original_filename — as the seller named it
• ingested_at — UTC timestamp from the engine clock
• primary_category — one of the enum above
• status — one of: active, quarantined, rejected, superseded
• classifier_layer — deterministic, ai_fallback, or analyst (manual)

Optional fields

• secondary_category — for multi-category files (e.g. vendor MSA with payment terms)
• classifier_confidence — populated only when classifier_layer = ai_fallback
• processed_from — pointer to the 00_intake/ original, populated only for OCR'd or translated copies under 00_intake/_processed/
• processing_provenance — OCR engine name + translation service name + timestamp; populated only for processed copies
• reclassified_from — prior primary_category, populated when an analyst reclassifies a file

What gets rejected at write time

• Any file whose primary_category is not in the enum.
• Any file missing a required field.
• Any active file whose sha256 collides with another active file in the same run (in-run deduplication — collisions are referenced, not duplicated).

Migration policy

This is the target schema for the engine rebuild. The engine is pre-production at the time of this spec — no prior runs exist under this schema, so no backward-compatibility shim is required. Future schema changes follow semver and ship with explicit migration scripts.

Who reviews

Four vendors evaluate the intake bundle in parallel: Anthropic Claude (Opus 4.7), OpenAI GPT (5.5), Google Gemini (2.5 Pro), DeepSeek (V4 Pro). None is the orchestrator's training origin twice — independence is the point. Each vendor receives the same Phase 0 output bundle and the same eight-charge sheet; none sees the others' verdicts. Vendor identities are pinned by the methodology snapshot at run-start; flagship rotation stamps a new snapshot version.

Why this panel

Hygiene findings block the entire run before any analytical work fires, so coverage gaps at intake cost more than gaps at downstream checkpoints. The 4-vendor panel matches Phase 2.5 (financial-output sense-check) and Phase 12 (memo verdict review) so the same runQuadReviewWith primitive serves all three — one workflow, one vendor count. The ~30s additional intake latency is a once-per-run cost paid in exchange for the safety bias.

What they receive

Phase 0's full output bundle, structured: methodology snapshot + manifest, run identity record, recall results, ingest hashes + rejection log, classification log with confidence scores, OCR / translation provenance, re-filing log, schema-compliance status. Plus the eight-charge sheet (canonical source: app/src/orchestrator/charge-sheets/phase0_5_hygiene.ts). Each vendor returns per-charge votes plus an overall disposition.

Divergence is the signal

Where vendors return different votes on the same charge, the divergence is surfaced verbatim with all rationales side by side. Consensus is not engineered.

1. Methodology snapshot integrity — methodology_version + git SHA + manifest hash all present in the run record; rule-file copies present in 01_methodology/; manifest hash matches the actual files on disk.
2. Run identity completeness — analyst identity, UTC submission timestamp, HubSpot deal ID, and target slug all recorded; no concurrent in-flight run exists on the same deal ID.
3. Recall coverage — both HubSpot and engine-own runs table were queried; match keys applied in the documented order (domain → founder email → fuzzy legal name); multi-match cases surfaced for analyst confirmation; prior-verdict aging stamped.
4. Ingest chain-of-custody — every active file in the run record has a SHA-256 hash; the hash was captured before any mutation; Drive OAuth scope is deal-folder-only; the volume-guard threshold was respected.
5. Classification soundness — no high-value files (candidate P&L, audit, balance sheet) sit in 00_intake/_unclassified/; ai_fallback confidence scores are above threshold where used; deterministic-pass results are consistent with the content keywords they matched on.
6. OCR / translation provenance — every file in 00_intake/_processed/ carries originating-language + service + timestamp metadata; the original-language file is preserved immutably in 00_intake/; service-failure retry log present if applicable.
7. Re-filing log completeness — any file renamed, moved, or re-classified during Phase 0 has a re-filing entry capturing the original location, new location, reason, and analyst (or engine: <heuristic>). Phase 11 (verifier) reads this log when challenging a verdict; gaps here mean a file's provenance can't be traced six months later.
8. Schema compliance — every file record has the seven required fields (drive_file_id, sha256, original_filename, ingested_at, primary_category, status, classifier_layer); enum values are valid; status transitions are logical (no active file with a quarantined-only history).

For each charge, each vendor returns SUSTAINED (charge holds, hygiene is fine on this dimension), DISMISSED (charge doesn't apply or the source material doesn't support evaluating it), or MODIFIED (charge applies in a slightly different form than stated, with explanation). The eight-charge sheet's canonical source-of-truth is app/src/orchestrator/charge-sheets/phase0_5_hygiene.ts; this list mirrors it. Methodology amendments stamp a new PHASE_0_5_METHODOLOGY_VERSION constant and propagate to both surfaces in lockstep.

Vendor dispositions (review-vocabulary)

Each of the four reviewers returns one of UPHELD / RESTRUCTURED / OVERRULED / UNAVAILABLE — the standard Quad Review vocabulary shared with Phase 2.5 and Phase 12. The aggregator maps these to the post-phase vocabulary (CLEAN / ISSUES_FOUND / BLOCKING / DEGRADED) so the deal page and the analyst-facing UI use consistent language across all three checkpoints.

Caution-bias aggregation

The aggregator counts only the dispositions returned by available vendors — UNAVAILABLE votes (vendor timeout, API down, parse error) do not contribute to the tally, but they reduce the panel size on which the verdict is computed. Partial unavailability (1, 2, or 3 of 4 vendors UNAVAILABLE) does NOT automatically downgrade to DEGRADED; the aggregator still emits a verdict from whatever vendors returned valid responses, and the per-vendor outage surfaces explicitly on the deal page so the analyst sees that the verdict is N-of-4 rather than 4-of-4.

• All UPHELD (among available vendors) → CLEAN → auto-proceed to Phase 1.
• 2+ vendors OVERRULED, OR 1 OVERRULED with 1+ RESTRUCTURED → BLOCKING → run halts, Phase 0 re-runs with the flagged fixes.
• 1 OVERRULED alone (rest UPHELD), OR 1+ RESTRUCTURED → ISSUES_FOUND → run pauses at the deal page; the analyst reviews the rationales and confirms before proceeding to Phase 1.
• All four UNAVAILABLE (no vendor returned a valid response) → DEGRADED → run proceeds with an explicit "hygiene check not run" entry in the deal-page audit log.

Divergence surfacing

Where the four vendors return different votes on the same charge, the divergence is surfaced verbatim — "Claude SUSTAINED, GPT MODIFIED, Gemini SUSTAINED, DeepSeek DISMISSED" — with all four rationales side by side. Consensus is not engineered; divergence is the signal.

Structured record written to ${RESEARCH_ARSENAL_RUNS_DIR}/${runId}/10_dd-output/{date}_{target-slug}_p0-hygiene-check.json at the end of every Phase 0.5 run, regardless of disposition. Contains the full per-charge vote and rationale from each of the four vendors, the per-charge divergence summary where applicable, the final aggregated disposition, the methodology snapshot version, and a duration / cost line. Surfaced on the deal page alongside the Phase 12 memo-verdict review so the deal page shows both the intake-side check and the verdict-side check. Persistence wired in Task 11 via the shared writeGateLogFile helper (alongside Phase 1, Phase 2, Phase 2.5, Phase 3, Phase 4 gate-log writers); soft-fails when RESEARCH_ARSENAL_RUNS_DIR is unset (engine ships without RA wired by default). The symmetric readGateLogFile(runId, 'p0-hygiene-check') reader is what the deal-page audit-trail surface consumes.

If the disposition is BLOCKING or ISSUES_FOUND, the deal page renders an action banner with the affected charge(s) named and a "re-run Phase 0" or "confirm and proceed" button as appropriate.

Why this exists

Scoring criteria without sufficient input is how a gate hallucinates. The model will helpfully pattern-match an answer to a criterion it cannot actually evaluate from the supplied data. Phase 1 refuses to score a criterion unless the engine has the input the criterion requires.

Per-criterion input requirements

• Criteria 1, 2, 9 — deal-form fields + Phase 0 classification log (always present).
• Criteria 3, 4, 7, 8 — P&L or processor-derived revenue / margin data from Phase 0's classified financial documents.
• Criterion 5 — order-to-delivery data from Phase 0's commerce or operations documents.
• Criterion 6 — deal-form listing-ask field.
• Criterion 10 — customer-order data from Phase 0's commerce or CRM documents.
• Criteria 11, 12 — deferred (Phase 3 and Phase 5 backfill).

What happens when input is missing

Any criterion with insufficient input returns DEFERRED with the named missing-input. The gate aggregation treats DEFERRED distinctly from PASS / NEAR / FAIL — it surfaces on the deal page as "criterion N requires <data> which is not present; analyst can supply or accept the deferral." Silent best-effort scoring is forbidden.

What it is

The file that holds Ecomma's twelve acquisition criteria, the hard disqualifiers, the per-criterion metadata, and the lesson history for every criterion that was earned the hard way. Lives at project-starter/.claude/skills/run-deal-dd/references/acquisition-thesis.md. Version-stamped under the methodology snapshot at Phase 0; the run is bound to whatever version was current at run-start time.

Per-criterion metadata schema

Each criterion in the reference file carries this metadata, not just the threshold:

• threshold — numeric or categorical (per-category table where the threshold differs by niche).
• tolerance_band — what counts as "near" vs. "fail."
• deal_stage_overrides — different thresholds for Pre-LOI screen vs. LOI vs. postmortem vs. BYO.
• input_required — what data the criterion needs to be scorable (used by the gate-input contract above).
• failure_template — the boilerplate sentence Phase 1 writes into the HARD-PASS memo when this criterion fails.
• lesson_history — when this criterion was added, the deal that drove the lesson, the link to the post-mortem.
• override_eligibility — structured field with two sub-fields: allowed (boolean — whether this criterion is overridable by the analyst at all; false for the seven hard disqualifiers, which are not analyst-overridable under any circumstances and instead route through the separate HubSpot IC-waiver pathway before the run starts); valid_reason_codes (array — when allowed is true, which of the six typed reason codes from the override taxonomy are accepted for this criterion specifically, since not every reason fits every criterion — e.g., criterion 1 niche fit accepts only IC_STRATEGIC and CATEGORY_OUTLIER_JUSTIFIED, never DATA_GAP_TEMPORARY; the array is empty when allowed: false).

The twelve criteria

The instant hard disqualifiers (separate from the twelve)

These are not scored — they are absolute and not overridable except by explicit IC waiver recorded in HubSpot.

• Edible, perishable, or regulated products
• Adult products
• Self-fulfilled operations (we want third-party logistics)
• Banned or restricted ad accounts on the major platforms
• Active legal disputes or IP risks
• Unresponsive or uncooperative seller
• Inability to transfer key assets

Model + version

Claude — current flagship Opus version, pinned by the methodology snapshot at run-start (Opus 4.7 as of methodology v3.0.0). The methodology version is the binding reference; the specific model identifier lives in the methodology snapshot, not hardcoded in this narrative.

What the engine sends

Three inputs: the ten gate-active criteria (criteria 11 and 12 are deferred and not included in this call), the deal's grounding bundle (classified financial documents, commerce/CRM data, deal-form fields, Phase 0 classification log — explicitly the same bundle the gate-input-contract pre-check just validated), and an instruction to score each criterion with {vote, value, confidence, rationale, sources_used} per criterion. The instruction forbids inventing values — if the model cannot find the data it needs in the bundle, it must return DEFERRED with the named missing input, not a guessed score.

Scoring contract

Per criterion, Claude returns:

• vote — one of PASS, NEAR, FAIL, DEFERRED.
• value — the numeric or categorical value the model found (e.g. "47% GM", "$12K trailing average revenue").
• confidence — 0–1 model self-rating. Confidence below the methodology-set floor (default 0.7) downgrades the vote to DEFERRED automatically.
• rationale — one sentence on the reasoning.
• sources_used — the specific Phase 0 files / data fields the model relied on. Used by the gate logger for the audit trail.

Cross-check (not a cost choice — a quality choice)

The same scoring runs against a second vendor in parallel for any criterion where the first vendor's confidence is between 0.7 and 0.85 — the band where the model is confident enough to vote but not confident enough to be solo-trusted. The second vendor is pinned by the methodology snapshot at run-start, drawn from the same four-vendor roster the Phase 12 Quad Review uses (Anthropic Claude Opus, OpenAI GPT, Google Gemini, DeepSeek); the current pinning is GPT (chat-API flagship 5.5) as the cross-check partner to the Claude primary scorer. Divergence between the two vendors on a load-bearing criterion (1, 3, 4, 7, 8, 9) auto-escalates the criterion to analyst review before the gate aggregates.

What happens if the cross-check vendor is unreachable

If the cross-check call fails (timeout, API error, key invalid), the affected criterion does not silently fall back to the single-vendor vote. Instead, the criterion is marked DEFERRED with the missing-cross-check reason recorded on the gate log, and the analyst is gated via the deal page banner before the run proceeds. The cost of unverified mid-confidence votes is paid in analyst time, not in silent acceptance.

The four gate states

• PASS — every gate-active criterion (1–10) is PASS or, for the graduated criteria (5, 6, 10), NEAR with no other concerns. Proceed to Phase 2.
• CONDITIONAL PASS — one or more NEAR verdicts on graduated criteria, OR one or more DEFERRED verdicts on non-load-bearing criteria, with no hard-fail on a load-bearing criterion. Proceed to Phase 2 with named gaps on the deal page that the memo must address.
• HARD PASS — any FAIL on a load-bearing criterion (1, 2, 3, 4, 7, 8, 9), OR two-or-more FAIL verdicts on any criteria, OR any of the seven hard disqualifiers fires. Run halts and produces the HARD-PASS deliverable (see below).
• OVERRIDE PROCEED — analyst override under the override-paths policy (cross-cutting section below). The gate's vote stands ("HARD PASS would have fired on criterion 8"); the run proceeds anyway with the override reason captured. The memo surfaces the override prominently, not in an appendix.

What load-bearing means

Load-bearing criteria are the ones where a single fail is decisive: 1 (niche fit), 2 (operating age), 3 (revenue floor), 4 (profit floor), 7 (YoY trend), 8 (gross margin), 9 (model type / IP). The other criteria (5, 6, 10) graduate through NEAR; the deferred ones (11, 12) get backfilled by Phase 7 and only affect the verdict, not the Phase 1 gate.

DEFERRED vs FAIL

DEFERRED never aggregates to a fail at Phase 1. It marks "the engine couldn't score this from current inputs" and surfaces on the deal page for the analyst to either supply the missing data, accept the deferral and proceed, or treat the deferral as a fail explicitly. The default is "surface and ask" — silent best-effort is the failure mode the gate-input contract exists to prevent.

phase1-gate-log.json

Written to 10_dd-output/{date}_{target}_phase1-gate-log.json on every run, regardless of gate outcome. Contains, per criterion: vote, value, confidence, rationale, sources_used, cross-check vendor verdict (if cross-check fired), and the final aggregated gate state. Surfaced on the deal page as a collapsible audit trail. A HARD PASS verdict challenged six months later is reviewed against this artefact.

HARD-PASS short memo

When the gate state is HARD PASS, the engine still produces a 1–2 page memo at 10_dd-output/{date}_{target}_dd-memo_hard-pass.docx. Contents:

• Target identification (name, domain, founder, category).
• The verdict and the specific criteria that failed, with the values found and the failure-template sentence from the methodology.
• The underlying data sources that drove the failure verdict.
• The re-engagement conditions — what would need to change in the target's business for Ecomma to re-open the deal. Pulled from re-engagement-triggers.md per reason code.
• The override-trigger conditions — what an IC override would need to document if Ecomma wanted to proceed despite the failure.

HubSpot write

The gate decision is written back to the HubSpot deal record with the reason code and the re-engagement triggers attached, so future recall queries (Phase 0 sub-step 3) surface the prior verdict with the conditions needed to unblock it.

What it checks

Before any commerce / payments / accounting pull fires, the engine verifies (a) target_currency is set on the run record — Phase 2 fails loud if it isn't, since every downstream number depends on it; (b) the FX-rate snapshot captured by Phase 0 is present for every non-target currency the target's data touches; (c) at least one connected source exists per leg (commerce, payments, accounting). Missing inputs are recorded as deferred sub-aspects, not silent empty pulls.

What happens when an input is missing

The corresponding sub-output is marked DEFERRED with the missing-input reason recorded (e.g. accounting_unavailable: no_connector_registered). Downstream skills are passed the deferred state and produce explicit data-gap blocks rather than synthesising values from empty arrays. If all three legs are unavailable, Phase 2 cannot proceed and the gate aggregates to HARD PASS unless overridden by an analyst with documented data-gap reason.

Why discovery, not hardcoding

A target on Magento produces empty data if the engine hardcodes Shopify. A target running both a Shopify storefront and Amazon Brand Registry — 40%+ of revenue on Amazon — looks like a much smaller business if marketplaces are ignored. A target operating one parent legal entity plus two subsidiaries reconciles wrong if treated as a single entity. Discovery runs before the pulls so the engine actually knows what to pull and from where.

What's discovered

• Commerce platforms — Shopify (storefront fingerprinting on the public site + OAuth integration probe), Magento, WooCommerce, BigCommerce, Salesforce Commerce Cloud, plus marketplace channels: Amazon (Brand Analytics + Seller Central), eBay (Sales reports), TikTok Shop (Analytics), Etsy. Per-platform discovery confidence is captured; low confidence triggers the seller-questionnaire / analyst-escalation loop.
• Payment processors — Stripe, PayPal, Adyen, Braintree, Mollie, Klarna. Per-processor discovery covers multi-account targets (per-entity processor accounts).
• Accounting systems — QuickBooks (US-default), Xero (UK / AU / NZ default), Sage (UK / IE / DE), Moneybird (NL — often returns Dutch, handled by Phase 0 translation), NetSuite (larger targets), Wave.
• Entity structure — single legal entity vs parent + subsidiaries. Multi-entity discovery surfaces consolidation and intercompany-elimination requirements to the 3-statement-model skill.

Output

10_dd-output/{date}_{target}_phase2-platform-discovery.json. Surfaced on the deal page; the analyst can correct misdiscoveries (e.g. mark a detected platform as not-actually-the-target's) with one click, which re-fires the affected pulls.

The handshake

Phase 0 captured target_currency at intake (mandatory, no default) and the FX-rate snapshot at run-start. Phase 2 reads both. Every raw amount that comes back from a pull (orders in EUR from a NL Shopify, settlements in USD from Stripe, GL transactions in EUR from Moneybird) is normalised to target_currency using the FX-rate snapshot — never re-fetched, so re-runs of the same run produce identical numbers.

Provenance preserved

Raw per-currency values are preserved alongside normalised values on every leg. The reconciliation operates on normalised values; the audit log and the data pack cite both. The FX-rate snapshot's capturedAt timestamp is propagated for every cross-currency conversion so the data-pack's audit trail shows which snapshot fired which conversion.

What's pulled

For each discovered platform: the trailing 24 months of orders, customer cohorts, returns, refunds, refund-lag distribution, product-mix shares, repeat-purchase share. Per-platform pulls run in parallel; per-platform failure surfaces in the leg's pull_status rather than blocking the aggregate. Marketplace pulls (Amazon Brand Analytics, eBay Sales reports, TikTok Shop Analytics) are first-class alongside the storefront pulls — a 40%-of-revenue Amazon channel produces 40% of the cohort data.

Source tier

Platform-pulled data is tagged [verified] — it can't be inflated because the platform is the source. Seller-exported analytical exports (e.g. a CSV the seller produced) are tagged [inferred] and require reconciliation against a primary source before promotion.

What's pulled

Per discovered processor, per connected account (multi-account targets handled by enumerating connected accounts): the actual settled money. Settlement-level — every charge, every refund. Plus disputes (open + resolved) and chargebacks. The chargeback dimension matters for the reconciliation denominator: gross settlement minus chargebacks = net revenue the business actually realised, which is what should reconcile against the GL net revenue line, not the gross.

Why disputes and chargebacks are separate from refunds

A refund is voluntary; the business chose to issue it and the operational metrics treat it as customer satisfaction or returns. A dispute or chargeback is involuntary and signals downstream issues (delivery failure, fraud, misrepresentation). For DD, the chargeback rate as a percentage of gross settlement is itself a quality signal — a chargeback rate above the methodology-pinned floor flags an operational risk in the deal page even if the reconciliation passes.

What's pulled

From the discovered accounting system: trial balance, P&L, balance sheet, general-ledger detail, the COGS ledger, and inventory-movement records. The COGS + inventory pulls are separate from the GL pull because the COGS-to-inventory reconciliation (cost of goods sold this period vs inventory that moved this period vs supplier invoices booked this period) is its own integrity check — revenue inflation isn't the only fraud surface.

Multi-entity targets

If discovery flagged multiple legal entities (parent + subsidiaries), the engine pulls each entity's GL separately, then loads the consolidation eliminations from whichever entity carries them. The 3-statement-model skill receives both per-entity ledgers and the consolidated view; the audit-xls skill verifies that the consolidated total equals the sum of per-entity totals net of eliminations.

Data-room fallback

When no live accounting integration is available, the engine falls back to the seller-exported P&L from Phase 0's data-room ingestion. Seller-exported data is tagged [inferred] until GL reconciliation passes. The fallback is logged on the gate log so the verdict can be challenged later with "this verdict was reached on seller-exported financials, not live GL pulls."

What's checked

For each month, the engine ties three numbers together: (a) COGS recognised in the P&L, (b) inventory that moved out of stock per the inventory ledger, (c) supplier invoices booked into accounts payable for the same period. These three should reconcile within the methodology-pinned tolerance. Where they don't, the gap is classified — common operational explanations include timing on inventory receipts vs invoice booking; uncommon explanations include misclassified expenses or inventory shrinkage.

Why this matters

Revenue inflation is one fraud surface; margin inflation via under-reported COGS is another. A target showing 50% GM might actually be 35% GM if 15 points of COGS sit unbooked. The COGS-inventory-invoice triangulation catches this class.

What the skill is

One of our Tier A finance skills. The SKILL.md file at project-starter/.claude/skills/finance/3-statement-model/ tells the methodology-pinned LLM how to build an integrated financial model: P&L, balance sheet, and cash flow, linked by formulas, with proper integrity checks (balance sheet balances, cash ties out from indirect-method cash flow to the actual cash account). For multi-entity targets the SKILL.md spec covers the per-entity build + the consolidation step.

Methodology-pinned vendor

The vendor and model identifier live in the methodology snapshot at run-start, not hardcoded in the skill body. Current pinning: Anthropic Claude Opus (version pinned by methodology version). The cross-check partner (when the skill's confidence band suggests one is needed) is GPT (chat-API flagship 5.5) per the same methodology snapshot. Methodology version drift = skill version drift = audit-trail entry.

What it produces

An Excel file: {target}_three-statement-model.xlsx. Formulas, not hardcodes. Every blue input cell cites its source. The model becomes the foundation for every downstream phase that needs financials — Phase 3 comps, Phase 4 ten-layer unit-economics review, Phase 6 scenarios, Phase 7 verdict, Phase 10 memo.

Why it runs before the datapack

The data pack is the IC-facing deliverable. If the underlying model has a balance-sheet imbalance or a broken cash-flow tie-out, the data pack will silently embed that error and cite it as ground truth. So the audit runs first; the data pack only runs against an audited model.

Closed enumeration of failure types

The audit-xls SKILL.md defines a closed list of structural failure types, each with its own tolerance and per-failure failure-mode template:

• Balance-sheet imbalance — Assets ≠ Liabilities + Equity beyond the methodology-pinned tolerance. Hard structural error.
• Cash-flow tie-out failure — Indirect-method cash flow's ending cash doesn't equal the balance sheet's cash line. Hard structural error.
• Hardcoded numbers inside formulas — Blue input cells mixed with hardcoded values in computed cells. Recoverable; surfaces as warning + analyst review.
• Broken roll-forwards — Period-N closing balance doesn't equal Period-N+1 opening. Hard structural error.
• Missing inputs — Formulas pointing at empty source cells. Recoverable; surfaces with named gap.
• Source-tier mis-tagging — Numerical claim without a [verified] / [derived] / [inferred] / [benchmark] / [judgment] source tier. Recoverable; analyst-correctable.

Four-state outcome

Audit-xls returns one of CLEAN / WARNINGS_ONLY / RECOVERABLE_ERRORS / HARD_ERRORS. CLEAN and WARNINGS_ONLY proceed. RECOVERABLE_ERRORS proceed with CONDITIONAL_PASS gate state and the errors surface on the deal page for analyst review. HARD_ERRORS fail the phase gate (HARD PASS) unless analyst override.

What the skill is

Reconciles the accounting system's GL revenue line against the payment-processor settlements (less chargebacks per the chargeback-economics row above) against the commerce-platform orders. For multi-entity targets the reconciliation runs per-entity plus on the consolidated total. For each month, the three totals should reconcile within the methodology-pinned tolerance.

Tolerance + denominator + aggregation rule (all methodology-pinned)

The tolerance, denominator, and aggregation rule all live in reconciliation-rules.md under the methodology snapshot — not hardcoded in the skill body. Current pinning: 2% tolerance on monthly net GL revenue, applied as "any single month exceeding 2% triggers classification; three consecutive months exceeding 1.5% also triggers; rolling 12-month average exceeding 1% triggers." The denominator is monthly net GL revenue (gross less refunds less chargebacks). Methodology amendments to any of these values stamp a new version into the snapshot.

Operational break-code taxonomy (not strategic — the audit-quad finding)

Breaks outside tolerance are classified by operational break code, distinct from Phase 1's strategic override reason codes:

• TIMING — GL recognises revenue in month N+1; settlement landed in month N. Common, operationally explainable, low-signal.
• MISSING_CHANNEL — GL revenue has no corresponding processor settlement (e.g. Amazon revenue not yet integrated as a payment leg). Resolvable by adding the missing source.
• CLASSIFICATION_ERROR — GL account miscategorisation (refund posted to revenue, deferred revenue recognised early).
• CURRENCY_VARIANCE — FX-conversion variance within methodology tolerance; tracked separately from suspicious for clarity.
• SUSPICIOUS — Gap with no operational explanation. Primary fraud-signal bucket. Auto-escalates to analyst review before the gate aggregates.
• EXPLAINED_BY_ANALYST — Analyst attached a specific operational note + accepted the break. Gate-log preserves both the break and the explanation.
• PENDING_ANALYST — Surfaced to the deal page; awaiting analyst classification. Blocks the gate until classified.

Cross-vendor cross-check

The break classification is itself a model judgment. When the primary classifier's confidence is in the methodology-pinned mid-confidence band (currently 0.7–0.85), the same break is re-classified by the cross-check vendor (per the Phase 1 cross-check architecture). Divergence on a suspicious or pending classification auto-escalates to analyst review.

Why it runs last

The data pack is the deliverable the IC sees. It cites the financial model, the reconciliation outcome, and the audit verdict. Running it last (after audit-xls + GL reconciliation) means every number it cites has already been integrity-checked and reconciliation-classified. Building it earlier means citing un-vetted numbers.

What it produces

A single Excel workbook with every number an investment-committee member would want to see: revenue waterfall (gross → less refunds → less chargebacks → net), margin walk, customer cohort table (monthly cohorts, retention by month, LTV), ad-spend breakdown, supplier-concentration chart, working-capital schedule, reconciliation outcome summary, audit-xls verdict summary. Every number cites its source-tier and which Phase 2 pull it came from.

Downstream consumers

Phase 3 (comps benchmark) reads the financial model + cohort table to position the target against peer transactions. Phase 4 (ten-layer review) reads the unit-economics layer + supplier-concentration chart. Phase 6 (scenarios) reads the cohort table + working-capital schedule to model retention curves and cash conversion. Phase 7 (verdict) reads everything. Phase 10 (memo render) cites the data pack rows by reference.

What can be overridden

Per-aspect overrides at Phase 2: input-contract failure (e.g. accounting unavailable but seller-provided P&L deemed adequate), audit-xls HARD_ERRORS verdict (e.g. balance sheet imbalance under a known accounting-system quirk), reconciliation outcome (e.g. SUSPICIOUS break that the analyst has reclassified to EXPLAINED_BY_ANALYST with documented note). Each override is keyed by sub-aspect, not by phase as a whole.

Reason codes are operational, not strategic

Phase 1's strategic reason codes (IC_STRATEGIC, FOUNDER_RELATIONSHIP, etc.) do not apply at Phase 2 — Phase 2 is an operational analytical phase, not a strategic-fit gate. The Phase 2 override taxonomy uses the operational break-code vocabulary from the reconciliation skill plus per-aspect typed reasons (e.g. ACCOUNTING_SYSTEM_QUIRK, SELLER_PNL_RECONCILED_OFFLINE, BREAK_RECLASSIFIED_ON_INSPECTION). The per-aspect valid_reason_codes set lives in reconciliation-rules.md alongside the tolerance pinning.

Surfacing + aggregate review

Every override surfaces in the executive summary of the memo + on the deal page. The IC monthly review aggregates Phase 2 overrides alongside Phase 1 and Phase 7 overrides — patterns (same break code reclassified often, same analyst reclassifying disproportionately) drive either methodology amendments to reconciliation-rules.md or an analyst conversation.

The four states

• PASS — every leg's input contract satisfied, audit-xls CLEAN or WARNINGS_ONLY, reconciliation within tolerance or breaks operationally explained, COGS/inventory triangulation within tolerance, no override. Proceed to Phase 3 cleanly.
• CONDITIONAL_PASS — one or more deferred sub-aspects (e.g. live accounting unavailable, seller-PnL fallback in use), OR audit-xls RECOVERABLE_ERRORS, OR within-tolerance breaks with analyst-explained codes. Proceed to Phase 3 with named gaps on the deal page that the memo must address.
• HARD_PASS — audit-xls HARD_ERRORS (balance imbalance, cash tie-out failure, broken roll-forwards), OR reconciliation has SUSPICIOUS or PENDING_ANALYST breaks above methodology tolerance, OR input contract failed on all three legs with no override. Run halts and produces the HARD-PASS deliverable. Phase 3 does not start.
• OVERRIDE_PROCEED — analyst override under the override-paths policy. The gate's vote stands ("HARD_PASS would have fired on the SUSPICIOUS break on the Amazon settlement gap"); the run proceeds anyway with the override reason captured. The memo surfaces the override prominently.

Why no other hard gates

The previous Phase 2 design had audit-xls as a hard run-stop ("if any critical errors are found, this phase fails and the run stops"). That violated the engine-wide no-hard-gates principle established in Phase 0.5 and Phase 1. The new four-state gate preserves the fail-fast posture for truly unrecoverable conditions (a model whose balance sheet doesn't balance cannot be salvaged) while routing everything else through CONDITIONAL_PASS or OVERRIDE_PROCEED so analyst judgment can decide.

What's in it

Written to 10_dd-output/{date}_{target}_phase2-gate-log.json on every run, regardless of gate outcome. Contents: input-contract state per leg, discovered platforms, FX-rate snapshot timestamp, per-skill {ok, errors, warnings}, audit-xls failure list with severity, reconciliation outcome with per-break classification, COGS/inventory reconciliation outcome, final gate state, override (if any), analyst classifications applied during the run. Surfaced on the deal page as a collapsible audit trail. A verdict challenged six months later is reviewed against this artefact.

What it is

The financial model from the 3-statement-model skill, post-audit. Carries the methodology version stamp and the FX-rate snapshot timestamp on the cover sheet so future analysts know exactly which rules and which rates produced it. Filed under the deal's Drive folder. Available on the deal page under Supporting Documents.

What it is

The data pack from the datapack-builder skill. Single Excel file. Every number cites its source-tier ([verified] / [derived] / [inferred] / [benchmark] / [judgment]), which Phase 2 pull it came from, and the reconciliation outcome that vouches for it.

Why Claude for sense-check

Claude is the primary analytical model behind Phase 2's skill calls (3-statement-model, audit-xls, gl-reconciliation, datapack-builder). At Phase 2.5 a separately-prompted Claude instance reviews the output of those same skills — different prompt, different context, no shared memory between the build pass and the review pass. This is the same vendor's analytical rigor turned on its own work.

What it receives

Seven content blocks: input-contract state, discovered platforms (commerce / payments / accounting / entity structure), 3-statement model output, audit-xls verdict, GL reconciliation outcome, data pack summary, Phase 2 gate state. Plus the eight-charge sense-check sheet (see below). Returns per-charge votes plus an overall disposition.

Why GPT for sense-check

GPT-5.5 has shown particular strength on code-level control flow and structural integrity questions — exactly the dimensions Phase 2's audit-xls verdict and reconciliation classification ride on. Different training origin from Claude; catches different things.

Same content, independent verdict

Identical seven content blocks and charge sheet. The four vendors do not see each other's verdicts. Divergence is high-signal — when reviewers disagree on a charge, the analyst sees all four rationales before deciding whether to proceed.

Why Gemini for sense-check

Different corpus and alignment from Claude and GPT. Strong on schema completeness and missing-field detection — useful when Phase 2's data pack columns need to match the downstream Phase 4 (ten-layer review) and Phase 6 (scenarios) consumer expectations.

Why DeepSeek for sense-check

Different training origin from Claude, GPT, and Gemini. Consistently pushes back on overreach, gold-plating, and assertions presented as facts when the underlying data is ambiguous. Adversarial pressure on Phase 2's reconciliation classifications — particularly the SUSPICIOUS-vs-EXPLAINED-BY-ANALYST boundary — is exactly what DeepSeek is best at.

1. Financial model integrity — balance sheet balances; cash-flow tie-out reconciles indirect-method ending cash to the balance-sheet cash line; period-N closing balances equal period-N+1 opening; no hardcoded values inside formulas.
2. Reconciliation outcome credibility — break classifications are operationally explainable; the SUSPICIOUS bucket is non-empty only when the gap is genuinely unexplained; any >-tolerance break has either an operational explanation or a SUSPICIOUS / PENDING_ANALYST escalation.
3. Source-tier discipline preserved — every numerical output carries [verified] / [derived] / [inferred] / [benchmark] / [judgment] tagging; platform-pulled data is [verified]; seller-exported is [inferred] until reconciled.
4. Currency normalisation consistent — every raw amount is converted to target_currency using the FX-rate snapshot stamped on the run; per-currency raw values are preserved alongside normalised values; no silent mixed-currency aggregation.
5. Cohort retention and unit-economic plausibility — outputs are plausible relative to the seller-provided narrative AND the platform-pulled order data; no fabricated cohort tables; no LLM-hallucinated retention curves; cohort granularity matches the methodology-pinned definition.
6. Marketplace coverage complete — Amazon / eBay / TikTok Shop / Etsy revenue is captured where the target operates on those channels; the reconciliation denominator reflects all commerce channels, not Stripe + PayPal only.
7. Multi-entity handling correct — for targets with parent + subsidiaries, per-entity GL is consolidated with explicit eliminations; the audit-xls verdict checks per-entity-plus-consolidated; no entity is silently dropped.
8. Output schema compliance — data pack columns match the methodology-pinned schema; Phase 4 (ten-layer unit economics) and Phase 6 (scenarios) consumers receive the fields they expect.

For each charge, each vendor returns SUSTAINED (charge holds, Phase 2 output is fit on this dimension), DISMISSED (charge doesn't apply or the source material doesn't support evaluating it), or MODIFIED (charge applies in a slightly different form than stated, with explanation).

The four post-phase dispositions

• CLEAN — every available reviewer returned UPHELD; Phase 2 output is fit to proceed to Phase 3.
• ISSUES_FOUND — one or more reviewers returned RESTRUCTURED. The run can proceed but the analyst confirms via the deal page.
• BLOCKING — two or more reviewers returned OVERRULED (or one OVERRULED + one RESTRUCTURED) — Phase 2's output has a structural issue that makes Phase 3 unsafe. Phase 2 must address the findings and re-run.
• DEGRADED — all four reviewers unavailable (timeout, API down, parse error). The run proceeds with an explicit "Phase 2.5 not run" entry in the deal page audit log.

How review-vocabulary maps to post-phase-vocabulary

Reviewers return UPHELD / RESTRUCTURED / OVERRULED / UNAVAILABLE (the standard Quad Review vocabulary). The aggregator maps these to the post-phase CLEAN / ISSUES_FOUND / BLOCKING / DEGRADED vocabulary so the deal page and the analyst-facing UI use consistent language across Phase 0.5, Phase 2.5, and Phase 12 checkpoints.

Caution wins ties

OVERRULED gets safety bias: any single OVERRULED combined with any RESTRUCTURED forces BLOCKING. Two or more OVERRULED is automatic BLOCKING. The principle: when reviewers disagree on whether Phase 2 output is fit, the cautious read wins.

Divergence surfacing

Where the four vendors return different votes on the same charge, the divergence is surfaced verbatim — "Claude SUSTAINED, GPT MODIFIED, Gemini SUSTAINED, DeepSeek DISMISSED" — with all four rationales side by side. Consensus is not engineered; divergence is the signal.

Structured record written to 10_dd-output/{date}_{target}_p2-sense-check.json. Contains the full per-charge vote and rationale from each of the four vendors, the per-charge divergence summary where applicable, the final aggregated disposition (CLEAN / ISSUES_FOUND / BLOCKING / DEGRADED), and a per-vendor duration line. Surfaced on the deal page alongside the Phase 0.5 hygiene verdict and the Phase 12 memo verdict so the IC reviewer sees every adversarial checkpoint's outcome in one place.

If the disposition is BLOCKING or ISSUES_FOUND, the deal page renders an action banner with the affected charge(s) named, the dissenting reviewer(s) cited, and a "re-run Phase 2" or "confirm and proceed" button as appropriate.

What it checks

Before any comp pull fires, the engine verifies (a) Flippa / PitchBook / internal comp-database connectors are reachable; (b) Phase 2's prior output (model + commerce breakdown + reconciliation outcome) is present and not HARD_PASS without override — running comps against an un-reconciled revenue figure produces meaningless size-band positioning; (c) target_currency + FX-rate snapshot are present (already enforced upstream but rechecked at this boundary).

What happens when an input is missing

The affected sub-output is marked DEFERRED with the missing-input reason. Downstream comps-analysis skill receives the deferred state and produces explicit data-gap blocks rather than synthesising a peer set from empty arrays. If every comp source is unavailable AND Phase 2 prior output is missing, Phase 3 aggregates to HARD_PASS unless overridden by an analyst with documented data-gap reason.

Why discovery, not hardcoding

Each comp source uses a different category taxonomy: Flippa has its own marketplace categories; PitchBook uses NAICS / SIC industry codes; the curated comp-database is organised by Ecomma-internal verticals (beauty / apparel / home / baby / automotive). Passing the raw deal.categories strings to all three results in taxonomy misses — a "Watches" deal won't match PitchBook's Personal-luxury-goods NAICS code. Discovery-before-pull is the same pattern Phase 0.5 (vendor selection) and Phase 2 (platform-of-record) established.

Per-source mapping confidence

Each taxonomy mapping carries a methodology-pinned confidence score. Mappings with confidence below 0.7 surface on the deal page for analyst confirmation before the affected pull fires. Methodology amendments to the taxonomy-mapping tables stamp a new methodologyVersion; re-runs use the same mapping the original run used.

Output

Per-source { available, nativeCategories, mappingConfidence } structure plus a snapshot version stamp. Surfaced on the deal page; the analyst can correct a low-confidence mapping with one click, which re-fires the affected pull.

The handshake

Comp transactions come in their source currency: Flippa US comps in USD, PitchBook EU comps in EUR, Ecomma curated comps in whatever currency the original transaction was recorded in. Phase 3 normalises every raw amount to target_currency using the fxRateSnapshot AT THE COMP'S TRANSACTION DATE — historical FX, not the run-start snapshot used for Phase 2's current-state data. This is materially more complex than Phase 2's handshake because comps span historical dates with their own FX-rate context.

Why multiples themselves are currency-neutral

An EV/Revenue multiple of 3.5× is a dimensionless ratio — both numerator and denominator carry the same currency, so the ratio is identical whether expressed in USD or EUR. The currency-sensitive surface is the size-band metric (target revenue vs comp revenue), the monetary outputs (price ranges, EBITDA in absolute terms), and the per-source primary-listing currency. Phase 3 normalises the monetary inputs; the multiples flow through unchanged.

Provenance preserved

Each comp transaction carries fxRateApplied: { sourceCurrency, rate, rateCapturedAt } alongside its normalised values. The audit log can reconstruct the conversion six months later.

What Flippa is

The largest open marketplace for small online-business sales. Most Ecomma-sized deals (under $1M) show up there at some point. The API gives us recent transactions filtered by category, multiple, and size — but the data is seller-asserted, not audited, so every Flippa row is tagged [inferred] source tier.

What's pulled

Per the discovered Flippa categories from the previous step, the engine pulls trailing-24-month sold listings (the lookback window is methodology-pinned in comp-selection-rules.md; default 24 months). Each row normalised to the canonical CompTransaction shape with currency normalisation + earnout decomposition + EV-basis tagging applied. Per-source pull_status (connected / unavailable / rate_limited / auth_failed / empty_for_category) surfaces in the gate aggregation.

What PitchBook is

Subscription database of private-company transactions. Bigger deals than Flippa. Useful when the target is on the larger end of our range or when we want strategic-acquirer comps. Editorial review applied to every row, so source-tier is [verified].

What's pulled

Per the discovered PitchBook NAICS / SIC codes, the engine pulls trailing-24-month transactions filtered by the methodology-pinned size band (revenue ±50%, extended to ±100% only if the primary band yields fewer than 8 comps). Each row normalised to CompTransaction. Per-source pull_status surfaces in gate aggregation.

What it is

Ecomma's own curated comp database. Organised by Ecomma-internal vertical with annotated multiples, growth rates, and gross margins on each comp. Source-tier is [curated] with per-row vintage + last-reviewed timestamps. A row added in 2022 that hasn't been reviewed since is flagged for status — the curation methodology pin tracks per-row review cadence so a 2-year-stale row doesn't get treated as authoritative.

Curation hygiene

The curation methodology (who adds, who reviews, retirement criteria, per-vertical reviewer assignment) is pinned in Wohnish-Methodology-Derivation.md as a methodology amendment. Drift between curated rows and current market reality (e.g. pre-rate-hike comps in a post-rate-hike market) is surfaced via the time-decay weighting that the comps-analysis skill applies.

Why this matters

Headline transaction prices routinely include earnouts (contingent on hitting forward revenue / EBITDA milestones), seller notes (deferred payments), and equity rollovers (continued ownership stake) that materially distort the implied multiple. A $5M headline deal with $3M of earnout is, at signing, a $2M cash transaction with $3M of contingent upside — averaging that into a 5M-priced comp median over-weights the deal class by 2.5×.

What the decomposition produces

Each comp carries three price fields: headlinePrice (the announced figure), realisedPriceLow (cash + non-contingent equity paid up-front), realisedPriceHigh (max if all earnout triggers fire). Plus a contingentStructure sub-record capturing earnoutAmount, earnoutTriggers, equityRollover, sellerNote. The comps-analysis skill computes "implied multiple" from realisedPriceLow by default and surfaces the headlinePrice separately so the IC sees the difference. Comps where realisedPriceLow / headlinePrice < 0.5 (more than half is contingent) are flagged with the EARNOUT_DOMINATES break code.

Why this matters

Two comps both reported at "5× revenue" can mean different things depending on the EV definition: a cash-free / debt-free transaction (typical for clean PE deals) is not a like-for-like with a deal that assumed working capital deficits, or one with a working-capital peg adjustment at close. Without normalisation, multiples from different EV bases get averaged across structurally-different transactions.

What the basis-tag captures

Each comp carries evBasis: 'cash_free_debt_free' | 'with_liabilities_assumed' | 'with_wc_peg' | 'undisclosed'. The comps-analysis skill normalises to a consistent EV definition before computing multiples; undisclosed comps are flagged with the EV_BASIS_UNDISCLOSED break code and can be excluded or analyst-overridden depending on peer-set depth.

What Phase 3 reads from Phase 2

Three things: (a) phase2.model.consolidated.pnl.netRevenue — the reconciled revenue used for size-band positioning; (b) phase2.commerce — channel breakdown to derive the target's DTC channel mix (which the methodology-aligned-comparison rule requires > 60%); (c) phase2.recon — the reconciliation outcome that vouches for the revenue figure. If Phase 2's reconciliation has SUSPICIOUS breaks, Phase 3 surfaces a "reconciliation gap" warning on the comp positioning rather than silently using a possibly-inflated revenue figure.

Why fail-loud if Phase 2 HARD_PASS without override

A target whose Phase 2 reconciliation failed is one where the revenue figure isn't trustworthy. Running comps against an un-validated revenue figure produces meaningless peer-set positioning — a 5× multiple against an inflated revenue number is itself inflated. Phase 3 fails-loud unless the analyst has explicitly overridden Phase 2 with a documented reason.

What's pinned

The methodology snapshot fixes these per-run values so two analysts running the same target produce the same peer set:

• Lookback window: trailing 24 months (default; per-business-type override allowed).
• Peer-set size: 8 minimum (drop if smaller, unless override), 15 maximum (rank by relevance if larger).
• Size band: ±50% of target revenue (primary band); extend to ±100% only when primary yields fewer than 8 comps.
• DTC channel-mix threshold: 60% (applied for criterion-11 backfill peer selection; relaxed for general comp-set with explicit flag).
• Multiple set per business type: DTC ecommerce → EV/Revenue + EV/EBITDA primary, EV/Customer secondary; Marketplaces → EV/GMV + EV/Revenue; Subscription / SaaS → EV/ARR + EV/Customer; Mixed → all relevant, analyst flags primary.

Methodology amendments stamp a new snapshot version; re-runs use the same pins the original run used.

What the skill does

Constructs the peer set from the three sources, applies the methodology-pinned filters (lookback / size-band / channel-mix), strips outliers per the skill's pinned rule, splits strategic-vs-financial buckets per the methodology snapshot, and produces multi-axis positioning across the per-business-type multiple set. The SKILL.md at app/skills/finance/comps-analysis/SKILL.md is the canonical spec for: tier-weighted median formula, outlier-handling rule choice, IP/brand-portfolio comp class semantics, time-decay weighting, and strategic-vs-financial bucketing protocol.

Methodology-pinned vendor

Vendor and model identifier live in the methodology snapshot. Current pinning: Anthropic Claude Opus 4.7 as primary; GPT 5.5 as the cross-check vendor when peer-set ranking confidence is in the mid-confidence band [0.7, 0.85]. Methodology version drift = skill version drift = audit-trail entry.

Output

Two artefacts plus the structured outcome: {target}_comps-deck.docx (the IC-facing peer comparison), plus the structured CompsAnalysisOutput that the gate aggregator + Phase 6 (scenarios) + Phase 7 (verdict) read. Every cell cites source-tier per the M12 anti-hallucination protocol.

The rule

From the comp set, the engine selects the closest public comparable using the methodology-aligned-comparison predicates (each a hard gate, all must hold):

1. Same primary-category (target.categories[0] === comp's primary).
2. Size band: comp revenue within ±50% of target revenue (primary band).
3. Public filings within trailing 24 months (capturedAt is recent).
4. DTC channel mix > methodology-pinned 60% threshold.
5. sourceTier === verified (public filings or PitchBook curation; Flippa-tier excluded).

The selected comparable's trailing-12-month repeat-customer share (orders ≥ 2 from same email or phone in the window; DTC channel only) is persisted as phases.3.output.comp_retention_percentage alongside the comparable's identity, source filing reference, and the per-predicate pass/fail trace. Phase 7 reads this field directly to backfill criterion 11; no further computation at backfill time.

Cross-check on ranking judgment

When peer-set ranking confidence is in the mid-confidence band [0.7, 0.85], the same ranking is re-run by the cross-check vendor (currently GPT 5.5). Divergent rankings escalate to analyst review with both rationales surfaced.

If no comparable qualifies

The engine returns NO_QUALIFYING_COMP with rationale (typically: target operates in a category with no public peer at similar scale, or all public peers fail the DTC channel-mix threshold). Phase 7 propagates this as DEFERRED on criterion 11 — a missing comparable is a data gap, not a thesis miss. The audit-quad's "category-mismatched analyst-relaxation path" can be surfaced via the override path below.

What can be overridden

Per-aspect overrides at Phase 3:

• NO_QUALIFYING_COMP_ACCEPTED — analyst accepts a category-mismatched "closest available" comp when zero rows survive the methodology-aligned-comparison predicates. Phase 7 receives a marked-up retention figure with the relaxed-comparison flag set.
• BAND_OUTSIDE_TOLERANCE_ACCEPTED — comp included in peer set despite revenue outside ±100% extended band (e.g. only available comp is 3× target revenue, no closer options).
• OUTLIER_INCLUDED_BY_ANALYST — outlier comp the skill would have dropped is re-included with documented analyst rationale.
• SOURCE_TIER_GAP_ACCEPTED — peer set built primarily from Flippa-tier (inferred) data because no PitchBook or filings-tier comps exist in the category at this scale.

Reason codes are operational, not strategic

Phase 1's strategic reason codes (IC_STRATEGIC, FOUNDER_RELATIONSHIP, etc.) and Phase 2's reconciliation break codes do not apply at Phase 3 — Phase 3 is an analytical positioning phase, not a strategic-fit gate nor an integrity check. The Phase 3 override taxonomy is its own scope-appropriate vocabulary.

Surfacing + aggregate review

Every override surfaces in the executive summary of the memo + on the deal page. The IC monthly review aggregates Phase 3 overrides alongside Phase 1, Phase 2, and Phase 7 overrides — patterns (same break code reclassified often, same analyst overriding disproportionately) drive either methodology amendments to comp-selection-rules.md or an analyst conversation.

The four states

• PASS — every leg's input contract satisfied, at least one comp source returned ≥ 8 transactions after methodology-pinned filters, peer set passes outlier handling, comp_retention_percentage selection rule yielded a qualifying comp. Proceed to Phase 4 cleanly.
• CONDITIONAL_PASS — peer set ≥ 4 but < 8, OR > 1/3 of comps flagged EARNOUT_DOMINATES, OR mid-confidence taxonomy mappings, OR NO_QUALIFYING_COMP on criterion-11 selection but general comp set adequate. Proceed to Phase 4 with named gaps that the memo must address.
• HARD_PASS — peer set < 4 AND no override, OR Phase 2 prior output was HARD_PASS without override, OR all three comp sources unavailable. Run halts; HARD-PASS deliverable produced. Phase 4 does not start.
• OVERRIDE_PROCEED — analyst override under the override-paths policy. The gate's vote stands ("HARD_PASS would have fired on insufficient peer set"); the run proceeds anyway with the override reason captured. The memo surfaces the override prominently.

What's in it

Written to 10_dd-output/{date}_{target}_phase3-gate-log.json on every run, regardless of gate outcome. Contents: input-contract state per source, discovery results with per-source mapping confidence, FX-rate snapshot timestamp, per-source pull_status, comps-analysis skill {ok, errors, warnings}, peer-set transaction count, comp_retention_percentage value + selection trace (or NO_QUALIFYING_COMP rationale), final gate state, override (if any). Surfaced on the deal page as a collapsible audit trail.

What it is

The comps deck from the comps-analysis skill. Word document with the peer-set table, distribution charts, multi-axis positioning, and the "where this deal sits relative to comparable transactions" verdict. Every multiple cites which comp it came from + that comp's source-tier (verified / curated / inferred) + the methodology snapshot version. Cover sheet stamps target_currency + FX-snapshot timestamp + the methodology snapshot.

Downstream consumers

Phase 4 (ten-layer review, Layer 7 competitive-analysis) reads the peer set. Phase 6 (three-scenario model) reads the multiple ranges to bound bull / base / bear pricing. Phase 7 (verdict) reads everything plus the comp_retention_percentage. Phase 10 (memo render) cites the deck by reference.

Why this is a first-class output, not just a column in the deck

Phase 1's thesis gate defers criterion 11 (retention vs comp) because Phase 1 runs before the comp set exists. Phase 3 is the phase that produces the comp set; the closest public comparable's repeat-customer share is therefore Phase 3's responsibility. Phase 7 reads phases.3.output.comp_retention_percentage directly to backfill criterion 11 into the full-twelve verdict aggregation. The key path is documented in engine-sync/SKILL.md so a Phase 7 rewrite never reads a phantom field name.

NO_QUALIFYING_COMP semantics

When no comparable qualifies, the field is null and phases.3.output.no_qualifying_comp carries the rationale. Phase 7 propagates this as DEFERRED on criterion 11, not FAIL — a missing comparable is a data gap, not a thesis miss.

What it checks

Each layer's required inputs are verified before any LLM dispatch fires. Layer 3 (customer-retention) needs Phase 2's verified cohort + Phase 3's comp_retention_percentage; Layer 4 (named-competitive-landscape) needs Phase 3's peer set; Layer 8 (brand-and-digital-asset-valuation) reads Phase 2's commerce side. Missing inputs surface as DEFERRED on the affected layer, never as silent best-effort.

Phase 2 / Phase 3 handshake fail-loud

If Phase 2 returned HARD_PASS without override, Phase 4 fails loud — running structural review against an un-validated revenue figure produces misleading severities. Same for Phase 3 HARD_PASS without override (Layer 4 anchors against the comp set; no comp set means no defensible layer-4 evidence).

N/A semantics

Layers that don't apply to the deal type (e.g. Layer 7 ad-account-health on an all-organic target) are marked NOT_APPLICABLE with an analyst-attested rationale. N/A layers are excluded from the gate aggregator's fail-count denominator — they don't count toward the "multiple Material layers → HARD PASS" rule.

Why discovery first

Each vertical has accumulated knowledge — typical margin ranges, repeat rates, common supply structures, common IP traps, common post-acquisition failure modes — captured in category-knowledge/{slug}.md files. Phase 4 maps deal.categories to per-vertical slugs and loads the corresponding files. Multi-vertical deals (e.g. apparel + home-goods) load multiple files.

Missing file = documented gap, not silent

If a vertical has no knowledge file (a new category, never DD'd before), the run carries an explicit CATEGORY_KNOWLEDGE_GAP on the gate-log. The ten-layer-review skill compensates with broader research at run-cost; the per-layer source-tier downgrades from [curated] to [judgment]; the gate aggregator surfaces CONDITIONAL_PASS as the floor unless the analyst overrides with CATEGORY_KNOWLEDGE_GAP_ACCEPTED.

Compounding knowledge

Per-deal insights emitted by Phase 4 surface to a deal-page review queue. Confirmed insights merge back into category-knowledge/{slug}.md with per-row provenance (deal reference, date, reviewer). The merge is review-gated — never runtime auto-write — so a seller's dataroom can't poison the methodology file for every subsequent deal in that vertical.

The ten layers

Severity rubric per layer (template-binding)

Each layer gets one of three ratings — Material (load-bearing finding; could decide the verdict), Caution (material concern but not decisive on its own), or Minor (polish; surfaces in the memo, doesn't gate). Plus two engine-state sub-states: NOT_APPLICABLE (layer doesn't apply, analyst rationale required, excluded from fail count) and DEFERRED (awaits Phase 5 reputation or Phase 6 scenarios; Phase 7 verdict finalises). The "multiple Material layers → HARD PASS regardless of financial fitness" rule operates on the Material count among in-scope (non-N/A) layers.

Promote / demote rules

Promote to Material if: the layer surfaces an auto-flag (reputation / regulator), OR public-comp deficit is >2× the threshold, OR the gap is the deciding factor in the verdict. Demote to Caution / Minor if: the seller provides independent verification materially reducing the risk (e.g. signed supplier-transition assurance demotes Layer 6 from Material to Caution).

What this is

The first of three IP-clearance surfaces. Detects third-party trademarked branding in the catalogue (BMW, Porsche, Lamborghini, Disney, Marvel, Nike, LV, …) via a four-step path: (a) regex against the methodology-pinned marque list; (b) entity-register scan of Phase 0's seller dataroom for trademark mentions; (c) LLM judgment on catalogue descriptions; (d) cross-vendor consensus when single-vendor confidence < 0.85.

License-evidence chain

When a marque is detected, the license-evidence chain checks USPTO TSDR + EUIPO for the marque's registration + current owner + active enforcement status, then surfaces a license-verification step (brand-owner direct outreach + IP-counsel opinion when the deal proceeds). Per the binding Lesson 11 sub-rule: seller-attested licensing chains are insufficient evidence regardless of deal size. Layer 9 stays Material until the chain produces a verified-licensed conclusion for every detected marque.

What it caught

Carrora — the failure mode this lesson codifies. A "Porsche-branded car care" catalogue with seller-attested licensing that didn't survive a USPTO + brand-owner direct check; the deal walked.

What this is

The second IP-clearance surface. A target selling unbranded private-label goods could still have an unregistered brand name that conflicts with someone else's US/EU mark. The buyer inherits the IP exposure post-acquisition.

Detection path

Extract candidate brand-name(s) from deal.name + deal.domain + any "operating-as / d/b/a" mentions in the seller dataroom. USPTO TSDR query per brand name (status + conflicting registrations); EUIPO query per brand name. Per-geography filter — only conflicts in deal.geographies count toward Layer 9.

Why this is a separate axis from Lesson 11

Lesson 11 is "catalogue uses someone else's trademark" (Porsche). Target's-own-brand clearance is "the target's brand IS someone else's trademark, or is about to collide with one." Both are IP-exposure axes; both feed Layer 9 severity; both must be cleared for the deal to clear above HARD PASS.

What this is

The third IP-clearance surface. Detects oblique substitutes for trademarked brands ("Beamer" for BMW; "Italian Bull" for Lamborghini) — particularly when the same brand appears under two distinct naming conventions within a single catalogue, which the Lesson 12 binding sub-rule classifies as Material by default.

Detection path

LLM judgment on catalogue against a curated substitute list, plus a dual-naming-convention check (does the same referent appear under two different names?). Cross-vendor consensus required — false-positive risk on legitimate category language demands multi-vendor confirmation.

Override path

When detected, override to clear below Material requires "independent comp evidence that category convention drives the naming, not evasion." Analyst-attested with citation; default posture is Material.

What they are

One file per vertical capturing Ecomma's accumulated knowledge — typical margin range, repeat rates, common supply structures, common fraud patterns, common IP traps, common post-acquisition failure modes. Currently in the library: luxury-fashion-dropship.md (Aveugle case insights). New files get authored as a methodology amendment cycle when a new vertical is DD'd.

How they're used

The ten-layer-review skill loads the relevant files into its prompt for every layer's reasoning. A reviewer running Layer 9 on an automotive accessory deal doesn't have to rediscover that car-marque trademarks need USPTO verification — it's already in the knowledge file.

What it does

Builds a sector landscape: TAM, growth rate, value chain, top 5–10 players, valuation context, and the explicit "winners, losers, and why" call. Two methods for TAM (bottom-up preferred, top-down with caveats). Three-state-with-substates source-tier on every figure. Cross-vendor cross-check on the winners-losers call when primary confidence lands in the [0.7, 0.85] band.

Output

{target}_sector-overview.docx — IC-ready document. Structured SectorOverviewOutput consumed by Layer 1 of the ten-layer-review skill, by the competitive-analysis skill (top-players seeds the named landscape), and by Phase 10 memo (executive summary + market context section).

Per M9 resolution

Layer 1 of the ten-layer review imports this skill's TAM + growth rate + winners-losers thesis rather than re-deriving. The skill produces the content; the layer review references it with a methodology-pinned synthesis rule.

What it does

Maps the named competitive landscape: direct competitors with pricing, positioning, tier reading, distribution-channel signal, marketing-mix signal, defensibility moat sources, and the "where does the target sit?" tier reading. Per the binding template: "specific competitors with pricing, positioning, tier reading. Common pitfall: 'no moat' structurally argued without naming specific competitors. The named version is more defensible."

Tier reading rubric

Methodology-pinned tier scale (tier-1 / tier-2 / tier-3 / broker / unranked) with explicit distribution-channel + pricing-index + product-breadth + marketing-mix signals per tier. Tell signals — what reveals the target's true tier vs claimed tier — captured per competitor.

Output

{target}_competitive-analysis.docx — IC-ready document with positioning charts. Structured CompetitiveAnalysisOutput consumed by Layer 4 of the ten-layer-review skill, and by Phase 10 memo (competitive landscape section).

What it does

The canonical engine implementation of ten-layer-template.md. Dispatches per-layer LLM reasoning against the category-knowledge files + sector-overview + competitive-analysis + IP-clearance outputs + Phase 2 financial DD + Phase 3 comp benchmark, assigning severity per the Material/Caution/Minor rubric. Promoted from a research adapter to a skill in this rewrite — the work is too LLM-judgment-heavy to live in research.ts alongside deterministic adapters.

Per-layer output schema (template-binding)

Each layer carries five subsections: (1) what the financial DD covered; (2) what is missing; (3) external evidence with sources; (4) insight — "what no-one in the room would have said"; (5) impact on verdict (strengthens HARD PASS / weakens / supports CONDITIONAL / neutral). The insight subsection is the high-quality-bar element; the skill prompts explicitly for it.

Cross-vendor cross-check on severity

For every layer, when the primary vendor's confidence on the severity assignment lands in the [0.7, 0.85] band, the cross-check vendor runs the same prompt. Divergence captured per layer. Adoption rule: caution-bias (when in doubt, escalate); when cross-check votes less severe than primary, the layer becomes DEFERRED for analyst arbitration.

Compounding knowledge candidates

Insights surfacing during the layer review that aren't already in the relevant category-knowledge/{slug}.md are emitted as candidates to the deal-page review queue — confirmed by analyst (or IC) before merging into the methodology file with per-row provenance. Never runtime auto-write.

Output

{target}_ten-layer-review.docx — IC-ready document with the ten per-layer subsections rendered from TenLayerReviewOutput.verdicts. Structured output consumed by Phase 4 gate aggregator (Material count rule) and by Phase 7 verdict (severity-modulation against Phase 1 thesis-fit gate).

The circular dependency

The template's Layer 9 binding rule requires Phase 5 reputation results ("auto-flagged reputation issues are automatically Material"). Layer 5 (flip-viability) requires Phase 6 scenario output. But Phase 5 + Phase 6 run AFTER Phase 4 in the orchestrator's PHASE_FUNCTIONS order. Re-ordering phases would break the recall write against prior runs and the run-package writer.

The resolution: split-and-revisit

Phase 4 produces first-pass severity with the inputs it has. Layers needing Phase 5/6 data carry severity: 'DEFERRED' + a populated awaiting field naming the upstream phase. Phase 7 verdict assembly reads the DEFERRED set + Phase 5/6 outputs and finalises severities. Same proven pattern as Phase 1 criteria-11/12 → Phase 7 backfill.

Exception: Layer 9 with IP-trigger fired

When any IP-clearance check (third-party / target-own / oblique-substitute) detects a trigger, Layer 9 severity is Material immediately — no waiting on Phase 5 reputation. The reputation cross-reference can only escalate; the IP-trigger establishes the floor at Material.

Aggregation rules (priority order)

1. OVERRIDE_PROCEED — a non-expired analyst override for the phase is set.
2. HARD_PASS — any of: (a) Layer 9 Material from an IP-trigger AND no verified-licensed conclusion in the license-evidence chain; OR (b) ≥2 layers at Material with auto-flag triggers (reputation/regulator/comp-deficit > 2× threshold).
3. CONDITIONAL_PASS — any of: (a) 1 layer at Material without auto-flag (documented remediation path possible); (b) any layers DEFERRED awaiting Phase 5/6; (c) any category-knowledge file missing (documented domain-knowledge gap).
4. PASS — otherwise.

N/A excluded from fail-count denominator

Layers marked NOT_APPLICABLE are not counted toward the "≥2 Material" threshold — they're structurally not in scope, not a clean signal. Analyst-attested rationale required for every N/A.

• LAYER_FAIL_WITH_CONTRACTUAL_REMEDIATION — layer fail mitigated by signed contractual remediation (e.g. supplier-transition assurance).
• IP_LICENSE_VERIFIED_OUT_OF_BAND — license evidence captured outside the engine (analyst-attested with citation).
• SUPPLIER_RISK_ACCEPTED_WITH_INSURANCE — Layer 6 concentration accepted because key-supplier insurance / hedge in place.
• CATEGORY_KNOWLEDGE_GAP_ACCEPTED — no category-knowledge file exists but analyst affirms domain expertise.
• AD_ACCOUNT_HEALTH_DATA_UNAVAILABLE — Layer 7 ad-account-health can't be pulled (no Meta/Google access granted; public proxies suffice).
• PHASE_5_6_DEFERRED_LAYER_PROCEED — Phase 4 first-pass severity accepted as final; Phase 7 doesn't re-finalise.

Gate log

10_dd-output/{date}_{target}_phase4-gate-log.json — written on every run regardless of outcome. Contains: input-contract state per layer, category-knowledge discovery results, IP-clearance three-surface outcome, per-skill .ok statuses, per-layer verdict with rationale + evidence + source-tier + insight + impact-on-verdict, gate state, override (if any).

Three deliverable docx files

{target}_sector-overview.docx · {target}_competitive-analysis.docx · {target}_ten-layer-review.docx — produced by the three skills above. Filed in the deal's Drive folder, surfaced on the deal page.

Phase 7 read path

Phase 7 verdict reads phases.4.output.layerVerdicts for the "multiple layer-fails → HARD PASS regardless of financial fitness" rule enforcement, plus phases.4.output.deferredLayers to know which layers to finalise after Phase 5/6 produce their outputs.

Why discovery first

The list of platforms that matter is not fixed in advance. Some categories have category-specific review aggregators (e.g., baby-product communities, automotive forums); some markets have dominant local review sites (Kiyoh in NL, eKomi in DE, Avis Vérifiés in FR, Recensioni Italia, Yandex Reviews in Russia-adjacent markets, BBB in the US for certain categories); some brands accumulate signal on Pinterest, Etsy, Amazon product pages, Yelp, or Facebook reviews more than on Trustpilot. The engine discovers which surfaces actually hold review volume for this target before it commits to which surfaces to read in depth.

How discovery runs

• Search the target's brand name + "reviews" / "ervaringen" / "avis" / "rezensionen" / category-specific equivalents across major engines.
• Probe the standard platforms (Trustpilot, Google reviews, Yelp, Facebook reviews, Sitejabber, ResellerRatings, Glassdoor for the employer surface, Reddit for organic mentions) and capture the review-volume on each.
• Probe category-specific and locale-specific aggregators known to Ecomma's lessons table (the list grows over time).
• Rank surfaces by review-volume × platform-credibility-factor (Trustpilot scores high on volume + credibility; a local 8,000-review platform scores high on volume; a 3-review platform on any service scores low).

Output of discovery

A reputation-surfaces.json for this target with every surface found, the volume, the platform-credibility, and the priority order in which the in-depth checks will run. Surfaced on the deal page so the analyst can add or remove a surface before the in-depth pass fires.

What it is

Trustpilot is the largest public reviews platform in many markets. The paid-tier API gives us per-review metadata: timestamp to the second, reviewer history, review text. The free tier only gives aggregates — useless for the per-platform integrity checks.

What we look for (applied per platform, not just here)

• Clusters in time. Many reviews submitted within minutes of each other.
• Templated language. Reviews with near-identical phrasing.
• Reviewer history. Reviewers who only ever reviewed this business and nothing else.
• Geographic anomalies. All five-star reviews coming from one country the target doesn't ship to.

Aveugle had clustered batches of five-star reviews posted in 90-second windows, all from accounts with zero other history, repeating the same phrasing. That alone moved the deal from CONDITIONAL to HARD PASS.

Important: a target with low Trustpilot volume is not automatically a low-reputation target. The engine checks Trustpilot, then checks every other discovered surface; the integrity verdict is the aggregate.

Google Reviews via the Places API. Per-review metadata is more limited than Trustpilot's paid tier, but volume and timing are recoverable. The same spike-detection + templated-language + reviewer-history rules apply. Reviewer-history pattern is weaker (Google reviewer profiles are sparser), so this surface contributes more to the volume aggregate than to the templated-language signal.

Facebook reviews, Yelp (US), Sitejabber, and ResellerRatings each contribute a volume + integrity signal. The engine reads each surface where the target has >5 reviews (volume threshold below which the integrity checks lose statistical meaning). Each surface's verdict aggregates into the volume-weighted reputation score.

Why this is its own row

A US-only review surface set systematically misses signal for targets in other markets. The Netherlands has Kiyoh, klantenvertellen.nl, and Trustprofile. Germany has eKomi and Trusted Shops. France has Avis Vérifiés and Trustfolio. Italy has Recensioni Italia. The UK has Reviews.io. Each market has dominant local aggregators that Trustpilot does not displace.

The lesson

In a recent manual DD, a NL-market local aggregator (Kiyoh) held ~8,000 reviews for a target while Trustpilot held 3. A reputation phase that only read Trustpilot would have produced "low review volume, integrity inconclusive" — the wrong answer. Reading Kiyoh changed the verdict materially.

How it runs

The engine maintains a per-market table of dominant local aggregators (locale-keyed via target's primary geography from the deal form). It probes each, captures volume, and reads in depth where volume passes the threshold. The table is editable in project-starter/.claude/skills/run-deal-dd/references/reputation-surfaces.md; new local surfaces get added as lessons surface them.

Beauty has Sephora Community + MakeupAlley + Reddit r/SkincareAddiction. Baby/Kids has BabyCenter community + What to Expect forums. Automotive has marque-specific forums plus YouTube channel commentary. Home & Décor has Houzz + Etsy reviews + Pinterest sentiment. Apparel has Lyst + Style forums + brand-Reddit subs. The engine reads the per-category aggregators known to Ecomma's lessons table for the target's primary category.

Reddit's API gives us recent mentions of the target's brand name, sentiment, and context. Useful for catching organic complaints (subreddits like r/scams or category-specific communities often surface problems before reviews catch up) and founder-posted content (the founder may have promoted on Reddit in ways that contradict the seller's current narrative).

Broad news search for any mention of the target. Catches regulatory actions, product recalls, lawsuits, and any incident that left a public footprint. Multi-language coverage (the target may be discussed primarily in its operating-market language; English-only news search systematically under-reads).

How surfaces combine

Each surface produces an integrity verdict: CLEAN (no spike, no templated language, no reviewer-history anomaly), SUSPICIOUS (one signal flagged), or FRAUDULENT (two or more signals flagged, or a single signal flagged at severe magnitude). The aggregate verdict is volume-weighted: a surface with 8,000 reviews contributes ~2,667× more weight than a surface with 3 reviews; a surface with credibility-factor 1.0 weighs equally per-review with another credibility-1.0 surface. The aggregate verdict is what Phase 7 backfills as criterion 12's score.

Divergence

When surfaces disagree at meaningful weight (one major surface flags FRAUDULENT, another flags CLEAN), the divergence is surfaced on the deal page with both verdicts shown. The analyst sees the disagreement before the verdict is locked.

The "low volume everywhere" case

If the target has below-threshold review volume on every surface, the aggregate verdict is INSUFFICIENT_VOLUME — not CLEAN. A new business with no reviews is not "reputation-verified clean"; it is "reputation-not-yet-evaluable." Criterion 12 then defers with the missing-volume rationale; Phase 7 surfaces the deferral in the memo.

Staging (v1.0.0 per Phase 5 audit-quad recommendation)

Core surfaces (Trustpilot + Google Reviews + Reddit + news + per-locale local-aggregator template) are wired this cycle. Long-tail surfaces (Yelp, Facebook reviews, Sitejabber, ResellerRatings, Glassdoor, BBB, category-specific aggregators) are typed stubs flagged deferred_long_tail on the discovery output so the analyst sees which surfaces aren't yet pulled for this run. Adapter implementation lands in a follow-up cycle.

The hybrid: deterministic + LLM judgment

Spike detection, reviewer-history anomaly, and geographic-anomaly are deterministic — the per-signal severity is the output of a math computation against methodology-pinned thresholds (≥ 10 reviews / ≤ 90s for spikes; ≥ 30% zero-history reviewers for fraudulent; ≥ 80% single-geography for fraudulent). These live in research.ts adapters.

Templated-language is LLM judgment — distinguishing "this is templated phrasing reflecting fraud-like coordination" from "this is natural-language repetition (category vernacular, brand-loyalist phrases, response to a brand-prompted review request)." The deterministic similarity computation (embedding-cosine ≥ 0.9 on review-pair text) flags candidate pairs; the skill's LLM call judges the candidate set with cross-vendor cross-check in the [0.7, 0.85] confidence band per the Phase 1 confidence-band pattern.

GDPR + reviewer-data restriction

In GDPR-scope locales (EU member states), reviewer-history scanning is skipped at the deterministic-adapter level — the skill respects that gap and does NOT attempt to backdoor reviewer enrichment via the LLM prompt. Documented gap surfaces on the deal page; override path GDPR_PRIVACY_CONSTRAINT_ACCEPTED for analyst attestation.

Aveugle regression fixture

The Aveugle pattern (10 clustered 5-star reviews from zero-history accounts in a 90-second window, repeating phrasing) is the canonical regression-protect test fixture. The skill must catch this pattern at every methodology-version snapshot; the vitest fixture asserts the deterministic + LLM-judgment chain produces a per-surface FRAUDULENT verdict on the synthetic Aveugle corpus.

The handshake the rewrite closes

Phase 4's runTenLayerReview emits Layer 9 (legal-IP-exposure) with severity: 'DEFERRED' + awaiting: 'phase5_reputation' when no IP-trigger fired at Phase 4. Per the binding ten-layer-template's Lesson 11 sub-rule, *"auto-flagged reputation issues are automatically Material"* — meaning a fraudulent reputation signal escalates Layer 9 from DEFERRED to Material. Phase 5 produces the auto-flag signal; Phase 7 verdict reads it to finalise Phase 4's Layer 9.

The signal

Phase 5's extractLegalIpAutoFlag adapter fires when ANY surface produces a SUSPICIOUS or FRAUDULENT verdict. Phase 5 output schema includes legalIpAutoFlag: { fired, surfaces[], rationale } — the field Phase 7's verdict-assembly code reads. Fires also surface on the deal page so the analyst sees the cross-phase escalation before the verdict locks.

Aggregation rules (priority order)

1. OVERRIDE_PROCEED — a non-expired analyst override is set for the phase.
2. HARD_PASS — aggregate verdict FRAUDULENT AND ≥2 surfaces at SUSPICIOUS/FRAUDULENT (multi-surface confirmation; single-surface fraud is CONDITIONAL_PASS pending analyst review).
3. CONDITIONAL_PASS — aggregate verdict SUSPICIOUS, OR single-surface FRAUDULENT, OR INSUFFICIENT_VOLUME across all surfaces (deferred criterion 12).
4. PASS — aggregate verdict CLEAN.

Override reason codes (Phase 5 operational)

• FRAUDULENT_SIGNAL_CATEGORY_NORM_ACCEPTED — fraud signal is category-baseline (some verticals routinely cluster on launch-day promotions)
• INSUFFICIENT_VOLUME_NEW_BUSINESS_ACCEPTED — new business, no reviews yet, analyst attests that reputation evaluation will land at next-quarter review
• LANGUAGE_GAP_ANALYST_TRANSLATED — non-English coverage gap manually closed by analyst
• CROSS_PLATFORM_DEDUP_GAP_ACCEPTED — reviewer-identity dedup not yet wired; analyst attests no cross-platform pattern
• SELLER_GAMING_FLAG_ACCEPTED — post-LOI manipulation suspected; analyst attests pre-LOI baseline is authoritative (the audit-quad-flagged risk)
• GDPR_PRIVACY_CONSTRAINT_ACCEPTED — reviewer-history scanning skipped per data-protection law in EU geographies
• EMPLOYER_SURFACE_OUT_OF_SCOPE_ACCEPTED — Glassdoor / employer-review surfaces excluded from consumer-reputation aggregate (e.g. sole-proprietor target with no employees)
• REVIEW_AGE_NORMALISED_ACCEPTED — recent spike against a decade-old corpus of legitimate reviews; analyst attests the demote rule applies

Gate log

10_dd-output/{date}_{target-slug}_phase5-gate-log.json — persisted via the shared writeGateLogFile helper. Always attempted regardless of outcome. Contains: input contract state, surface discovery output, per-surface pull statuses, per-surface verdicts with per-signal rationale + cross-check trace, volume-weighted aggregate, legalIpAutoFlag, gate state, override (if any). Surfaced on the deal page as the per-surface audit trail.

Phase 7 read path

Phase 7 verdict reads phases.5.aggregate_reputation_verdict for criterion-12 backfill (stable key path documented in engine-sync SKILL.md to prevent silent rename drift; .output prefix retired per Phase 7 audit H12 coherence pass — engine stores phase outputs at priorOutputs.phaseN, no nested .output wrapper). INSUFFICIENT_VOLUME propagates as DEFERRED on criterion 12, not FAIL — mirrors Phase 3's NO_QUALIFYING_COMP design.

What an LBO is

"Leveraged buyout." The standard way private-equity buyers underwrite acquisitions. You assume a purchase price, layer in some debt, model the cash flows over a hold period (typically 5 years for Ecomma's deals), assume an exit valuation, and compute the return on your invested equity.

What this skill produces

An Excel file with: Sources & Uses (where the money to buy the deal comes from), an operating model (what the business does each year), a debt schedule (how much we owe over time), and a returns analysis (IRR — internal rate of return; MOIC — multiple on invested capital). Plus sensitivity tables — what happens if the exit multiple is one turn lower, or two years later, or both.

The three scenarios

Methodology-pinned assumption deltas per scenario, anchored to upstream phase outputs (the bear case is NOT a free LLM judgment — it's anchored to Phase 4 Layer 6 supplier concentration, Phase 4 Layer 7 ad-account health, and Phase 5 reputation aggregate):

• Bull: DTC efficiency +15%, supplier cost −5%, terminal multiple at peer-set p75, retention +5%, exit Year 5
• Base: Year-0 trend assumptions, terminal multiple at peer-set median, exit Year 5
• Bear: DTC efficiency −20%, supplier cost −10% (−20% if Phase 4 Layer 6 Material), retention −10% (−15%/−30% if Phase 5 reputation SUSPICIOUS/FRAUDULENT), terminal multiple at peer-set p25, exit Year 4 (pulled forward)

Probability weights (methodology-pinned)

Default: bull 25% / base 50% / bear 25%. Analyst override via SCENARIO_WEIGHTS_ANALYST_OVERRIDE reason code with mandatory citation. Cross-vendor cross-check on override weights when analyst calibration confidence in [0.7, 0.85] band.

Sensitivity grid

3D grid: exit-multiple delta (−1, −0.5, 0, +0.5, +1 turns) × exit-timing delta (−1, 0, +1 years) × DTC-efficiency delta (−10%, −5%, 0%, +5%, +10%). 75 cells total, rendered as three nested tables in the LBO Excel.

The handshake the rewrite closes

Phase 4's runTenLayerReview emits Layer 5 (flip-viability) with severity: 'DEFERRED' + awaiting: 'phase6_scenarios' per the split-revisit pattern from Phase 4's decision page D3. Per the binding ten-layer-template Layer 5 rule, *"show the arithmetic for the probability-weighted expected return explicitly"* — Phase 6 produces the arithmetic; Phase 7 verdict reads it to finalise Layer 5.

The signal

Phase 6's computeFlipViabilitySignal produces: scenarioWeightedExpectedReturn (Σ probability × IRR across scenarios), downsideSpreadToBase ((base − bear) / |base|), bearCaseSeverity (clean / caution / material per methodology-pinned thresholds — >50% downside-spread or negative expected return → material; 30–50% → caution; <30% → clean).

Phase 7's read

Phase 7 reads phases.6.output.flipViabilitySignal.bearCaseSeverity and maps it directly to Phase 4 Layer 5's final severity. If material, Layer 5 lands at Material in the final ten-layer record + verdict aggregator.

Aggregation rules (priority order)

1. OVERRIDE_PROCEED — a non-expired analyst override is set for the phase.
2. HARD_PASS — bear-case IRR < methodology floor (default 0%) AND no override. The floor exists because a bear-case loss-on-invested-capital is a deal that should at minimum require explicit analyst attestation before proceeding.
3. CONDITIONAL_PASS — flipViabilitySignal.bearCaseSeverity is caution OR material (high downside spread; deal proceeds with named tail-risk on the deal page).
4. PASS — bear-case IRR ≥ floor AND downside-spread within tolerance.

Override reason codes (Phase 6 operational)

• BEAR_CASE_BELOW_FLOOR_ACCEPTED — bear-case IRR < 0; analyst attests (e.g. earn-out structure absorbs the variance)
• SCENARIO_WEIGHTS_ANALYST_OVERRIDE — analyst override of methodology-pinned probability weights with mandatory citation
• TERMINAL_VALUE_BAND_RELAXED — exit multiple outside p25–p75 of comp-set; analyst attests
• MULTI_ENTITY_CONSOLIDATION_SCENARIO_GAP_ACCEPTED — multi-entity target without per-entity consolidation; parent-entity LBO rendered with analyst attestation

Gate log

10_dd-output/{date}_{target-slug}_phase6-gate-log.json — persisted via the shared writeGateLogFile helper. Always attempted regardless of outcome. Contains: input contract state, per-scenario assumptions + IRR / MOIC / yearly cash flows, expected-return-weighted, flipViabilitySignal, gate state, override (if any).

Excel artefacts

The LBO model and the cash-flow sidecar with all three scenarios. The sidecar is structured so any IC member can compare the three side by side without having to switch tabs.

Phase 7 read paths

Phase 7 verdict reads phases.6.output.expected_return_weighted for verdict-assembly arithmetic, and phases.6.output.flipViabilitySignal for Phase 4 Layer 5 finalisation.

Before the rules-canonical verdict-assembly fires, the engine verifies it has every input it needs: phases.1.deferredCriteria array, phases.2.repeat_share, phases.3.comp_retention_percentage (or no_qualifying_comp), phases.4.layerVerdicts + phases.4.deferredLayers, phases.5.aggregate_reputation_verdict + phases.5.legalIpAutoFlag, phases.6.flipViabilitySignal + phases.6.expected_return_weighted. Any missing input surfaces as missingReasons on the gate-log and downgrades the per-phase gate state to CONDITIONAL_PASS rather than producing a verdict against incomplete inputs.

This closes the audit's H5 finding (no gate-input contract). The engine never silently produces a verdict against partial data.

Why the backfill is Phase 7's responsibility

Phase 1's thesis gate scored ten criteria at intake and deferred two — criterion 11 (retention vs. public comp) needed Phase 3 to produce the comp set; criterion 12 (reputation) needed Phase 5 to run the multi-source reputation sweep. Both inputs now exist. Phase 7 is the first phase that has access to all twelve criteria simultaneously, so it is the phase that completes the gate.

Criterion 11 backfill

The engine reads phases.3.comp_retention_percentage (the closest-comparable retention figure Phase 3 produced under the methodology-aligned comparison rule) and the target's own trailing-12-month repeat-customer share from phases.2.repeat_share. Threshold check: target within 20 percentage points of the comparable. Returns PASS / NEAR / FAIL per the threshold, or DEFERRED if Phase 3 returned NO_QUALIFYING_COMP.

Criterion 12 backfill

The engine reads phases.5.aggregate_reputation_verdict (the volume-weighted aggregate Phase 5 produced across every reputation surface it probed) and maps it onto the gate vote: CLEAN → PASS, SUSPICIOUS → NEAR, FRAUDULENT → FAIL, INSUFFICIENT_VOLUME → DEFERRED. The per-surface divergence record from Phase 5 is preserved and surfaced in the memo when divergence is meaningful.

Final twelve-criterion aggregation

The full twelve criteria — Phase 1's ten plus the two backfills — are aggregated under the same four-state rule Phase 1 uses (PASS / CONDITIONAL_PASS / HARD_PASS / OVERRIDE_PROCEED). A FAIL on backfilled criterion 11 or 12 can move a CONDITIONAL_PASS to HARD_PASS or restructure an existing verdict. The verdict-assembly rules treat backfilled fails the same as gate-time fails — there is no discount for "found late."

What gets persisted

The backfill writes {date}_{target}_thesis-tracker.docx with the full twelve-criterion scorecard (gate-time + backfilled), and updates phase1-gate-log.json with a backfill sub-record that ties each backfilled score to its source phase output. The original Phase 1 gate verdict is preserved unmodified; the backfill is additive.

Why the finalisation lives in Phase 7

Phase 4 produces first-pass severity for the ten layers with the inputs it has. Layer 5 (flip-viability) needs Phase 6's bear-case scenario arithmetic; Layer 9 (legal-IP-exposure, when no Phase 4 IP-trigger fired) needs Phase 5's reputation auto-flag. Both layers carry severity: 'DEFERRED' + awaiting: 'phase6_scenarios' | 'phase5_reputation' out of Phase 4. Phase 7 is the first phase that has access to both Phase 5 and Phase 6 outputs, so it is the phase that finalises.

Layer 5 finalisation

The engine reads phases.6.flipViabilitySignal.bearCaseSeverity and maps directly: clean → Minor, caution → Caution, material → Material. The finalised severity replaces the DEFERRED in the ten-layer record. If Material, the verdict-arithmetic checks Phase 6's bear-case IRR — Material Layer 5 with bear-IRR below floor is a HARD PASS.

Layer 9 finalisation

The engine reads phases.5.legalIpAutoFlag. Mapping: fired=false → Minor; fired=true with one surface → Caution; fired=true with two or more surfaces → Material. Material Layer 9 (legal-IP exposure substantiated by Phase 5 surfaces) is a HARD PASS reason code regardless of any other layer.

Template-version-skew check

Phase 7 records the ten-layer-template version Phase 4 ran against (phases.4.templateVersion) and compares against the methodology snapshot bound at run-start. Mismatch surfaces as a sense-check field on the gate-log. Override path TEMPLATE_VERSION_SKEW_ACCEPTED lets the analyst attest mid-run version-bump was analyst-driven.

Why rules, not LLM judgment

The terminal verdict is the most-consequential decision in the engine. Letting an LLM produce the verdict creates an irresolvable question: when the LLM says PASS but the rule-arithmetic on prior-phase outputs says HARD PASS, which wins? Phase 7's rewrite removes the question. Deterministic arithmetic on the prior-phase outputs produces the verdict. The LLM is called only to write the rationale prose for the memo — never to decide the verdict.

HARD PASS triggers (priority-ordered)

• Backfilled criterion 11 (retention) is FAIL
• Backfilled criterion 12 (reputation) is FAIL
• Phase 5 aggregate reputation is FRAUDULENT
• Phase 4 Layer 9 (legal-IP exposure) finalised as Material
• Phase 4 Layer 6 (supplier concentration) is Material
• Phase 4 has two or more Material layers (post-finalisation)
• Phase 4 Layer 5 finalised as Material AND Phase 6 bear-IRR below 0%
• Phase 6 bear-case IRR below 0% floor

CONDITIONAL triggers

• Exactly one Material layer post-finalisation
• Any DEFERRED criterion (11 or 12) post-backfill
• Phase 6 expected-return-weighted below 12% threshold
• Phase 5 aggregate reputation is SUSPICIOUS

Otherwise PASS. Full rules: Due-Diligence-Engine/verdict-aggregation-rules_2026-05-21.md (methodology amendment file).

Defines the default AND-conditions per HARD PASS reason code. If a deal is HARD PASS because of supplier concentration, the default triggers are: "supplier table diversified to ≤30% top supplier AND 12 months of audited financials available AND price reduced by ≥25%." All three have to be true for the deal to come back to us. Three minimum per reason code — single triggers are gameable. Full per-code defaults: Due-Diligence-Engine/re-engagement-defaults_2026-05-21.md. Measurement-source paths pinned per condition so Phase 8 HubSpot recall serialises the exact downstream field to re-check.

Phase 7's per-phase gate state

Phase 7's own per-phase gate state mirrors the four-state model every other phase uses: PASS, CONDITIONAL_PASS, HARD_PASS, OVERRIDE_PROCEED. HARD_PASS fires when the terminal verdict is HARD_PASS. CONDITIONAL_PASS fires when input contract has missing reasons OR terminal verdict is CONDITIONAL.

The terminal verdict is three states, NOT four

The IC reads terminalVerdict: PASS | CONDITIONAL | HARD_PASS. OVERRIDE_PROCEED is per-phase gate state only — it does not propagate as a fourth terminal verdict. The IC sees the override on the deal page next to the verdict it modulated, but the verdict stays in the three-state enumeration.

Override codes

• BACKFILL_DIVERGENCE_ACCEPTED — Phase 1 gate PASS but backfilled criterion 11/12 FAIL; analyst accepts gate
• MULTIPLE_MATERIAL_LAYERS_OVERRIDE_ACCEPTED — Phase 4 ≥2 Material; analyst attests deal correctly priced
• BEAR_CASE_PHASE6_OVERRIDE_PROPAGATED — Phase 6 BEAR_CASE_BELOW_FLOOR_ACCEPTED; Phase 7 propagates
• REPUTATION_PHASE5_OVERRIDE_PROPAGATED — Phase 5 SELLER_GAMING_FLAG_ACCEPTED etc; propagated forward
• PRE_MORTEM_DOWNGRADE_ACCEPTED — arithmetic says PASS; pre-mortem surfaces deal-killer; analyst downgrades
• CONDITIONAL_OFFER_ANALYST_ATTESTED — conditional-offer terms outside verdict-assembly arithmetic
• TEMPLATE_VERSION_SKEW_ACCEPTED — Phase 4 ran against older template version than Phase 7 snapshot

Override-against-which-phase

Per-phase overrides remain logged against the contributing phase. A Phase 6 override stays at Phase 6 with its phase-specific reason code; Phase 7's collectUpstreamOverrides reads each contributing phase's override state and surfaces the propagation chain via the gate-log audit trail. Phase 7's own override codes (above) cover only cross-phase aggregation decisions.

The adversarial pre-mortem skill takes the rule-derived verdict + the structured charges and generates five risks total — typed by category across operating, market, financial, and governance dimensions. 18-month measurement horizon per methodology pin. Cross-vendor cross-check on the risk ranking lands with the byo-pre-mortem SKILL.md authoring cycle (deferred per audit-quad scope-down). Pre-mortem findings inform but do not normally modulate the verdict; the explicit override path PRE_MORTEM_DOWNGRADE_ACCEPTED handles the case where the analyst escalates a pre-mortem finding to deal-killer.

Gate log

10_dd-output/{date}_{target-slug}_phase7-gate-log.json — persisted via the shared writeGateLogFile helper. Contains: methodology version + ten-layer-template version, input contract state, full verdict assembly (terminal verdict, reason code, structured charges, criterion backfills, finalised layer verdicts, re-engagement triggers, pre-mortem risks, conditional offer if any), upstream-override propagation chain, gate state, override (if any).

Phase 8 / Phase 10 read paths

Phase 8 (HubSpot recall) reads phases.7.terminalVerdict, phases.7.reasonCode, phases.7.charges, phases.7.reEngagementTriggers. Phase 10 (memo render) reads all of the above plus phases.7.criterionBackfills (memo Section 3), phases.7.finalisedLayerVerdicts (Section 7), phases.7.preMortemRisks (Section 11), phases.7.assembly.conditionalOffer (Sections 2 + 4). Pinned in engine-sync SKILL.md to prevent silent rename drift.

Idempotency contract

Phase 7 reads the priorOutputs snapshot as-passed at invocation. If an upstream analyst override lands AFTER Phase 7 has completed, Phase 7 does NOT auto-rerun — an explicit re-execution flag (recorded against the run, e.g. runs.requires_phase7_rerun = true) is required. The deal-page surfaces the pending-rerun state so the IC sees the verdict is stale.

One write. Updates the deal record with: methodology version, verdict, reason code, AND-conditions, link to the memo in Drive, link to the run on dd.ecomma.co. The next time Phase 0 reads this deal, the recall is complete.

The engine emails the seller a link to a structured response form. Each open issue from the prior phases becomes a question. The seller's answers flow back into the engine and become a section in the memo.

Builds a per-deal scorecard: the falsifiable thesis statement, the supporting pillars, the risks, the catalysts, the pre-committed stop-loss triggers. If we acquire the deal, this scorecard is what the operating team tracks monthly to know whether the thesis is still intact or whether it broke.

The fourteen memo sections

1. Executive summary
2. Verdict
3. Thesis fit (all 12 criteria scored)
4. Financial DD
5. Cash flow + working capital
6. Comparables
7. Ten-layer findings
8. Reputation
9. Three-scenario model
10. LBO returns
11. BYO pre-mortem
12. What we did NOT verify (the explicit disclosure)
13. Quad Review disposition
14. Appendix — thesis-tracker scorecard

The DD memo. Every numerical claim in the document is tagged [verified], [derived], [inferred], [benchmark], or [judgment] so the reader can see at a glance what's forensic and what's estimated. Inferred and judgment numbers render visually distinct in the docx.

What it is

A Python script. Walks every cross-reference in the run's artefacts: revenue stated in the memo's executive summary has to match revenue in the financial DD section, which has to match the model's revenue line, which has to match the data pack's revenue cell. Any drift is a hard error.

Why a script, not an AI

This is exact-match arithmetic. Cheaper, faster, and more reliable to do mechanically than to ask an AI.

The same skill from Phase 2, but run against every Excel file produced this run — the 3-statement model, the LBO model, the data pack, the cash-flow sidecar. Catches anything the scenario tweaks or model-update steps introduced.

The five tags

• [verified] — from a sourced document with citation
• [derived] — arithmetic from verified inputs (e.g. GM = GP / Revenue)
• [inferred] — assumption made because data is missing, with explicit caveat
• [benchmark] — category baseline from a cited industry source
• [judgment] — analyst opinion / scenario probability

The verifier scans the memo prose. Every numerical claim must carry one of the five tags. Untagged claims block render. This is the anti-hallucination guard — added after Carrora, where unstated assumptions slipped into the memo as if they were facts.

Claude reviews the memo against the eight standard charges. For each charge, Claude returns one of: SUSTAINED (the charge holds), DISMISSED (the charge doesn't apply), or MODIFIED (the charge applies in a slightly different form). Claude is also the model that drafted the memo, so its review is treated with the lightest weight — it has a coherence bias toward its own output.

Independent reviewer trained on a different corpus and with different alignment objectives. Same eight charges. GPT tends to catch unstated assumptions and over-claimed certainty.

Same eight charges, fresh perspective. Gemini was trained differently than Claude, so it catches different things. Particularly strong on completeness — flagging weaknesses the memo failed to address.

Fourth independent reviewer. Different training origin from the other three. In practice, DeepSeek consistently pushes back on overreach, gold-plating, and assertions presented as facts when the source material is ambiguous — useful adversarial pressure that the other three (more consensus-leaning) reviewers sometimes miss.

1. Verdict-evidence mismatch — does the conclusion follow from the evidence presented?
2. Unsourced numbers — any number in the memo without a source citation?
3. Hallucinated comparables — any comp that doesn't actually exist or isn't actually similar?
4. Unstated assumptions — anything treated as fact that's actually an assumption?
5. Missed counter-evidence — any signal in the data that should have been addressed but wasn't?
6. Override path bypass — has the methodology's required override path been followed for any conditional pass?
7. IP-verification gaps — for catalogues with third-party trademarks, was Lesson 11 applied?
8. Recall registry compliance — has the verdict been written back to HubSpot with proper AND-conditions?

When it fires

Only when the Quad Review returns RESTRUCTURED or OVERRULED. The script walks the cross-reference graph deterministically — for the lesson identified, which reference files should change? It proposes diffs, runs a regression on the Aveugle fixture to make sure the new rules don't break the old verdict, and increments the methodology version. The library gets smarter on every restructured deal.

Structured record of each reviewer's verdict on each of the eight charges, plus the final disposition: UPHELD (memo ships as-is), RESTRUCTURED (verdict outcome holds but reasoning gets revised), or OVERRULED (the verdict itself is wrong and affected phases need to be re-run). This file is included in the deal's Drive folder and surfaced on the deal page so anyone reading the memo can see what the reviewers said.

Filename note: the file is currently named trifecta-disposition.json for historical reasons (the review was three-vendor before DeepSeek joined). The schema rename to quad-disposition.json ships with engine migration F21 in coordination with the trifecta_verdicts table rename.

The gate still runs

An override does not skip the gate. The gate runs, the criterion is scored, the verdict is captured. The override is the analyst's decision to proceed despite the gate's verdict — not to bypass the scoring entirely. This means the engine always has the gate's verdict on record, and the memo can say "the gate said HARD PASS on criterion 8 because GM was 32%, below the 50% Apparel floor; the analyst overrode with reason X." Both states are visible.

Per-criterion override eligibility

The acquisition-thesis.md reference declares override_eligibility per criterion as a structured field with allowed and valid_reason_codes. The twelve thesis criteria have allowed: true with a constrained valid_reason_codes set — e.g., niche fit (C1) accepts IC_STRATEGIC or CATEGORY_OUTLIER_JUSTIFIED; revenue floor (C3) accepts DATA_GAP_TEMPORARY (with mandatory expiry) or IC_STRATEGIC; gross margin (C8) accepts CATEGORY_OUTLIER_JUSTIFIED or IC_STRATEGIC, never DATA_GAP_TEMPORARY alone. The seven hard disqualifiers (edible/perishable, adult, self-fulfilled, banned ad accounts, active legal disputes, uncooperative seller, asset-transfer blockers) have allowed: false with valid_reason_codes: [] — they are not analyst-overridable at all. The pathway for proceeding on a disqualifier is the separate HubSpot IC-waiver workflow: a deal record carries an explicit waiver decision made by the IC before the run starts; the engine reads that at run-start and treats the disqualifier as pre-cleared for the run, never as an override decision made during the run. The engine rejects an analyst-set override whose reason_code is not in the criterion's valid_reason_codes list (or whose criterion has allowed: false) with a typed error surfaced on the deal page, not a silent acceptance.

Why typed reasons

Free-form override text is unreviewable in aggregate. Typed reasons let the engine answer questions like "which criteria get overridden most often, by which analysts, with which justifications, and how do those overrides perform downstream?"

The reason codes

• IC_STRATEGIC — Investment Committee pre-flagged this deal for strategic reasons that override the criterion. Free-form supplement required; IC member identified.
• DATA_GAP_TEMPORARY — The criterion failed because of a known data gap that's being closed in a separate workstream. Override is time-bounded; expires at a stated date.
• CATEGORY_OUTLIER_JUSTIFIED — The target is an outlier within its category in a way that makes the methodology threshold misapplied. Comparable target citation required.
• FOUNDER_RELATIONSHIP — Pre-existing founder relationship justifies engagement despite the gate signal. Relationship documented in HubSpot.
• LESSON_PRE_EARNED — The criterion was added after this deal was already in flight; retrospective scoring should not block continuing.
• OTHER — Catch-all for cases not covered above. Free-form text required; reviewed by IC at the next monthly cadence to decide if a new reason code is needed.

Required fields for every override

• reason_code — one of the typed reasons above.
• reason_text — free-form supplement, mandatory regardless of reason code.
• analyst — Google OAuth subject of the analyst who set the override.
• ic_visibility — boolean. Default true. False only if the IC has separately authorised the override class for this deal stage.
• expires_at — UTC date. Required for DATA_GAP_TEMPORARY; optional otherwise.
• set_at — UTC timestamp, captured by the engine.
• criterion_or_gate — which gate / criterion the override applies to.

In the memo

Every override surfaces in the executive summary of the deal memo, not in an appendix. The pattern: "Phase N's gate verdict was X on criterion Y; the analyst overrode with reason Z; the override has not been retired as of memo render time." The reader sees both the gate signal and the override decision before reading the analytical body.

On the deal page

The deal page renders an override banner alongside the run progress. Clicking expands to the full override record. Analysts can retire an override (mark it resolved with explanation) which the audit log records; retiring an override does not remove it from history.

In the aggregate view

The repository page hosts an "Overrides" view that lists every override across every run: which criterion, which reason code, which analyst, which deal, what the downstream verdict was, whether the override held up. The IC reviews this view at the monthly cadence. Patterns that emerge — same criterion overridden 80% of the time, same analyst overrides 5× more than others, override-reason FOUNDER_RELATIONSHIP correlates with deal failure — drive either a methodology amendment or an analyst conversation. Override aggregation is how the methodology learns from its own escape hatches.

• Overrides do not carry across runs. Re-running the same deal six months later requires re-justifying any override. Old overrides do not silently extend.
• Overrides do not change the gate's record. The gate verdict is preserved verbatim. The override sits alongside it.
• Overrides do not auto-propagate to similar deals. An override is per-deal. The IC monthly review is the path for promoting an override pattern into a methodology amendment.
• Overrides do not bypass the hard disqualifiers. The seven disqualifiers require an explicit IC waiver in HubSpot before the run starts; analyst-level override cannot clear them.
• Overrides do not delete the failure-template content. The memo's "criterion X failed because" sentence still gets written. The override adds context; it does not redact.

Tools

Google + Bing search, Firecrawl (renders JavaScript-heavy pages), Playwright (full browser automation when scraping needs to act like a human), agent-browser (the engine can navigate any site interactively), Wayback Machine (historical snapshots).

13 free public APIs the engine consults by default

• GDELT — global news event database, real-time sentiment per region
• Wayback Machine — historical snapshots of any URL. Verifies operating age, catches deleted claims, audits website-style changes that often precede a sale.
• Reddit — full search across all subreddits with reviewer-history visibility
• HackerNews — surfaces founder coverage, product launches, technical-community sentiment
• Stack Overflow — useful for software-adjacent ecommerce targets and supplier API issues
• OpenAlex — academic paper index, used for category research and supplier provenance
• arXiv + bioRxiv — preprints, mostly for supplements / biotech-adjacent verticals
• SEC EDGAR — public-company filings. Used when the target has a public-company customer or supplier or any predecessor public entity.
• USPTO — US trademark verification (already used in Phase 4 Layer 9)
• EPO — European Patent Office (already used in Phase 4 Layer 9)
• Court Listener — US federal + state litigation database. Founder background, predecessor-entity disputes, IP suits.
• Crunchbase-free — basic funding history and key-people data

Why this matters for DD: most "founder background" surface area lives across these APIs. Court Listener catches lawsuits the seller didn't disclose. Wayback catches website history mismatches. GDELT catches regional press mentions in languages we don't speak. None of these cost anything. None of them require manual checking.

What it is

Ecomma's own institutional memory. If a partner has discussed this seller in Slack three months ago, if a previous DD memo on a competitor lives in Drive, if a prior outreach attempt is sitting in Gmail, the engine should find it before drawing conclusions.

What it adds to a DD

• Catches when a seller has been pitched before under a different name (the engine searches all six surfaces for the founder's name + the entity name + the domain)
• Surfaces prior internal opinions on the category (someone walked from a similar deal six months ago — why?)
• Pulls relevant prior-deal pre-mortems so we can see if the same risk recurred

HubSpot recall already covers part of this for deal-level memory. The internal-knowledge surface goes wider: any document anyone at Ecomma has written about anything related to this deal.

The two we don't use yet but should

SimilarWeb gives us the target's actual web traffic — visits, sources, country mix, engagement, year-over-year trend. The seller can lie about traffic; SimilarWeb sees it independently. Plug into Phase 1 thesis-fit and Layer 6 (Channel).

Ahrefs gives us SEO health: organic keyword rankings, backlink profile, domain authority, content gaps versus competitors. Catches deals that look healthy on paid traffic but have zero organic moat — those die fast post-acquisition when ad costs rise. Plug into Layer 6 + Layer 7 (Competition).

The ones we already touch

HubSpot is in Phase 0 recall and Phase 8 writeback. Klaviyo is in Phase 2 commerce data. Supermetrics aggregates Meta/Google Ads/TikTok and would simplify Phase 2 marketing data pulls. Amplitude gives product-analytics depth if the target has it instrumented.

For deals where the target has invested in a real data infrastructure, the engine can query the warehouse directly. Mostly applies to larger deals; smaller ecommerce brands rarely have one. When present, it gives ground-truth on cohort retention, LTV, returns, and channel attribution — the Phase 2 financial DD becomes much sharper.

What it does

The engine pulls transcripts of every YouTube video that mentions the target — founder podcasts, product reviews from creators, unboxing videos, complaint videos, category overviews. Then it searches the transcripts for sentiment, claims, contradictions with the seller's stated story.

What this catches

• Founders who said one thing on a podcast 18 months ago and a contradictory thing in the LOI today
• Reviewer accounts of product defects that never made it to written reviews
• Podcast appearances where the founder discussed competitors, supply problems, or planned exits
• Creator partnerships the seller didn't disclose as marketing dependencies

This is one of the highest-yield, lowest-cost surfaces in the stack. Almost nobody does it.

For technical due-diligence on rare deals where the target has custom-built software (a Shopify app, a fulfilment system, a custom storefront). Reads the codebase to assess code quality, dependency risk, security posture, and transferability. Most ecommerce-brand acquisitions don't need this; when they do, it's load-bearing.

Gemini Deep Research, OpenAI Deep Research, Perplexity Sonar, and NotebookLM all run in parallel as sub-tools. Documented in the next card.

Google's flagship research-agent product. Reads dozens of sources for each query, builds a structured report, cites every claim. Strongest on category-level research, market-size questions, regulatory landscapes. We invoke it with the deal's category + geography + the specific question (e.g. "What is the trend in repeat-purchase rates for premium pet-care DTC brands in the EU 2024–2026?") and get back a sourced report.

OpenAI's research agent. Different training, different search bias, different conclusions on borderline questions. Particularly strong on financial-market context, M&A history, and corporate-actions data. Same question goes to all three engines simultaneously.

Perplexity's research API. Faster than the other two (seconds, not minutes), real-time web indexing. Good for "what's been said about this entity in the last 24 hours" sweeps and live-news layered queries. Often catches things the slower agents miss because the index is fresher.

NotebookLM is different from the other three — it researches against a specific corpus you give it, not the open web. We use it when we want to ask "what does this corpus of seller-provided documents actually say?" to cross-check seller-narrated claims against the seller's own documents. Useful in Phase 2 financial DD and Phase 9 seller-response.

What it does

The three engines return three reports. Reconciliation walks claim by claim and tags each one:

• Triangulated — all three engines agree. Highest confidence.
• Two-engine consensus — two agree, third either silent or different. Medium confidence; the third's position recorded as the contrarian view.
• Diverged — all three disagree. Flagged for analyst review. Often the most interesting signal in a DD.
• Single source — only one engine surfaced this. Recorded but tagged as low-corroboration.

The result is a single claims ledger with explicit corroboration metadata, ready to feed into the memo.

Every claim must cite a source — a URL, a Drive document path, a HubSpot record ID, a Stripe transaction ID. Not "industry sources" or "general knowledge." A specific, addressable, verifiable origin. The render pipeline refuses to ship a claim without a source.

A 2019 article about the category is not the same as a 2025 one. Every claim records the source date so the reader can weight it. Stale claims get explicit "as of YYYY-MM" notation in the memo. Critical for fast-moving categories where a year-old benchmark is already wrong.

Statista is not a peer-reviewed paper. A Reddit thread is not a Bain report. Every source gets a tagged authority level: regulator (SEC, USPTO, FDA), peer-reviewed (academic), institutional (Bain, McKinsey, BCG, named-firm reports), journalist (named publications with editorial standards), analyst (Statista, eMarketer, named research firms), community (Reddit, HackerNews, forums), seller-provided (any document the target gave us), self-published (blog posts, opinion pieces).

Authority shapes how much weight the claim gets in the verdict assembly.

A composite score from 0 to 100 based on: authority of the source, how recent it is, whether other sources corroborate, whether the engine could grep-verify the quoted material, and whether the claim survived the contrarian pass. Claims under 60% confidence go in claims-low-confidence.md, kept for the analyst's review but not used in the memo's headline conclusions.

If the memo says 'According to Bain (2025), repeat-purchase rates in premium pet care average 38% in year-two', the engine fetches the Bain source and greps for the literal "38%" figure. Any quoted statistic, percentage, or named fact has to literally exist in the cited source. Catches the entire class of LLM hallucinations where a model confabulates a number that sounds right.

What it attacks

The Contrarian agent attacks the claims. For every supportive piece of evidence in the draft memo, it goes hunting for the opposite. If the memo says "the category is growing 18% YoY," Contrarian asks "is there evidence it's growing 8% YoY or shrinking? what does the bear case look like?" and surfaces it.

What it produces

contrarians.md — a per-claim register of counter-evidence. Each entry has source, date, authority, confidence (the same four-dimension ledger). The synthesizer is required to address every contrarian when drafting the next memo version.

What it attacks

Red Team attacks how we did the research itself. Not whether the conclusions are right — whether the way we got there was sound. "Did the comp set actually represent the target? Was the Quad Review question framed in a leading way? Were the discovery specialists given enough breadth? Did we let the seller's framing dictate which questions we asked?"

Why both, not just one

The Contrarian could miss something the methodology never had a chance to surface. The Red Team finds those failure modes — gaps in the research design itself. Run by the existing tribunal-runner in research-claim style.

What it produces

red-team-verdict.md — methodology critique. Sometimes the verdict is "the research was fine, just incomplete on dimension X." Sometimes it's "the research was structurally biased; rerun with these constraints." Either way, the memo can't ship until red-team is satisfied.

Schema version

Folder Schema v1.0 under methodology v3.0.0. Full enum + required-field contract is documented in Phase 0's Folder Schema detail row. Changes here cascade — the schema documented in this section and the schema enforced by Phase 0 are the same artifact.

Why a fixed structure

Every deal at Ecomma uses the same subfolders. An analyst who has never touched the deal can land in the folder and immediately know where the P&L is, where the supplier list is, where the memo is. Without this, every dataroom would be organised differently and the institutional memory would be useless.

The subfolders

00 vs 10

The 00_intake folder is sacrosanct — original files arrive here and never get moved. Classified copies go to 02–07; ambiguous files get quarantined in 00_intake/_unclassified/ for manual classification rather than dumped into a catch-all bucket. If a classification turns out wrong six months later, the original is still there to re-process. The 10_dd-output folder is purely engine-produced; nothing manual goes in there.

The pattern

Examples

• 2026-05-10_carrora-watches_dd-memo_v3.0.0.docx
• 2026-05-10_carrora-watches_three-statement-model_v3.0.0.xlsx
• 2026-05-10_carrora-watches_lbo-model_v3.0.0.xlsx
• 2026-05-10_carrora-watches_byo-pre-mortem_v3.0.0.docx

Why every part matters

• Date first — sorts chronologically in any folder view.
• Target slug — fast filtering for one deal across mixed folders.
• Artefact kind — finds every memo across all deals with one search.
• Methodology version — when we re-run a deal under v3.1, the v3.0.0 file is still there for comparison. Nothing gets overwritten.

This convention isn't optional. The render pipeline refuses to write a file that doesn't conform.

What "house-style" means

Every artefact the engine produces — memos, models, decks, sidecars — is rendered through an Ecomma-branded template. Same fonts (Inter for body, Playfair Display for headings), same color palette (navy + cyan), same logo placement, same footer (Ecomma · Internal · DD platform · methodology version). The IC opens any document and recognises it instantly as one of ours.

Where the templates live

In project-starter under plugins/finance/ecomma-dd/templates/. One template per artefact kind: memo-template.docx, three-statement-model-template.xlsx, lbo-model-template.xlsx, comps-deck-template.docx, etc. The template is the brand.

The branding script

A small Node script called gen-house-style.js applies the house-style brand to any document the engine produces. It sets fonts, colors, header and footer, logo. The skills produce the content; the branding script makes it look like Ecomma. Both run before the file is filed in 10_dd-output/.

How files get labelled

Every file that lands in 00_intake/ goes through a two-step classifier. First a fast filename + content-shape heuristic (a file called P&L_2025.xlsx with revenue/cost/profit headers is almost certainly a P&L). Second, for ambiguous files, a short Claude call that reads the first page and assigns a category. The result is a label like financials.pnl or operations.supplier-list or legal.trademark-cert.

Then it moves the file

A copy of each file gets placed in the matching subfolder, renamed under the standard convention. The original stays in 00_intake/ untouched. Every move is logged so the analyst can see exactly what the classifier did.

What if it's wrong

Misclassifications get corrected on the deal page with one click. The file moves to the new folder and any downstream references update.

What it does

Every artefact a phase produces (memo, model, deck, sidecar) is handed to the outbound filer. The filer applies the naming convention, applies the house-style branding through gen-house-style.js, writes the file to 10_dd-output/ in the deal's folder, and inserts a row in the artefacts table so the deal page can surface it.

What it refuses to do

Write a file with a non-conforming name. Write a file without house-style branding applied. Write a file without recording it in the artefacts table. Any of these would break the audit trail; the filer enforces them at the boundary.

The Drive API is what physically writes the files. Every move, every rename, every new file is a Drive API call. The engine has write permission scoped to the deal's folder only — it cannot touch anything outside that folder. Every write is logged so we can audit exactly what changed.