Venture Separation Architecture

1. Owned problem

When several ventures share a platform, architecture debates often collapse into two bad slogans: “share everything” or “separate everything.” Both shortcuts can hide coupling, failure-domain, data-sensitivity, lifecycle, and cost consequences. ARC-001 owns Venture Separation Architecture only; PLN-028 repair/canary work and ARC-002 Versioned Shared Interfaces remain separate outcomes.

2. Deliverable

Build Venture Boundary & Separation Decision Record v1. For every capability, record Venture Scope, Tenancy Model, Isolation, Change Cadence, Data Sensitivity, Failure Domain, Owner, Shared/Marginal/Migration Cost, Coupling, Serviceability, Decision, Stop/Pivot Trigger, and Evidence.

3. Mental model: capability before venture-wide architecture

Decide capability by capability: evidence → hard isolation gates → lifecycle/failure-domain gates → cost & coupling → proposed-model comparison → bounded state. Identity may stay shared, customer records may use a bridge, and an audit store may be fully siloed. A defensible architecture does not need one model for every component.

4. What external guidance says—and does not say

Azure describes isolation as a spectrum and explains that the chosen level affects security, cost, performance, reliability, and responsiveness to tenant-specific needs. AWS describes silo, pool, and bridge as dedicated, shared, and mixed models. Neither source decides your venture boundary; that requires local evidence and governance.

5. Evaluate hard gates before cost

Do not trade away data sensitivity or failure-domain requirements for a cheaper number. If a capability requires DEDICATED isolation or handles RESTRICTED data, low volume is not enough to justify sharing. Conversely, separating a low-risk capability merely by preference can create avoidable fleet and operational cost.

6. Lifecycle cadence is a real boundary signal

Two ventures can start with the same feature set and later diverge in release cadence. If one ships daily and another monthly, a single shared deployment can create lifecycle coupling. A bridge can be appropriate: some layers remain shared while lifecycle-sensitive components separate. A cadence change reopens the record.

7. Read cost together with coupling and migration

Low shared cost does not prove “share,” and low dedicated cost does not prove “split.” Migration cost, coupling, and ongoing shared/marginal cost must be evaluated together. In this lab, a material shared-cost increase causes a pivot only after migration and coupling are recomputed.

8. Worked baseline: a mixed architecture

The baseline has three capabilities. identity-edge is low-sensitivity with a shared failure domain and remains SHARED. customer-records has high sensitivity plus logical/partitioned isolation and uses BRIDGE. regulated-audit has a dedicated requirement and restricted data, so it is SILO. The result is ACCEPTED_MIXED, not “all shared” and not “all silo.”

9. Mutation one: stronger isolation with unchanged traffic

If customer-records moves from HIGH/LOGICAL to RESTRICTED/DEDICATED while the team keeps BRIDGE, the decision becomes PIVOT_REQUIRED. Low or unchanged traffic does not neutralize the gate; the isolation requirement changed.

10. Mutation two: shared-platform cost doubles

If operating shared infrastructure for a low-coupling capability materially increases, the record must recompute cost, coupling, and migration. In the fixture, identity-edge is no longer defensible under its previous model and the recommendation changes to SILO. The old verdict is not copied.

11. Missing or conflicting evidence is not success

Removing evidence for a failure-domain claim yields UNKNOWN; old decisive evidence yields STALE; conflicting authority on the requirement yields DISPUTED. These typed states are not cosmetic warnings—they block a stronger architecture claim until evidence is repaired.

12. Stop/pivot triggers are part of the decision

Every accepted boundary needs a trigger: isolation requirement changes, shared cost materially shifts, cadence diverges, failure domain changes, or serviceability drops. A boundary without a trigger eventually becomes a hidden assumption.

13. Transfer: a fourth venture with strict isolation and low volume

The transfer adds Venture D with low volume but stricter isolation for Customer Records. Recompute from evidence: Identity can remain shared, while Customer Records moves from Bridge to Silo. Low volume does not erase the requirement. The overall architecture remains mixed, but its decision vector changes from baseline.

14. Lab execution

Go to lab/ARC-001-LAB1/learner/ and run python run_checks.py offline. Eight fixtures cover Baseline, Isolation Raise, Shared-Cost Double, Cadence Divergence, Missing Evidence, Stale Evidence, Authority Conflict, and the Fourth-Venture Transfer. The goal is not to preserve one verdict; explain the first controlling gate and the recomputation.

15. Assessment, freshness, and claim boundary

Assessment covers scope, the baseline record, negative evidence, and transfer. Azure/AWS bound only the external facts about isolation spectrum and silo/pool/bridge models. Cost thresholds, typed states, stop/pivot policy, and the evidence contract are MAKNOW design. No live split, billing change, or tenant migration occurs, and accepted canonical bytes require a new package version to change.