Skip to Content
Numinance
Concepts

Change lifecycle

The durable stages every change passes through - Understand, Plan, Act, Verify, Evidence - and the release, observe and recover stages that exist only when authorized.

View as .mdUpdated
Under development
The lifecycle is run by the proprietary runtime. The state names are public-spec in the shared types.

A change is a durable state machine with fresh authority at each gate, not one long agent session.

The core loop

Understand -> Plan -> Act -> Verify -> Evidence
StageWhat happensTypical states
UnderstandResolve context, classify the change.CHANGE_STATE_UNDERSTOOD, CHANGE_STATE_CLASSIFIED
PlanProduce a plan and pass the plan gate.CHANGE_STATE_PLANNED, CHANGE_STATE_PLAN_GATE
ActAgents implement work units under bounded grants.CHANGE_STATE_IMPLEMENTING, CHANGE_STATE_INTEGRATED
VerifyIndependent checks, bounded repair.CHANGE_STATE_VERIFYING, CHANGE_STATE_REPAIRING
EvidenceSeal the record of what happened.CHANGE_STATE_CLOSED

Change lifecycle

What does a durable change do from objective to evidence, and where does it pause?

Illustrative · simulated
Scenario
Speed
  1. Understand / Classify
  2. ◇ Plan gate
  3. Implement
  4. Verify
  5. ┄ Repair (bounded)
  6. Rehearse
  7. ◇ Release gate
  8. Merge
  9. Release
  10. Observe
  11. ┄ Recover
  12. Evidence seal

Step 1 of 10 · Understand / Classify

Context is resolved from authorised sources and the Change is classified.

Lifecycle state
Opened, Understood, Classified
Who acts
engine (read-only grant)
Temporal holds (references only)
change_id, state, context bundle artifact_ref + sha256
Customer artifact storage holds
Repository index, resolved context bundle, risk classification
Evidence record emitted
Context resolved: sources used and digests

Happy path, step 1 of 10: Understand / Classify. Context is resolved from authorised sources and the Change is classified.

▣ current✓ visited◇ gate┄ not on this pathnext action is yellow
Text description

A Change is a durable state machine, not one long agent session. The agent implements one work unit at a time; planning, gates, verification, release and recovery are performed by Numinance with fresh authority per stage. Orchestration payloads carry references and digests only; source, diffs, prompts, logs and findings bodies live in customer artifact storage.

Stages in order: Understand / Classify, Plan gate, Implement, Verify, Repair (bounded), Rehearse, Release gate, Merge, Release, Observe, Recover, Evidence seal. Verification failure re-enters implementation with the findings reference as the only new input, at most max_repair_attempts times (default 2 in the generated Playbook), then the Change is escalated. Plan and release gates can allow, deny or require approval; approvals come from a human other than the author.

Happy path. Every gate allows and verification passes first time.

  1. Understand / Classify: Context is resolved from authorised sources and the Change is classified. Acts: engine (read-only grant). Evidence: Context resolved: sources used and digests.
  2. Plan gate: Policy allows the plan under the initial grant. Acts: engine plans; policy decides. Evidence: Policy decision with reasons, plan digest frozen before any write grant.
  3. Implement: One work unit runs in a sandbox under a work-unit grant. Acts: author-agent (work-unit grant). Evidence: Author run completed: candidate digest, grant id, budget used.
  4. Verify: Deterministic checks pass; the reviewer adds findings, never a verdict. Acts: reviewer-agent (read-only) and deterministic verifiers. Evidence: VerdictIssued: layers, findings reference.
  5. Rehearse: A disposable environment rehearses migrations and deployment; it is destroyed at its TTL. Acts: engine with environment provider; reviewer identity. Evidence: Rehearsal evidence: timings and plan digests.
  6. Release gate: Policy consumes the verdict and the evidence list and allows the release. Acts: policy decides; release-pipeline identity only after allow. Evidence: Gate decision referencing the verdict, never raw findings.
  7. Merge: The release pipeline merges. At PR level the Change closes here; higher levels continue. Acts: release-pipeline. Evidence: Merge recorded with operation id; PR-level autonomy ends here as Closed.
  8. Release: Only the release pipeline deploys, and only if the autonomy level allows. Acts: release-pipeline (the only deployer). Evidence: Deployment recorded under the release identity.
  9. Observe: The canary window is evaluated against the declared SLOs. Acts: engine evaluates canary window. Evidence: Canary result against declared SLOs.
  10. Evidence seal: The runner seals the evidence sequence and the Change closes. Acts: runner identity (evidence writer). Evidence: Sequence sealed with an outcome record.

