Governance is structural, not a checklist.

No image serves without passing supply-chain admission inside the deploy saga: a Cosign signature, an SBOM, and a vulnerability scan. An unadmitted image halts the saga 403 with the build marked refused — and the refusal is recorded as evidence, not silently dropped. The quality-gate floor (signed-image requirement, critical/high vuln ceilings, test-pass floor) is evaluated on every run.

• Signature + SBOM + scan required at the admit step
• A failing image halts the saga with a reason
• Refusals are first-class audit evidence
• Gate defaults are strict: 100% test pass, 0 critical vulns, signed image

tenant_id is a first-class, verified request concern resolved once at the edge. A verified SS-01 token carries the tenant; an in-mesh X-Tenant-Id header is trusted only over mTLS, and when both are present they must agree — a mismatch is a confused-deputy attempt, rejected 403. All persistence is tenant-scoped, so an id is unique only within a tenant and cross-tenant reads are structurally impossible, not merely filtered.

• Verified token (strong path) or mTLS mesh header — never a forgeable client header
• Token/header disagreement → 403 (confused-deputy closed)
• Storage scoped per tenant: cross-tenant read returns zero rows
• Automated cross-tenant pen test runs in CI

Every audited action appends to a hash chain: each entry carries the previous entry's hash, so altering or dropping any earlier entry breaks the chain from that point on and is detectable by re-walking it. In production the digest is a Vault-Transit signature, so the chain is cryptographically attributable to the platform's signing key — held in SS-05, never in the service. Entries are tenant-scoped and retained for seven years.

• Append-only hash chain; tampering breaks the links
• Vault-Transit signed — signing key never leaves SS-05
• Every deploy, rollback, promotion, cron and scale change is recorded
• 7-year retention; compliance evidence is a byproduct of shipping

Run the build plane on hardware you control: register self-hosted linux runners and drain them on your terms, with an in-cluster fallback so a build never fails for lack of a runner. When you need to leave, GET /apps/{app}/export emits the app's complete portable desired state — definition, revisions, rollout, addon refs, crons, scale and pipeline — to re-target a BYOC or partner cluster. Never credentials, never operational history you can't take with you.

• Self-hosted linux runners; hermetic policy follows the workload
• In-cluster build fallback — no Linux fail-safe gap
• Portable desired-state export (secret refs only, never material)
• Dedicated / sovereign regions on Enterprise