Release Rings: Target Architecture vs Runtime Activation

1. The problem: “released” is not one state

In a real delivery system, saying “the release is out” is underspecified. A new artifact can be deployed while its feature path is disabled, enabled only for one cohort, or running against a target architecture that has not yet converged. Collapsing all of those conditions into Released = Yes makes it impossible to explain what is actually running, where, for whom, and with what evidence.

This lesson uses the release ring as the unit of review, but it does not equate a ring with an environment. A ring can be a logical grouping of users, stamps, regions, tenants, or deployment targets. The goal is an observable model that keeps intended state separate from observed state and makes every transition reviewable.

2. Separate a release ring from an environment

An environment usually describes a boundary such as development, staging, or production. A ring describes rollout and exposure. Multiple rings can exist inside one production environment, and one logical ring can span multiple physical targets. An environment name alone therefore proves neither audience, blast radius, nor promotion order.

Release Ring Activation Matrix v1 records ring identity and environment mapping separately. This prevents a common shortcut: “it is in production, therefore everyone has it.” Production describes location; activation and cohort require their own evidence.

3. Target architecture is intended state

Target architecture answers: what architecture is this ring supposed to converge to? The intent may name a topology version, target revision, dependency shape, or deployment-stamp layout. It is a baseline, not a runtime observation.

Keep the intent traceable with a revision or hash. If the target changes while runtime has not converged, record drift or an open convergence window. Editing the target description must not make the old runtime look compliant by narrative alone.

4. Record artifact deployment independently

Artifact deployment proves that a particular build or version was placed on, or observed in, a target. It does not prove that a feature path inside that artifact is active. Version, digest, deployment stamp, and deployment evidence should be captured independently.

Compare the desired and observed artifact. If the architecture target requires version B while the ring is still running version A, that is artifact drift. Resolve the runtime or change the target through change control; do not erase the mismatch from the record.

5. Separate runtime activation from code presence

Feature flags and equivalent mechanisms can alter runtime behavior after code is already deployed. Artifact presence and feature activation are therefore separate states. This separation is a core evidence boundary in the lesson.

The synthetic model uses DISABLED, PARTIAL, and ENABLED. If the new artifact is deployed but the feature remains disabled, the matrix should say DEPLOYED_NOT_ACTIVATED, not “fully released.” When activation is partial, the cohort must be explicit.

6. Cohort and population are part of activation evidence

Activation is incomplete without an audience. Enabled for whom: internal users, one tenant, a region, a percentage of traffic, or everyone? Ring population and cohort assignment belong in observed state.

If desired activation is PARTIAL, the expected cohort must match the observed cohort. Exposure to a broader audience than intended can create cohort drift even when artifact and architecture are correct. This is where blast radius becomes observable.

7. Keep health gates and bake windows as evidence

Progressive exposure without health evidence is only progressive risk. For each ring, record which signals were checked, over what observation window, and whether the ring exit condition passed. Human approval can be part of governance, but it is not a runtime health signal.

This lesson does not invent universal thresholds. SLOs, error budgets, latency limits, business metrics, or synthetic probes must come from the real system policy. The matrix only requires health evidence and gate outcome to be independent fields.

8. Approval evidence is not health evidence

Approval states that a person or policy authorizes a transition. Health evidence states what the runtime is doing. Approval can be green while health is failing; in that case promotion must still stop, and a real rollback trigger may require rollback.

The inverse is also possible: health is good but a governed transition still requires explicit approval. That ring can be technically healthy but not yet promotion-eligible. Keeping the two evidence classes separate makes the hold reason precise.

9. Localize drift instead of calling the whole release “bad”

When intended and observed state disagree, identify the dimension that diverged: target topology, artifact version, runtime activation, cohort, or configuration. A generic “deployment failed” label usually obscures the correct repair path.

target drift means observed topology does not match intended topology. artifact drift means version or digest is wrong. activation drift means enablement differs from intent. cohort drift means the actual audience differs from the assignment. A ring can have more than one drift at once.

10. Failure probe: deployed but disabled

One lab case is intentionally misleading: the new artifact is successfully deployed and the deployment log is green, but the feature remains disabled for the intended cohort. Looking only at deployment status produces the wrong conclusion.

An evidence-first result keeps both facts: deployment succeeded and activation has not converged. The transition stays on HOLD until the activation mismatch is reconciled. The probe demonstrates that deployment and runtime activation are independent states.

11. Failure probe: approval green, health red

A second probe contains recorded approval while the health gate fails. Approval is not stronger evidence than runtime health. If a real rollback trigger is met, the transition becomes a rollback candidate; otherwise promotion at least remains held.

The matrix therefore keeps an evidence ordering: observed health and state reconciliation are technical conditions, while approval is a governance condition. Neither silently substitutes for the other.

12. Build Release Ring Activation Matrix v1 row by row

A minimum row contains Ring, Intended Target, Environment, Desired/Observed Artifact, Deployment Evidence, Desired/Observed Activation, Cohort, Health Gate, Approval, Drift, and Transition Decision. Attach evidence or an explicit UNKNOWN to each conclusion.

The artifact exists to explain what is actually running. A green summary is valid only when row-level evidence supports it. UNKNOWN_INSUFFICIENT_EVIDENCE is preferable to a guessed state.

13. Derive promote, hold, and rollback from evidence

Promotion is defensible when required state dimensions converge, health passes, and required governance is complete. Hold applies when a repairable mismatch or missing evidence remains. Rollback requires an actual policy or trigger; the lesson does not invent one.

Match reconciliation to the drift: deploy/reconcile the artifact for artifact drift, correct activation state for activation drift, reconcile topology or change-control the target for target drift, and correct assignment for cohort drift. “Redeploy everything” is not a universal repair.

14. Lab: rebuild the matrix from a local fixture

The lab is fully local and synthetic. Eight cases cover a healthy ring, deployed-but-disabled state, artifact drift, health failure with approval, target drift, cohort drift, insufficient evidence, and a transfer case with different names. No credentials, live endpoints, customer data, or production systems are used.

Run python run_checks.py to verify fixture structure. Then implement analyze_ring(case) in starter.py and return eight independent evidence dimensions for each case. The skill is evidence separation, not memorized prose.

15. Transfer: rebuild under different ring names and topology

The transfer case changes ring names, target architecture, and activation mechanism. Do not copy ring count, threshold, or baseline names. Reconstruct the method from raw evidence: intent, artifact, activation, cohort, health, approval, drift, and transition.

Transfer is demonstrated when the same state separation survives a changed context. Close the result only when direct evidence, inference, and unknowns remain distinguishable.