Verification fails, then repair. A failing check feeds one bounded repair attempt, then verification passes.

  1. Understand / Classify: Context is resolved and the Change is classified. Acts: engine (read-only grant). Evidence: Context resolved: sources used and digests.
  2. Plan gate: Policy allows the plan. Acts: engine plans; policy decides. Evidence: Policy decision with reasons, plan digest frozen before any write grant.
  3. Implement: The author-agent produces a first candidate. Acts: author-agent (work-unit grant). Evidence: Author run completed: candidate digest, grant id, budget used.
  4. Verify: A deterministic check fails. The findings are stored and referenced by digest. Acts: reviewer-agent (read-only) and deterministic verifiers. Evidence: VerdictIssued: layers, findings reference.
  5. Repair (bounded): Attempt 1 of 2 (the default cap). The findings reference is the only new input. Acts: engine re-enters Implementing; author-agent. Evidence: Repair attempt recorded with its number and findings digest.
  6. Implement: The author-agent runs again under a fresh grant. Acts: author-agent (work-unit grant). Evidence: Author run completed: candidate digest, grant id, budget used.
  7. Verify: All verification layers pass this time. Acts: reviewer-agent (read-only) and deterministic verifiers. Evidence: VerdictIssued: layers, findings reference.
  8. Rehearse: A disposable environment rehearses migrations and deployment; it is destroyed at its TTL. Acts: engine with environment provider; reviewer identity. Evidence: Rehearsal evidence: timings and plan digests.
  9. Release gate: Policy consumes the verdict and the evidence list and allows the release. Acts: policy decides; release-pipeline identity only after allow. Evidence: Gate decision referencing the verdict, never raw findings.
  10. Merge: The release pipeline merges. At PR level the Change closes here; higher levels continue. Acts: release-pipeline. Evidence: Merge recorded with operation id; PR-level autonomy ends here as Closed.
  11. Release: Only the release pipeline deploys, and only if the autonomy level allows. Acts: release-pipeline (the only deployer). Evidence: Deployment recorded under the release identity.
  12. Observe: The canary window is evaluated against the declared SLOs. Acts: engine evaluates canary window. Evidence: Canary result against declared SLOs.
  13. Evidence seal: The runner seals the evidence sequence and the Change closes. Acts: runner identity (evidence writer). Evidence: Sequence sealed with an outcome record.

Repair exhausted, escalated. Two bounded repairs fail. The Change escalates to a human instead of trying forever.

  1. Understand / Classify: Context is resolved and the Change is classified. Acts: engine (read-only grant). Evidence: Context resolved: sources used and digests.
  2. Plan gate: Policy allows the plan. Acts: engine plans; policy decides. Evidence: Policy decision with reasons, plan digest frozen before any write grant.
  3. Implement: First candidate. Acts: author-agent (work-unit grant). Evidence: Author run completed: candidate digest, grant id, budget used.
  4. Verify: Verification fails. Acts: reviewer-agent (read-only) and deterministic verifiers. Evidence: VerdictIssued: layers, findings reference.
  5. Repair (bounded): Attempt 1 of 2. Acts: engine re-enters Implementing; author-agent. Evidence: Repair attempt recorded with its number and findings digest.
  6. Implement: Second candidate. Acts: author-agent (work-unit grant). Evidence: Author run completed: candidate digest, grant id, budget used.
  7. Verify: Verification fails again. Acts: reviewer-agent (read-only) and deterministic verifiers. Evidence: VerdictIssued: layers, findings reference.
  8. Repair (bounded): Attempt 2 of 2. Acts: engine re-enters Implementing; author-agent. Evidence: Repair attempt recorded with its number and findings digest.
  9. Implement: Third candidate. Acts: author-agent (work-unit grant). Evidence: Author run completed: candidate digest, grant id, budget used.
  10. Verify: Verification fails a third time. The cap is reached. Acts: engine; waits for a human signal. Evidence: Escalation recorded with the findings digest; no grant is widened.

