Two tenants. One database.
Zero leakage.

01Two tenants, structurally identical, cryptographically distinct

Both tenants registered the same policy_id = pol_v101_exporter_v1 independently (each with its own signed policy_register event). Both issued an export_content_bundle grant against that policy to their own customer principal. The grants are structurally identical but cryptographically distinct — different authority_id, different granted_by, different granted_to, different 148-hex signature.

Tenant B's creator_uuid was derived from the locked NS_H33_CREATORS_V1 namespace: uuid5(NS_H33_CREATORS_V1, "99001") = 7905888e-…. Same derivation Tenant A used; deterministic and reproducible.

02Three layers tested

verdict       = ProvenanceBroken
active_grants = 0

03Why this is different

Most "multi-tenant" systems rely on a WHERE clause and trust the developer to write it correctly every time. H33's isolation is structural: the replay engine doesn't have a global view; it has the events it's given plus a claimed root, and it refuses to derive authority that can't trace to that root. The injection test isn't theatrical — it's the actual attack a misconfigured query would produce. The engine catches it at the provenance layer, not at the database layer, because the database layer is allowed to be wrong.

This is what "No Derived Authority Without Provenance" buys: the failure mode is verdict ProvenanceBroken, observable, auditable, and zero authority — never "almost the right thing" or "a partial leak."

04Isolation matrix

Full machine-readable artifact: isolation-matrix.json.

05Independent reconstruction

A third party with read access to canonical_auth_events for both tenants, plus the test harness, reproduces this proof:

H33_TEST_PG_URL='postgres://…?sslmode=require' \
  cargo test --test multi_tenant_isolation_001 -- --ignored --nocapture

Expected outputs (byte-identical):

state_id_A = 24a06e845ce573dd773298451ad9a05da213cea52068e8b93e054ae9166f9db9
state_id_B = c11b3ca74742c191bf1f2846970f91a104b78a2e375bcceef23c48f116e20f15
injection verdict = ProvenanceBroken, active_grants = 0

06Known limitations

1. Tenant B is structural, not a real customer. A's identity chain reaches all the way to Auth1 (real EdDSA Bearer, real OTP login, real audit trail). B's identity chain stops at the canonical event log. Sufficient to prove isolation, not sufficient to be a "second customer." When the first second-customer proof lands, B gets replaced.
2. Two tenants, not many. Scale-of-isolation (10, 100, 10,000 tenants) is not yet measured. Belongs in Proof #5 (Scale).
3. Single point-in-time check. Isolation verified at one moment with one event set per tenant. Continuous isolation under churn (grants and revokes interleaved across tenants) is not yet tested.
4. Bundle issuance for Tenant B not exercised. Tenant B's grant resolved correctly in replay; whether the V101 bundle-issue endpoint produces an anchored receipt for B is not part of this proof.
5. Same signing keys for both tenants. The isolation proven is at the application layer. Cryptographic isolation (different keys per tenant) is a different proof not yet undertaken.

07Evidence appendix

08Deployment commit SHAs

09Readiness determination

What this unlocks: customer conversations about "what happens if you onboard a second customer; what happens if you serve a competitor; what happens if you make a typo in a WHERE clause." The answer is the isolation matrix.

What this does not unlock: scale-of-isolation (#5), continuous-churn isolation, cryptographic isolation (different signing keys per tenant), or commercial-second-customer claims. Each earns its own published proof.