A Context Pack release changes which evidence, tools, policies and constraints reach a workflow. Moving traffic to a new version is therefore a governed operation, with an accountable owner and a tested recovery path.
The five stage names from Harness Engineering remain useful:
| Stage | Work exposed | Evidence to advance |
|---|---|---|
0%_shadow | Eligible candidate evaluation alongside baseline | Complete paired results; candidate cannot perform production effects |
1%_internal | Explicit internal cohort | Required controls and useful outcomes pass in that cohort |
5%_low_risk | Bounded authorized task slice | Stable utility, correction and escalation behavior; all mandatory controls pass |
25%_monitored | Broader bounded cohort | Tail and critical slices have complete independent evidence |
100% | Approved release becomes default within its scope | Required observation period and release/recovery evidence are complete |
Percentages and observation windows are policy choices. A stage label does not prove the actual allocation, and no number of elapsed days waives a failed requirement. An internal cohort also needs an explicit proportion: sending every internal user to a candidate is not automatically a one-percent deployment.
October 16 correction: the earlier router, shadow runner, SQL promotion gate and shell scripts were incomplete tutorial sketches. They used incompatible RunContext fields, relied on a dry-run flag without an enforcement boundary, allowed automatic advancement from incomplete evidence and conflated release rollback with reversal and byte-identical model replay. They are withdrawn. This article specifies implementation obligations; it does not ship a production router, flag service, gate or cron job.
Pin the release and the rollout decision
A release tuple names immutable pack, policy, tool registry, model/runtime, evaluator, data and exact control/profile definitions. Record full artifact digests, rather than resolving mutable version aliases again during a run.
The rollout record additionally needs:
| Record | Purpose |
|---|---|
| Candidate and baseline digests | Identify exactly what is compared and deployed |
| Workflow, environment and tenant scope | Bound where the decision applies |
| Cohort policy and input snapshot | Explain who was eligible and the actual allocation |
| Stage revision and expected prior revision | Prevent competing transitions from overwriting one another |
| Required cases, floors and observation period | Declare acceptance before seeing outcomes |
| Trusted report/verdict references | Bind independent evidence to that exact release |
| Current entitled approvers and expiry | Establish permission for this exact rollout action |
| Recovery tuple and control owner | Define how future dispatch can be restricted or redirected |
A signed artifact is one integrity mechanism. A signature alone cannot establish current approver entitlement, report completeness, active containment or atomic promotion. A reviewed feature-flag service can distribute decisions if it preserves these bindings and history; storing JSON in Git is not the only acceptable design.
Make routing reproducible without making it authority
For a canonical base run, user identity is ctx.user.user_id, while tenant_id, run_id and intent are separate run fields. Internal membership and domain task classes are independently verified application facts, not invented top-level RunContext fields.
A cohort allocator needs a documented stable algorithm over unambiguous encoded inputs. Pin its version, salt/key policy where used, eligible population and candidate revision. Prevent delimiter collisions and untrusted identity selection. Record the actual routing inputs and result with the run; a later Git file alone does not prove what a worker loaded.
Cohort eligibility proposes a release choice. Current owned tenant/audience/purpose and all ancestor restrictions/revocation still constrain the run. Native risk, guardrails, exact stored full-action approval/quorum, active containment/credential/data controls and external preconditions remain independent. Applicable policy-expression errors stop compilation with structured diagnostics.
Missing or unsupported mandatory controls block the candidate. Falling back to the baseline is valid only when that route independently satisfies current requirements; a known old release is not permanently authorized.
Shadow work needs a real boundary
A block_destructive option cannot establish that a candidate is unable to send, publish, spend, mutate memory or disclose data. Use actual isolated fixtures, denied production credentials/destinations or equivalent enforced capabilities. Verify every hosted tool, shell, browser, peer and subprocess path. Read-only retrieval can still disclose a private query.
Bind candidate inputs to an eligible baseline snapshot while keeping evaluation authority separate. Collect useful success, required denial and fault cases; compare paired tasks without treating unavailable observations as success. If real workflow data is used, govern its actual recipients and processors before collection or inference.
Root, shadow, child, reviewer, retry and repair work consume original shared immutable capacity. Reserve before starting each branch, settle trusted cumulative usage and retain uncertain reservations. Candidate cost cannot disappear because its output was not shown to the user.
Complete evidence precedes advancement
The former SQL returned advance for 1,000 matching rows with every score field null. A local SQLite probe of the query, removing only PostgreSQL numeric casts, reproduced that result. Counts and averages alone cannot establish evidence completeness.
A production release evaluator needs all of these checks:
validate bounded inputs, required fields and finite metrics at trusted ingress
bind exact candidate/baseline, workflow, environment, data and evaluator revisions
verify current independent observer/report provenance and exact artifact digests
require the declared useful, denial and fault case inventory without silent omissions
reject conflicting, duplicate or out-of-scope results
hold missing, stale, synthetic or unverified runtime evidence
apply independent mandatory floors and prespecified uncertainty/slice requirements
produce a verdict bound to the exact rollout proposal and expected prior revisionThis is a non-executable checklist. The conformance reference supplies a deterministic scoped evidence boundary, not a deployed scoring or promotion service. Select exact control profiles; a high average cannot compensate for a required permission, isolation or fault-control failure.
Freeze the candidate before sealed final evaluation and bound repeated submissions and feedback. If a pack, policy or evaluator changes during rollout, treat the new tuple as a new candidate. A security finding can require blocking the affected path even before an aggregate score crosses a threshold.
Promotion is a separately authorized operation
An evaluator verdict is evidence, not permission to edit routing. A current entitled release authority approves the full exact action, scope, evidence and immutable pins under required separation/quorum rules. The protected store applies the stage change atomically only if its expected revision still matches.
Use structured, parameterized storage operations. Do not interpolate operator-provided text into SQL, parse a multi-column query by its last whitespace token, or let a shell script automatically commit a stage change because a string says advance. Authenticate and bind every dependency, including any deployment system applying the change.
A scheduled controller has a current owner and finite revocable mandate. Its wake checks current authority, exact approval, active controls, provider preconditions and remaining original capacity. Protected atomic run/operation/approval/budget state and enforced generation fencing prevent stale controllers from applying changes.
Stop dispatch and reconcile in-flight work
An operator response has several separate responsibilities:
| Responsibility | Observable result |
|---|---|
| Restrict new dispatch | Affected runs and delegated workers cannot start new prohibited effects |
| Fence stale ownership | Old generations cannot mutate protected state or dispatch through fenced targets |
| Request interruption | Active work receives cancellation where supported |
| Observe stop | Worker and child state establishes what actually stopped |
| Reconcile effects | Provider evidence distinguishes confirmed, not applied, partial and unknown outcomes |
| Select a recovery route | A currently permitted prior tuple or reduced/manual path handles future work |
A cancellation request is not verified stop. A provider may finish a write after the process stops. Unknown outcomes retain stable operation identity and reservations until reconciled under the actual provider contract. An idempotency key alone does not authorize retry. Compensation is a new governed effect.
Selecting a prior tuple changes future work; it does not undo refunds, delivered messages or disclosure. Replaying retained transcripts can reconstruct evidence without guaranteeing identical future model bytes. Respect current access and retention rather than resurrecting deleted data to reproduce a historical run.
Govern rollout evidence as data
Collection, inference, tool input/output, telemetry, cache, memory, export and delegation all need actual purpose/readers/recipients/processors/residency and retention checks. Inventory candidate artifacts, scorecards, traces and derived copies. Correction/deletion needs receipts bound to record, operation and artifact digest; pending, failed or externally unknown propagation remains incomplete.
Historical integrity means preserving eligible evidence faithfully during authorized retention. It does not justify an unlimited raw production transcript store.
A worked rollout decision
For an illustrative ctxpack.support@5.1.0 to 5.2.0 candidate:
- Pin complete tuples and exact profiles, declare scope, cohorts, required cases and acceptance criteria.
- Validate the actual shadow boundary and reserve shared capacity before evaluation.
- Collect complete independently verified paired useful, denial and fault evidence.
- Freeze the candidate, run sealed release checks and obtain exact current rollout approval.
- Apply one atomic stage transition; observe the actual cohort and required slices.
- Treat fixes as new immutable candidates. Block or restrict a mandatory-control failure immediately.
- Expand only when the scoped current evidence and authority permit it; retain an eligible recovery tuple and honest in-flight state.
No production runs, promotion service or automatic recovery drill is claimed by this example. The execution guide identifies the stores, adapters and observations an implementation must supply.