Approval required. Policy answers require approval. The workflow waits for a human other than the author.

  1. Understand / Classify: Context is resolved and the Change is classified as higher risk. Acts: engine (read-only grant). Evidence: Context resolved: sources used and digests.
  2. Plan gate: Policy answers require approval. The workflow now waits on a signal with a timer (default 7 days). Acts: policy; human approver pending. Evidence: Policy decision: require approval, approver group, author excluded.
  3. Plan gate: A human approver grants. The signal is rejected if the approver equals the author. Acts: human approver. Evidence: Approval record with approver principal and decision id.
  4. Implement: Work proceeds under the approved grant. Acts: author-agent (work-unit grant). Evidence: Author run completed: candidate digest, grant id, budget used.
  5. Verify: Verification passes. Acts: reviewer-agent (read-only) and deterministic verifiers. Evidence: VerdictIssued: layers, findings reference.
  6. Rehearse: A disposable environment rehearses migrations and deployment; it is destroyed at its TTL. Acts: engine with environment provider; reviewer identity. Evidence: Rehearsal evidence: timings and plan digests.
  7. Release gate: Policy consumes the verdict and the evidence list and allows the release. Acts: policy decides; release-pipeline identity only after allow. Evidence: Gate decision referencing the verdict, never raw findings.
  8. Merge: The release pipeline merges. At PR level the Change closes here; higher levels continue. Acts: release-pipeline. Evidence: Merge recorded with operation id; PR-level autonomy ends here as Closed.
  9. Release: Only the release pipeline deploys, and only if the autonomy level allows. Acts: release-pipeline (the only deployer). Evidence: Deployment recorded under the release identity.
  10. Observe: The canary window is evaluated against the declared SLOs. Acts: engine evaluates canary window. Evidence: Canary result against declared SLOs.
  11. Evidence seal: The runner seals the evidence sequence and the Change closes. Acts: runner identity (evidence writer). Evidence: Sequence sealed with an outcome record.

Denied by policy. The plan gate denies. The denial is recorded and the Change is abandoned with no write grant ever issued.

  1. Understand / Classify: Context is resolved and the Change is classified. Acts: engine (read-only grant). Evidence: Context resolved: sources used and digests.
  2. Plan gate: Policy denies the plan. Denials are evidence too. Acts: policy decision point. Evidence: Denial with rule ids as reasons and the policy decision id.
  3. Evidence seal: The runner seals the sequence. No code was written. Acts: runner identity (evidence writer). Evidence: Sequence sealed with an outcome record.

Beyond the pull request

When, and only when, the autonomy level and policy authorize it, the lifecycle continues:

  • Release. CHANGE_STATE_REHEARSING, CHANGE_STATE_RELEASE_GATE, CHANGE_STATE_MERGING and CHANGE_STATE_RELEASING. The release gate and everything after it run under the release-pipeline identity, never the author agent.
  • Observe. CHANGE_STATE_OBSERVING watches the released change for a window defined by the playbook.
  • Recover. CHANGE_STATE_RECOVERING and CHANGE_STATE_ROLLED_BACK when observation or release fails.

A change at PR level closes after the pull request is opened and never enters release states. The evidence export records that explicitly: the deployment and observation parts are marked not applicable at PR level, and the verifier checks that the chain bears this out.

Terminal and side states

StateMeaning
CHANGE_STATE_ESCALATEDA human signal is needed. Reached from failed verification, exhausted repair or a denied gate.
CHANGE_STATE_PAUSEDThe circuit breaker tripped. Work resumes only on breaker reset.
CHANGE_STATE_ABANDONEDThe change was denied, rejected or cancelled.
CHANGE_STATE_CLOSEDCompleted at the authorized level.
CHANGE_STATE_ROLLED_BACKRecovery restored the previous state.

Fresh authority per stage

Authority does not carry over. Planning runs under an initial read-oriented grant. The plan gate decides again before implementation. The release gate decides again before merge. A human can be required at either gate by policy or by risk class, and the approver cannot be the author. Because each stage re-evaluates, a decision that was right at planning time cannot be reused after the situation changed.

Reference-only payloads

The orchestration layer moves change identifiers, digests, decision references and status codes. Source, diffs, prompts and logs stay in the artifact store and travel as references. This is why a workflow history can be inspected without leaking the change itself.

Failure modes

  • Verification fails and repair is exhausted: the change escalates, it does not loop.
  • The breaker trips mid-implementation: the change pauses.
  • A gate denies: the change is abandoned with the denial recorded.

Next steps

On this page