First Inherited Risk Replay.
PE, acquirers, insurers don't buy acquisitions. They buy reductions in unknown inherited risk.

01The killer query — show_inherited_risk(acquisition_001)

inherited from:      tenant_acquired_44962d9b-25f5-5622-bd9a-98d5580bb8a2
inheritance policy:  full

counts_by_type:
  loss:                  2
  lawsuit:               1
  regulatory_action:     1
  operational_failure:   1

counts_by_severity:
  financial:             2
  legal:                 1
  regulatory:            1
  operational:           1

aggregate exposure:    $18,400,000

Every inherited consequence below carries origin_enterprise_id = tenant_acquired_…. A diligence reader can tell, line by line, whether each consequence originated before or after the acquisition.

02The risk ledger — five open consequences crossing the boundary

03The money slide

04The endpoint progression

05Why the architecture is right

Cross-tenant replay does not require the engine to pull events across tenants. Each tenant replays independently, byte-identically, to its own snapshot. The inheritance view is composed above the engine, from two consistent snapshots plus the AcquisitionRecord.

That is the discipline. The engine never crosses tenant boundaries. The composition layer does — explicitly, traceably, and only when the AcquisitionRecord says it should.

06The schema additions

// Consequence gains a single field — but it answers a billion-dollar diligence question.
Consequence {
    at_ms, consequence_id, consequence_type, consequence_severity,
    triggering_decision_ids, affected_asset, amount, description,
    origin_enterprise_id: Option<String>,   // ← NEW — None for native; Some(tenant_id) when inherited.
    recognized_by, signature,
}

// New event kind — the inheritance anchor.
EnterpriseAcquisition {
    at_ms, acquisition_id,
    acquirer_tenant_id, acquired_tenant_id,
    acquirer_root_principal, acquired_root_principal,
    inheritance_policy,                     // "full" | "selective" | "novation"
    recognized_by, signature,
}

Snapshot extensions: ConsequenceSnapshot.origin_enterprise_id, AcquisitionRecord, and AuthorityStateSnapshot.acquisitions — all skip-if-empty. All 16 prior proofs' state_ids verified byte-identical under the extended engine.

07What this proof IS and IS NOT

08Known limitations

1. Consequence amounts are opaque strings (e.g. "3200000.00 USD"). The aggregation helper parses; the engine does not arithmetic. Typed money is a future iteration shared with #15.
2. Only inheritance_policy = "full" exercised in this scenario. "selective" and "novation" are in the type but not yet covered by a separate proof.
3. One acquirer × one acquired. Multi-step chains (B acquires C, then A acquires B) are queued; the architecture supports them via repeated AcquisitionRecord composition.
4. Roll-forward consequences after T_ACQ remain on the acquired tenant's log in this proof. A "post-close consolidated view" is a roadmap composition.
5. Phase E lock open as in every prior proof; L9.1 closes it.

09Where this proof sits

10Evidence appendix

11Readiness determination

What this unlocks: every diligence buyer (PE, R&W insurer, acquirer, fund administrator, board, regulator) can now ask the deepest question they ask the day after close — what did we just inherit? — and receive a deterministic, signed, byte-identically replayable answer. The category claim Eric named as the corpus endpoint at this depth: Institutional Continuity Infrastructure.

What this does not unlock: a reserving engine for inherited risk; a public registry of all corporate acquisitions; a legal verdict on inherited liability allocation; an opinion on whether a given acquisition was wise.