Know the blast radius before you deploy. Architecture Rehearsal builds a causal dependency graph, runs failure scenarios, and blocks unsafe changes before they reach production.
Topology, ownership, and the proposed change become a predicted impact surface.
02
Rehearse failures
Deterministic scenarios inject failure modes against the graph before traffic does.
03
Gate the change
Policy returns approve, warn, or block. Graph and rules decide; optional AI only explains.
04
Verify with evidence
Post-change verification closes the loop; every gate cites content-addressed digests on CRs.
02
Evidence
From problem to proof.
How the system is framed, operated, and proven — not a slide deck summary.
01
Problem
Blast radius often shows up only after promote — reviews named opinions; production exercised the real graph.
02
Architecture
Causal dependency graph + deterministic failure scenarios + approve/warn/block policy, recorded as Kubernetes CRs with content digests, then post-change verify.
03
Operating model
One shared language for blast radius: affected services, firing policies, required evidence before promote, verification after sync.
04
Trade-offs
You must model ownership and failure modes early. Incomplete models are expected — post-verify exists so the graph can be calibrated.
05
Evidence
Graph revision, gate decision, scenario pack digests, rehearsal logs, and post-deploy match / partial / miss.
06
Latest evidence
rehearsal argo-impact is a native Argo CD change-impact gate (since v1.6.0; v1.7.0 adds an Argo CD PreSync hook that blocks risky syncs): it explains the consequences of a desired sync — scheduling capacity, PVC zone conflicts, NetworkPolicy cuts, PDB violations, blast radius — without re-implementing Argo diff. Each detector returns PASS / WARN / BLOCK / UNKNOWN and missing data is UNKNOWN, never a silent PASS (fail-closed). Policy defaults also fail closed (PR #45): omitted unknownAsBlock defaults to true so UNKNOWN blocks. In the argo-kind-e2e job of CI run 38133353467: native benign Application → PASS, netpol-cut / unschedulable / pdb-violation → BLOCK, missing PDB inventory → UNKNOWN (exit 4). Argo CD PreSync hook (rehearsal argo-presync, PR #46) runs the same gate in-cluster on every sync — including manual/UI — so CI bypass cannot skip it; BLOCK/UNKNOWN and gate errors fail closed. On fixtures (kind job argo-presync-kind-e2e in CI run 38173365460 + offline matrix; docs/EVIDENCE.md): risky blocked 5/5, safe false-blocked 0/3; in-cluster hook adds ~0.9–1.0 s per sync. Small fixture set — regression check, not field accuracy.
Causal dependency graphs, policy gates, evidence chains, Kubernetes CRDs, and deterministic rehearsal before deploy.
03
Deep dive
What production teaches — before it teaches you.
Architecture Rehearsal is not a prettier design review. It is a pre-deploy control plane that turns blast-radius talk into a runnable experiment with a gate decision and an evidence chain.
Plain answer
Architecture Rehearsal models the causal dependency graph of a proposed change, runs deterministic failure scenarios against that graph, returns approve / warn / block from policy, and verifies after deploy whether the prediction matched reality. Evidence is content-addressed and stored as Kubernetes CRs — so the decision is auditable.
Most platforms discover architectural blast radius the expensive way: a merge lands, a sync completes, and three services nobody named in the review start failing. The review had opinions. Production had the graph.
The constraint is blunt: if you cannot rehearse the change against a model of ownership and failure, you are guessing — and guesses do not belong in the promote path.
Control loop
01
Collect
Topology, ownership, SLOs, and the proposed change enter as structured inputs — not a slide with arrows.
02
Model
A causal architecture graph projects which services, policies, and recovery paths sit in the blast radius.
03
Rehearse
Deterministic scenarios inject failure modes against the graph so operators see what breaks before traffic does.
04
Gate
Policy returns approve, warn, or block — linked to the graph revision and scenario pack that produced it.
05
Verify
Post-change verification records match / partial / miss so the model can be calibrated, not silently trusted.
Why cluster state — not a prettier log
01 · Operator surface
RehearsalRun as cluster state
The operator surface is a RehearsalRun-style Kubernetes CR: desired change, graph digest, scenario pack, gate outcome, and evidence pointers live as cluster state. Helm packages the CRDs so the control plane installs like any other platform product.
That choice matters. If rehearsal results only exist in a CI log scrollback, they are not operable. If they exist as objects with digests, you can diff, audit, and calibrate the model over time.
02 · Evidence
Content-addressed receipts
Content-addressed evidence is the unglamorous part that makes the rest trustworthy. A gate that cannot cite which graph revision and which scenario pack produced it is just another opinion with better typography.
03 · Operator E2E
Kind proves the control plane
Kind-based operator E2E exists for a reason: the control plane has to survive install, CR lifecycle, and verification hooks without a human babysitting YAML. If rehearsal only works on the author’s laptop, it is a demo, not a platform capability.
What the gate actually decides
Approve
Promote is coherent with the model
Predicted blast radius is inside policy bounds; required evidence artifacts are present; no hard scenario failed.
Warn
Proceed with eyes open
Something is off-model or soft-failed: ownership gaps, partial coverage, or a scenario that needs a human call.
Block
Change is not ready
A hard policy or failed rehearsal scenario says the change is not ready. Fix the graph, the change, or the recovery path — then rerun.
Failure modes this is built to catch
Failure mode
Hidden fan-out
A shared library or platform service sits under many owners; the review named one consumer, the graph names twelve.
Detected bygraph traversal
Failure mode
Policy fiction
The change assumes a gate that does not exist yet, or a warn that production treats as allow.
Detected bypolicy evaluation
Failure mode
Recovery theater
Rollback is documented, but the rehearsal shows the restore path depends on a service inside the blast radius.
Detected byscenario + policy
Failure mode
Stale topology
The model is wrong. Verification after deploy is what keeps that honest — and forces recalibration instead of silent confidence.
Detected bypost-verify
Signals that matter in operation
Gate mix
A / W / B
Approve vs warn vs block over time — warns climbing usually means model debt, not luck.
Prediction match
post-verify
Share of runs where post-change verification agreed with the rehearsal prediction.
Evidence freshness
digest age
Gate decisions should cite current graph and scenario digests, not last quarter’s export.
Time-to-rerun
minutes
If fixing a block takes days to re-model, the control plane is not actually in the path.
How to carry this
Trade-off
Model debt is real
Rehearsal demands ownership and failure modes up front. Incomplete models are expected — that is why verify exists. The alternative is discovering the real graph in an incident channel.
Use when
Cross-boundary changes
Shared platform planes, restore assumptions, multi-service blast radius. A typo in one isolated service does not need a causal graph.
Adoption
Start narrow
Pick one change class — ingress, shared library, identity, or restore — wire rehearsal into that promote lane first, then widen. Boiling the ocean on day one produces a neglected graph.
04
Related
Nearby systems.
Case 25 · Flagship
TwinOps Control Plane
OpenUSD
Go
Kubernetes
Industrial digital twins are often demos, not operable infrastructure with drift, reconciliation, and incident replay
A design review produces opinions. Architecture Rehearsal produces a gate decision linked to a causal graph, scenario pack, and content-addressed evidence — then verifies after deploy whether the prediction matched.
Why not just CI, OPA, Chaos Mesh, or a service catalog?
CI knows if tests passed. OPA knows if config is allowed. Chaos knows what breaks when running. Catalogs know dependencies. Architecture Rehearsal asks whether this specific change should be promoted given predicted blast radius and failure scenarios — and records the receipt. It connects those signals; it does not replace them.
Does AI approve or block changes?
No. Optional AI may explain a decision. Graph topology and policy rules approve, warn, or block. Narrative stays out of the risk path.
What if the model is wrong?
Incomplete models are expected. Post-change verification records match / mismatch so the graph can be calibrated instead of silently trusted.
When should I use it?
When a change crosses service boundaries, shared platform planes, or restore assumptions. Isolated single-service typos do not need a causal graph.
Available for meaningful infrastructure conversations
