The Agentic Transformation Lifecycle

How an autonomous system transforms critical infrastructure under governed authority — the workload-independent operational spine of the discipline. Agentic Post-Quantum Conversion is its first workload.

• Document: APQC-LIFECYCLE-004 — Lifecycle Specification
• Status: Draft 0.1
• Version: 0.1
• Date: 2026-07-02
• Editor / Authoring body: H33.ai, Inc.

This specification describes what an autonomous system does when it transforms critical infrastructure, in terms of decisions, not technology. The stages hold whether the workload is post-quantum conversion, identity modernization, PKI, secrets, cloud migration, or compliance. The workload changes; the lifecycle does not.

RFC 2119 keywords apply where used.

0. Front Matter

0.1 Normative References

• APQC-CORE-001 — The APQC Constitution.
• APQC-MODEL-003 — Conceptual Model.

0.2 Informative References

• APQC-PROBLEM-002 — Problem Definition.
• APQC-GLOSSARY-000 — Canonical Glossary.

0.3 Related Specifications

• APQC-AUTH-006 (expands Stage 4 and the Authority Graph), APQC-EVIDENCE-007 (expands Stage 9 and the Evidence Graph), APQC-ARCH-005, APQC-MATURITY-008.

0.4 Conformance Dependencies

• Depends on: APQC-CORE-001, APQC-MODEL-003, APQC-GLOSSARY-000.
• Referenced by: APQC-ARCH-005, APQC-AUTH-006, APQC-EVIDENCE-007, APQC-MATURITY-008.

1. Purpose

A transformation of critical infrastructure is a sequence of decisions made and executed under authority: what outcome is intended, what exists, what it means, who may act, what to do, what would happen, doing it, confirming it, proving it, judging it, watching it, and adapting. This document specifies that decision sequence as the canonical lifecycle of agentic transformation. It is deliberately independent of any workload so that a single platform can run many workloads on one operational model.

The lifecycle is framed around decisions rather than tools for a specific reason: tools and primitives change on a horizon of months to years, but the decisions an organization must make to transform critical infrastructure safely — and prove it made them correctly — do not. A specification anchored to the decisions outlives the technology that satisfies it, the property the discipline requires of everything it produces (APQC-CORE-001, P7).

1.1 How to read this document

Section 2 lists the twelve stages. Section 3 develops the three-graph triad and gives a state-transition view of how each stage mutates the graphs. Section 4 specifies each stage in full — objective, inputs, outputs, authority, evidence, graphs advanced, a carried worked example, failure cases, numbered conformance tests, and implementation notes. Section 5 specifies stage transitions and the gates between them. Section 6 restates and strengthens workload generality with a second worked example. Section 7 is Not In Scope.

Two worked examples run through the document. The primary example (carried through all twelve stages in Section 4) is a post-quantum conversion: an enterprise, Northwind Financial, converting a fleet of 1,240 TLS-terminating endpoints and a code-signing pipeline from classical primitives (RSA-2048 / ECDSA-P256) to NIST post-quantum and hybrid primitives. The secondary example (Section 6, summary depth) is an Agentic Identity Modernization workload, to demonstrate that the identical lifecycle governs a workload whose assets are not cryptographic keys at all.

2. The lifecycle

Twelve stages, ordered but iterative. Stage 12 re-enters Stage 1.

1. Intent Established — what business outcome is being authorized?
2. Discovery — what exists?
3. Understanding — what does it mean?
4. Authority Assignment — what is each agent allowed to do?
5. Planning — what sequence of changes satisfies the intent?
6. Simulation — what would happen if executed?
7. Execution — make governed changes.
8. Verification — did the changes occur as intended?
9. Evidence — produce immutable, portable proof.
10. Governance — evaluate policy, authority, and risk.
11. Continuous Operation — monitor for drift.
12. Continuous Adaptation — re-enter the lifecycle as the environment changes.

 (1) Intent ──► (2) Discovery ──► (3) Understanding ──► (4) Authority
                                                            │
        ┌───────────────────────────────────────────────────┘
        ▼
 (5) Planning ──► (6) Simulation ──► (7) Execution ──► (8) Verification
                                                            │
        ┌───────────────────────────────────────────────────┘
        ▼
 (9) Evidence ──► (10) Governance ──► (11) Continuous Operation
                                            │
                                            ▼
                                  (12) Continuous Adaptation
                                            │
                                            └──────► re-enters (1) Intent

The stages are ordered — each consumes an output the previous produced — but the loop is iterative and never-terminating: Continuous Operation feeds drift into Continuous Adaptation, which re-scopes Intent, re-opening the cycle. There is no "done." An estate is operated, not finished (APQC-CORE-001, P6).

3. The three-graph triad

Every stage advances one or more of three graphs. Together they are the intellectual core of the discipline; every agentic transformation workload needs all three.

A conforming lifecycle MUST maintain all three graphs. A workload that advances knowledge and execution but not authority is ungoverned; one that advances knowledge and authority but not evidence is unprovable. Each stage in Section 4 states which graph(s) it advances.

3.1 Why three graphs and not one

A naive design collapses all three into one database of "facts about the estate." The discipline refuses this because the three graphs fail categorically differently. The Knowledge Graph can be wrong (stale, incomplete) without any action being illegitimate. The Authority Graph can be correct while Knowledge is wrong — a perfectly-governed action performed on a misunderstood asset. The Evidence Graph can be complete while Authority was over-broad — every action proven, yet none that should have been permitted. Keeping the three separate is what lets Governance (Stage 10) ask "did execution stay inside authority?" as a join between two independently-maintained graphs rather than as a tautology. Conflating them destroys the ability to detect the most dangerous failure: a well-evidenced action that was never authorized.

3.2 The invariants that hold across all edges

Three invariants (APQC-MODEL-003 §4) are not stages but conditions on every transition:

• I1 — Proof. No transition is complete until it has produced independently-verifiable evidence.
• I2 — Authority. No action occurs outside the Authority Graph; an unauthorized attempt produces no effect and no evidence.
• I3 — Least Exposure. Sensitive material is acted upon without being revealed to the acting agent.

A stage may advance a graph, but it may never do so in violation of an invariant. A conformance failure against an invariant is more severe than a conformance failure against a stage output, because invariant violations are silent and cross-cutting.

3.3 State-transition view: how each stage mutates the graphs

The following table gives the net effect of each stage on the three graphs. K = Knowledge, A = Authority, E = Evidence. + = adds/advances nodes or edges; ✓ = verifies against reality; — = no direct effect.

Three things in this table are load-bearing and non-obvious:

1. Grants are reserved in Planning and consumed in Execution (rows 5 and 7). This two-phase treatment of authority is what lets Simulation reason about a plan without any risk that reasoning about a change silently consumes the right to make it. A grant reserved but never consumed leaves an auditable "authorized but not executed" record — itself evidence of restraint.
2. Governance verifies the Authority Graph against reality (row 10), it does not build it. Governance holds A constant and joins it against E. If Governance ever mutates A, it has stopped judging and started permitting, which is a conformance failure (§4, Stage 10).
3. The Evidence Graph is append-only across every row. No stage edits or deletes prior Evidence. Correction is expressed as a new Evidence node that supersedes an old one, with the supersession itself evidenced. This is the structural expression of P1 (proof over assertion) and P7 (portability).

4. Stage specifications

Each stage is specified by: objective, inputs, outputs, authority required, evidence generated, graph(s) advanced, a worked example (Northwind Financial, carried consistently), failure cases / anti-patterns, conformance tests (Given/When/Then, numbered), and implementation notes.

Conformance test identifiers use the form CT-<stage>.<n>. A process claiming conformance to this specification MUST satisfy every MUST-level conformance test; SHOULD-level tests are strongly recommended and any failure MUST be justified in the process's conformance statement.

Stage 1 — Intent Established

• Objective: capture and authorize the business outcome the transformation must achieve, as a bounded, traceable intent.
• Inputs: a stated goal; its constraints (scope, budget, deadlines, regulatory drivers); its risk tolerance; and its authorizing party.
• Outputs: a bounded, authorized intent that scopes everything downstream — including the definition of which assets are "relevant" for Discovery.
• Authority required: the authority to set intent — the highest-level grant; all later authority derives from it. This authority is not delegated by the system; it enters from outside it (a human authorizer or a governing body).
• Evidence generated: a signed intent record binding who authorized what outcome, when, under what constraints. This is the first node in the Evidence Graph and the root node in the Authority Graph.
• Graphs advanced: Authority (root grant), Evidence.

Worked example. Northwind Financial's CISO authorizes an intent: "Convert all internet-facing TLS termination and the production code-signing pipeline to NIST-standard post-quantum cryptography, hybrid where interoperability requires it, complete within four quarters, prioritizing systems handling data with a confidentiality horizon beyond ten years." The intent names constraints (four quarters; hybrid permitted), a risk driver (harvest-now-decrypt-later on long-lived confidential data, mapped to APQC-CORE-001 T6), and an authorizing party (the CISO, acting under a board resolution). The intent record is signed and becomes Evidence node E1 and Authority root A0.

Failure cases / anti-patterns. - Unbounded intent: "modernize our cryptography" with no scope, deadline, or asset class. Everything downstream inherits the ambiguity; Discovery cannot decide what is relevant, and Governance cannot judge completion because there is no defined finish line. - Unauthorized intent: an engineering team sets the intent without a grant traceable to a governing authority. Every derived grant is then rooted in nothing, and the entire Authority Graph is unanchored — the most severe possible failure, because it invalidates every action beneath it. - Implicit intent: the intent lives in a slide deck or a ticket, unsigned. It cannot seed the Evidence Graph, so no downstream evidence can be traced to it.

Conformance tests. - CT-1.1 (MUST): Given a transformation in progress, when any stage output is inspected, then it MUST be traceable to exactly one signed intent record. - CT-1.2 (MUST): Given an intent record, when its authorizing party is checked, then that party MUST be identifiable and MUST hold authority to set intent from outside the system. - CT-1.3 (MUST): Given an intent record, when its scope is read, then it MUST bound the relevant asset classes and a target state such that "complete" is decidable. - CT-1.4 (SHOULD): Given an intent record, when its constraints are read, then they SHOULD state risk tolerance and any regulatory driver, so downstream prioritization is not invented later.

Implementation notes. The intent record is the only lifecycle artifact whose authorizing authority originates outside the system; every other grant is derived by delegation (Stage 4). Implementations SHOULD treat intent as immutable within a cycle: a changed outcome is a new intent (a new Stage 1), linked to the old via a Stage 12 delta, not an edit. This preserves the property that every action beneath an intent was authorized under the intent as it stood when the action occurred.

Stage 2 — Discovery

• Objective: observe the estate and enumerate every asset relevant to the intent, with stated coverage.
• Inputs: the intent (which scopes what is relevant); read/observe access to the estate.
• Outputs: raw observations of assets, each carrying provenance (where observed, when, by what sensor) and a coverage statement.
• Authority required: read/observe authority only. Discovery holds no authority to change anything (glossary: Discovery).
• Evidence generated: a signed observation manifest binding the observation set to the sensors and time window that produced it.
• Graphs advanced: Knowledge (population), Evidence.

Worked example. Discovery agents observe Northwind's estate under read-only authority: TLS endpoints are enumerated from load-balancer configurations, certificate transparency logs, and live handshake probes; the code-signing pipeline is observed from CI/CD configuration, artifact repositories, and HSM key-slot inventories. The result: 1,240 TLS-terminating endpoints (of which 1,118 present RSA-2048 certificates and 122 present ECDSA-P256), one code-signing pipeline using an ECDSA-P256 key held in an HSM slot, and 17 endpoints observed but not fully characterized (probes timed out behind a firewall). Coverage is stated as "1,223 of an estimated 1,240 characterized; 17 pending; estimate derived from load-balancer config, which may itself be incomplete." Discovery does not assert the estate is 1,240; it asserts what it observed and what it could not.

Failure cases / anti-patterns. - Silent incompleteness: reporting "1,223 endpoints" as if it were the whole estate, hiding the 17 pending and the possibility of assets the load-balancer config never named. This produces a Knowledge Graph that is confidently wrong. - Stale observation: treating a six-month-old scan as current. The estate is a live population (glossary: Estate); staleness silently reintroduces the very drift the lifecycle exists to eliminate. - Observation mistaken for change: a Discovery agent that "fixes" a misconfiguration it finds. This violates I2 — Discovery has no change authority — and corrupts the separation between sensing and acting.

Conformance tests. - CT-2.1 (MUST): Given a Discovery output, when its coverage is inspected, then completeness MUST be stated (with method and known gaps), not assumed. - CT-2.2 (MUST): Given a Discovery agent, when it encounters a changeable defect, then it MUST NOT change anything; any attempt MUST fail closed and produce no effect. - CT-2.3 (MUST): Given an observation, when its provenance is checked, then it MUST bind the sensor and the observation time. - CT-2.4 (SHOULD): Given two Discovery runs over the same scope, when compared, then the delta SHOULD be attributable to real estate change or to coverage change, distinguishably.

Implementation notes. Discovery hands raw observations to Understanding, not a finished Knowledge Graph — the two stages are deliberately separated so that classification errors (Stage 3) are distinguishable from observation errors (Stage 2). Discovery is continuous, not a one-time scan; the same function is re-invoked by Stage 11. Coverage should be expressed as a measurable ratio against a stated denominator, and the denominator's own uncertainty should be carried forward, not discarded.

Stage 3 — Understanding

• Objective: turn raw observations into meaning — classify each asset and resolve the dependency edges among them, producing the Knowledge Graph.
• Inputs: raw observations from Stage 2 (with their coverage statement).
• Outputs: the Knowledge Graph — classified asset nodes and the dependency edges among them, including each asset's blast radius (what breaks if it changes).
• Authority required: analysis authority; no change authority.
• Evidence generated: classification and dependency records with provenance, so that any classification can be traced to the observation that supports it.
• Graphs advanced: Knowledge (structure), Evidence.

Worked example. Understanding classifies Northwind's 1,240 endpoints: 1,118 as RSA-2048 TLS termination, 122 as ECDSA-P256, and it resolves dependencies. It discovers that 43 of the RSA endpoints front a legacy payments partner whose client library rejects any non-RSA certificate — a dependency edge that makes those 43 non-convertible to pure PQ without breaking the partner. It classifies the code-signing key as a dependency root: 312 downstream artifacts are validated against it, so rotating it invalidates every previously-signed artifact unless a hybrid or dual-signing path is used. Blast radius is now explicit: converting the signing key is not one change but a change with 312 dependents. The 17 uncharacterized endpoints from Stage 2 are marked unclassified and carried forward as a known gap, not silently dropped.

Failure cases / anti-patterns. - Misclassification: labeling an ECDSA endpoint as RSA, causing Planning to select the wrong conversion path. - Missed dependency: failing to find the 43 payments-partner endpoints. This is the single most expensive Stage 3 failure — it surfaces as a production outage during Execution rather than as a plan constraint. - Blast radius by assumption: asserting "the signing key has no dependents" without tracing the 312 artifacts. An unmeasured blast radius is an unbounded one.

Conformance tests. - CT-3.1 (MUST): Given the Knowledge Graph, when any classified asset is inspected, then its classification MUST be traceable to a Stage-2 observation. - CT-3.2 (MUST): Given an asset that will be a candidate for change, when its blast radius is queried, then the set of dependents MUST be enumerable, not estimated by assertion. - CT-3.3 (MUST): Given an unclassifiable observation, when the graph is built, then it MUST appear as an explicit unclassified node, never be dropped. - CT-3.4 (SHOULD): Given a dependency edge, when inspected, then its direction (depends-on vs depended-on-by) SHOULD be explicit so blast radius is computable in both directions.

Implementation notes. Understanding is where the Knowledge Graph acquires structure; Discovery only gives it population. The separation matters because dependency resolution is the stage most likely to be incomplete, and conflating it with observation hides which is at fault. The blast radius computed here is consumed directly by Planning (sequencing) and by Simulation (predicted failure surface); its quality caps the quality of both.

Stage 4 — Authority Assignment

• Objective: determine what each agent is permitted to do, deriving every grant from the intent and binding it to specific assets in the Knowledge Graph.
• Inputs: the intent (Stage 1); the Knowledge Graph (Stage 3); the organization's delegation structure and policy.
• Outputs: the Authority Graph — scoped, time-bounded, revocable grants, each bound to a specific class of action on a specific class of asset, and each traceable up a delegation chain to the intent root.
• Authority required: the authority to delegate authority (itself derived from the intent root).
• Evidence generated: delegation records binding who delegated what to whom, on which assets, within what bounds, revocable by whom.
• Graphs advanced: Authority (delegations), Evidence.

Worked example. From Northwind's intent root A0, Authority Assignment derives grants: a TLS-conversion grant scoped to the 1,197 convertible endpoints (1,240 minus the 43 partner-locked ones minus… — see below), valid for the four-quarter window, revocable by the CISO or the platform's change-control authority; a code-signing-key-conversion grant scoped to exactly one asset, requiring a dual-signing transitional path, expiring at quarter-end. The 43 partner-locked endpoints receive no conversion grant at all — Authority Assignment declines to grant authority for an action Understanding proved would break a dependency, so the illegitimate action is impossible by construction rather than merely discouraged. The 17 unclassified endpoints likewise receive no grant until they are classified. Each grant is bound to the specific asset nodes, not to "TLS" in the abstract.

Failure cases / anti-patterns. - Over-broad grant: granting "convert all TLS endpoints" including the 43 partner-locked ones. The Authority Graph now permits an action known to be breaking. - Grant without expiry or revocation: a standing conversion right that outlives the intent window. Authority must be time-bounded and revocable (glossary: Authority). - Untraceable privilege: a grant that cannot be traced up to the intent root. Governance (Stage 10) then cannot prove the action was legitimate even if it succeeded.

Conformance tests. - CT-4.1 (MUST): Given any prospective action, when its authority is checked, then it MUST map to exactly one grant, and that grant MUST be traceable to the intent root. - CT-4.2 (MUST): Given any grant, when inspected, then it MUST be scoped (action × asset), time-bounded, and revocable; a grant missing any of these MUST be rejected. - CT-4.3 (MUST): Given an action that Understanding proved breaks a dependency, when Authority Assignment runs, then no grant for that action MUST exist (impossible by construction, not merely policy-discouraged). - CT-4.4 (SHOULD): Given the Authority Graph, when the revocation authority for each grant is queried, then it SHOULD be a single identifiable party or role.

Implementation notes. Authority Assignment binds grants to Knowledge Graph nodes, which is why it must follow Understanding: you cannot scope a grant to "the convertible endpoints" until Understanding has determined which are convertible. This stage is expanded fully in APQC-AUTH-006. The design goal is that Execution (Stage 7) can present a grant at the moment of each action and have out-of-scope actions fail closed with no effect — which is only possible if grants are asset-bound and revocation is live.

Reference implementation (informative). The authority root and delegation fabric are realized by H33-Root in the reference implementation (APQC-REFERENCE-010); credential-bound execution without exposure is realized by H33-Key. These names are illustrative and MUST NOT appear in a conformance claim against this normative specification.

Stage 5 — Planning

• Objective: produce the ordered, reversible sequence of changes that satisfies the intent without violating dependencies or authority.
• Inputs: intent; Knowledge Graph; Authority Graph.
• Outputs: an ordered plan in which each planned action is bounded by an existing (reserved) grant, respects dependency ordering, and carries a reversal path.
• Authority required: planning authority. The plan proposes only actions for which authority exists; it reserves grants but does not consume them.
• Evidence generated: a signed plan bound to the intent and to the specific grants it will consume.
• Graphs advanced: Knowledge (planned deltas), Authority (reserved grants), Evidence.

Worked example. Planning sequences Northwind's conversion. Because Understanding found the code-signing key has 312 dependents, the plan does not rotate it in place; it schedules a dual-signing transitional path — new artifacts are signed with both the classical ECDSA key and a new ML-DSA key, so old verifiers keep working while new verifiers gain PQ assurance — with a reversal path that disables ML-DSA signing if the new verifier rollout stalls. TLS endpoints are sequenced by blast radius: low-dependency internal endpoints first (to build evidence and confidence), the payments-facing endpoints last, and the 43 partner-locked endpoints scheduled for hybrid deployment (classical + PQ presented together) since pure PQ is non-viable. Each planned action reserves its Stage-4 grant; the plan is signed and bound to intent E1.

Failure cases / anti-patterns. - Planning beyond authority: a plan that includes converting the 43 partner-locked endpoints, for which no grant exists. The plan is unexecutable and its presence signals that Planning ignored the Authority Graph. - Dependency-blind sequencing: rotating the signing key before establishing dual-signing, invalidating 312 artifacts at once. - No rollback path: a plan with no reversal for the signing-key change. Reversibility is a Constitution principle (P5); an irreversible plan for a high-blast-radius change is non-conformant.

Conformance tests. - CT-5.1 (MUST): Given a plan, when each planned action is checked, then it MUST be bounded by a reserved grant from the Authority Graph. - CT-5.2 (MUST): Given a plan, when its ordering is checked against the Knowledge Graph, then no action MUST precede an action it depends on. - CT-5.3 (MUST): Given a plan, when each material action is inspected, then it MUST carry a reversal path or an explicit, evidenced justification for why reversal is infeasible. - CT-5.4 (SHOULD): Given a plan, when sequencing is inspected, then low-blast-radius actions SHOULD precede high-blast-radius actions to build evidence before risk.

Implementation notes. Planning reserves grants rather than consuming them (see §3.3), which is what lets Simulation reason over the plan without side effects. The plan is the primary input to both Simulation and Execution; it must be expressed at the granularity of individual authorized actions, not as coarse phases, so that a single action can fail and be reversed without collapsing the whole plan.

Stage 6 — Simulation

• Objective: predict what would happen if the plan executed, before touching production — including predicted failures and blast radius.
• Inputs: the plan (Stage 5); the Knowledge Graph.
• Outputs: a predicted outcome branch of the Knowledge Graph, with predicted failures, interoperability breaks, and blast-radius realizations surfaced.
• Authority required: simulate-only authority; no production effect.
• Evidence generated: a signed simulation result recording what was predicted and against which graph state.
• Graphs advanced: Knowledge (predicted state), Evidence.

Worked example. Simulation runs Northwind's plan against a model of the estate. It predicts that the hybrid deployment on the 43 partner-locked endpoints increases the TLS handshake size beyond a limit configured on the partner's legacy appliance, which would cause connection resets — a failure invisible in Planning and catastrophic in Execution. It also predicts that dual-signing doubles code-signing latency, pushing one nightly build past its window. Both are surfaced as predicted failures before any production change, with blast radius attached (which endpoints, which builds). The plan returns to Stage 5 for revision: the partner-facing hybrid is re-sequenced behind a partner-side appliance upgrade, now a named precondition.

Failure cases / anti-patterns. - Simulation divergence: simulating against a model so unlike production that its predictions are worthless — a green simulation that reflects the model's optimism, not reality's behavior. - Skipping simulation for "obvious" changes: the changes that seem obvious (a "simple" TLS cert swap) are exactly where the handshake-size failure hid. - Predicting only success: a simulation that surfaces the happy path but not predicted failures is a demonstration, not a simulation.

Conformance tests. - CT-6.1 (MUST): Given a Simulation, when it runs, then it MUST produce a predicted outcome that includes predicted failures and blast radius, not success alone. - CT-6.2 (MUST): Given a Simulation, when its authority is checked, then it MUST have no production effect. - CT-6.3 (MUST): Given a material predicted failure, when Simulation completes, then the plan MUST NOT proceed to Execution until the failure is resolved or explicitly, evidenced-ly accepted. - CT-6.4 (SHOULD): Given a Simulation result, when compared post-hoc to actual Execution outcome, then the divergence SHOULD be measured and fed back to improve future model fidelity.

Implementation notes. Simulation is the last stage before reality changes, and the cheapest place to fail. Its value is bounded by model fidelity, so implementations SHOULD close the loop with CT-6.4: comparing predictions to actual outcomes (available after Stage 8) and using the divergence to improve the model. A simulation that is never checked against reality decays into a rubber stamp.

Stage 7 — Execution

• Objective: make the governed changes in the live estate, consuming reserved grants, under least exposure.
• Inputs: the approved plan; the reserved grants; the simulation result (with all material predicted failures resolved or accepted).
• Outputs: the transformed assets, with the Knowledge Graph advanced to actual post-change state.
• Authority required: execution authority, presented at the moment of each action; an out-of-scope action fails closed and produces nothing (I2).
• Evidence generated: a per-change execution record bound to its consumed grant. Under least exposure (I3), sensitive material is acted upon without being revealed to the actor.
• Graphs advanced: Knowledge (actual state), Evidence (execution links).

Worked example. Execution agents convert Northwind's endpoints in the planned order. For each TLS endpoint, the agent presents its reserved grant, performs the certificate change, and emits a per-change execution record binding which endpoint, from RSA-2048 to hybrid ML-KEM+X25519, at what time, under which grant. When an agent reaches one of the 43 partner-locked endpoints before the partner appliance upgrade (the precondition from Stage 6) is confirmed, its grant is not yet valid — the action fails closed, changes nothing, and produces no evidence, exactly as I2 requires. The code-signing key conversion runs under least exposure: the new ML-DSA private key is generated and used inside the HSM; the execution agent orchestrates dual-signing without the private key material ever entering its memory.

Failure cases / anti-patterns. - Action beyond authority: an agent converting an endpoint whose grant expired mid-cycle. If this produces a change, I2 is violated and the whole governance chain is unsound. - Partial change without rollback: the signing-key rotation half-applied — new key active, old verifiers not yet migrated — with no reversal, stranding 312 artifacts. - Exposure during change: the signing private key read into the agent's context to "make signing easier." This violates I3 and creates a T5 exposure (APQC-CORE-001).

Conformance tests. - CT-7.1 (MUST): Given an execution action, when it runs, then valid authority MUST be present at the moment of action; if absent, the action MUST fail closed and produce no effect and no evidence. - CT-7.2 (MUST): Given a completed execution action, when its record is inspected, then it MUST bind the change to the specific grant consumed. - CT-7.3 (MUST): Given a change to sensitive material, when Execution runs, then the material MUST NOT be revealed to the acting agent (I3). - CT-7.4 (MUST): Given a material change, when it is applied, then it MUST be staged/reversible per its plan entry, or fail closed if reversal is unavailable.

Implementation notes. Execution is the only stage that mutates reality, and the only stage where the invariants are tested against an adversary rather than a checklist. Authority must be checked at the moment of action, not at plan approval time, because grants can be revoked or expire between planning and execution. The per-change execution record is the raw material Stage 9 seals into portable evidence — it must be emitted as a byproduct of the change, not reconstructed afterward.

Stage 8 — Verification

• Objective: confirm, independently of the executor, that the changes occurred as intended and the assets are correct and functional.
• Inputs: the post-execution estate; the plan; validation vectors (known-answer tests, interoperability suites).
• Outputs: verification results, including deliberate-mismatch (negative) tests proving that tampering would be detected.
• Authority required: verify authority (independent of execution authority).
• Evidence generated: signed verification results.
• Graphs advanced: Knowledge (confirmed state), Evidence.

Worked example. Verification re-observes Northwind's converted endpoints independently — it does not trust the execution agent's own report. It performs live handshakes to confirm each converted endpoint negotiates the hybrid primitive, runs interoperability suites against real clients, and validates (glossary sense: correctness against spec) that the code-signing pipeline's dual-signed artifacts verify under both the classical and the ML-DSA verifier. Crucially, it runs negative tests: it presents a deliberately corrupted dual-signature and confirms the verifier rejects it. A verifier that only passes the happy path cannot detect tampering; the negative test is what proves detection works. Verification catches that 3 of the 122 ECDSA endpoints were converted but left the old certificate chain active as a fallback — a partial change — and flags them for reversal.

Failure cases / anti-patterns. - Verifying intent instead of reality: checking the plan said "converted" rather than re-observing that the endpoint negotiates PQ. - Happy-path-only verification: no negative tests, so tampering detection is unproven. - Verifier trusts executor: the executor reports success and the verifier records it. Verification must be independent (glossary: Verification — "independently of the actor").

Conformance tests. - CT-8.1 (MUST): Given a converted asset, when it is verified, then verification MUST re-observe reality independently of the executor's report. - CT-8.2 (MUST): Given a verification run, when it completes, then it MUST include negative/deliberate-mismatch tests demonstrating that tampering would be detected. - CT-8.3 (MUST): Given a partial or incorrect change, when verification runs, then it MUST fail for that asset and not report population-level success. - CT-8.4 (SHOULD): Given a functional asset, when verified, then validation (correctness against spec) SHOULD be run in addition to verification (change-occurred-as-intended).

Implementation notes. Verification and validation are distinct (glossary): verification confirms the change occurred as intended; validation confirms the result is correct and functional against its spec. Both belong here, but conflating them hides the difference between "we changed the wrong thing correctly" and "we changed the right thing incorrectly." Verification's independence from Execution is structural, not procedural — the verifier should not consume the executor's success report as an input to its own conclusion.

Stage 9 — Evidence

• Objective: seal each verified material change into immutable, portable, independently-verifiable proof.
• Inputs: execution records (Stage 7); verification results (Stage 8); the governing authority under which they occurred.
• Outputs: entries in the Evidence Graph, each binding who acted, what changed, when, and under whose authority — verifiable offline, without trusting the issuer, for the full retention horizon.
• Authority required: the authority to issue evidence; absent valid authority, no evidence is produced.
• Evidence generated: the proof artifacts themselves — the discipline's memory.
• Graphs advanced: Evidence (the authoritative record).

Worked example. For each of Northwind's converted assets, Stage 9 emits a portable, post-quantum-signed commitment binding the change to its authority: endpoint X converted from RSA-2048 to hybrid ML-KEM+X25519, verified negotiating PQ at time T, under grant G traceable to intent E1, by agent whose authority chains to root A0. The artifact commits to (does not expose) the sensitive inputs, is signed under post-quantum signatures so it survives a future quantum adversary, and is anchored so its timestamp cannot be backdated by anyone — including Northwind. Four years later, a regulator can hand the artifact to an independent verifier and confirm the conversion happened, when, and under whose authority, without contacting Northwind or the tool vendor.

Failure cases / anti-patterns. - Editable / issuer-bound evidence: a database row or a log entry that the issuer can alter. This is a log, not evidence (glossary), and fails P1/P7. - Vendor-locked verification: evidence that can only be verified by the tool that produced it. It dies with the vendor and cannot be handed to a regulator. - After-the-fact assembly: generating "evidence" by querying logs at audit time rather than emitting it as a byproduct of the change. The gap between change and assembly is where tampering hides.

Conformance tests. - CT-9.1 (MUST): Given an evidence artifact, when a third party verifies it, then verification MUST succeed offline, without contacting the issuer, for the full retention horizon. - CT-9.2 (MUST): Given an evidence artifact, when inspected, then it MUST bind who/what/when/authority and MUST commit to sensitive inputs without exposing them (I3). - CT-9.3 (MUST): Given a material change with no valid issue-authority, when Stage 9 runs, then no evidence MUST be produced. - CT-9.4 (MUST): Given the Evidence Graph, when any correction occurs, then it MUST be expressed as a new superseding node, and prior nodes MUST NOT be edited or deleted (append-only).

Implementation notes. Evidence is emitted as a byproduct of verified change, not assembled afterward — this is the structural difference between evidence and a log. The Evidence stage is expanded fully in APQC-EVIDENCE-007. The append-only property (CT-9.4) is what makes the Evidence Graph a durable memory: it grows monotonically and every state it ever held is reconstructable.

Reference implementation (informative). The proof artifact is realized as the H33-74 substrate (a 74-byte post-quantum attestation) in APQC-REFERENCE-010, anchored via HATS. These names are illustrative and MUST NOT appear in a conformance claim.

Stage 10 — Governance

• Objective: evaluate the whole transformation against policy, authority, and risk — specifically, prove over the entire population that no action exceeded its authority.
• Inputs: the three graphs (Knowledge, Authority, Evidence).
• Outputs: governance findings — a population-wide confirmation that execution stayed within authority, plus any violations, gaps, or residual risks, each with an owner.
• Authority required: governance/oversight authority. Governance judges; it does not permit.
• Evidence generated: a governance audit trail over the population.
• Graphs advanced: Authority (verified against reality, not mutated), Evidence.

Worked example. Governance joins Northwind's Evidence Graph against its Authority Graph and proves, over all 1,197 converted assets, that each change consumed a grant that was valid, scoped, and unexpired at the moment of action — and it identifies exactly the exceptions: the 43 partner-locked endpoints remain unconverted with no grant (correct restraint, recorded as a conscious deferral with a reopen trigger — the partner appliance upgrade), the 17 unclassified endpoints remain out of scope pending classification, and the 3 fallback-chain endpoints Verification caught are logged as reverted. Governance produces the sentence an auditor actually wants: "Over 1,240 in-scope assets, 1,197 were converted under valid authority, 43 were deferred by policy, 17 are pending discovery, and zero actions occurred outside a grant."

Failure cases / anti-patterns. - Governance as opinion: a written assessment ("we believe controls were followed") rather than a verifiable join of Evidence against Authority. - Governance that mutates authority: if Governance grants or broadens authority to make an action retroactively legitimate, it has stopped judging and started permitting — a conformance failure (§3.3). - Unenforceable findings: violations reported without owners or reopen triggers, so nothing changes.

Conformance tests. - CT-10.1 (MUST): Given the three graphs, when Governance runs, then it MUST prove over the whole population whether each action stayed within its authority, by joining Evidence against Authority. - CT-10.2 (MUST): Given a Governance run, when it completes, then it MUST NOT have mutated the Authority Graph; authority is held constant and judged, not changed. - CT-10.3 (MUST): Given any violation or deferral, when Governance reports it, then it MUST carry an owner and, for deferrals, a reopen trigger. - CT-10.4 (SHOULD): Given the population, when Governance reports, then the result SHOULD be expressible as a single population-wide statement (converted / deferred / pending / out-of-authority counts).

Implementation notes. Governance is a read over three graphs, never a write to the Authority Graph (§3.3). Its distinguishing power is population-wide provability: not "we spot-checked," but "over the entire estate, here is exactly where authority was and was not consumed." Deferrals (the 43 endpoints) are first-class findings, not omissions — a conscious "known-deferred" with a reopen trigger is stronger governance than a silent gap.

Stage 11 — Continuous Operation

• Objective: monitor the estate continuously for drift — the reappearance of the pre-transformation state.
• Inputs: the live estate; the Knowledge and Evidence graphs (the record of what should be true).
• Outputs: drift detections, characterized (which asset, what regressed, when detected).
• Authority required: monitor authority (read-only, like Discovery).
• Evidence generated: continuous drift receipts — evidence that the estate was checked, and what was found, even when nothing drifted.
• Graphs advanced: Knowledge (current truth), Evidence.

Worked example. Six weeks after Northwind's conversion, Continuous Operation detects that a newly-deployed load balancer, provisioned from an old infrastructure template, is serving RSA-2048 on 8 endpoints inside the converted scope — classical primitives have reappeared (drift, glossary). It also detects that the partner appliance upgrade (the reopen trigger from Stage 10) has completed, meaning the 43 deferred endpoints are now convertible. Both are emitted as characterized drift receipts. Critically, on the weeks where nothing drifted, Continuous Operation still emits receipts that it checked and found conformance — absence of drift is itself a proven fact, not an assumption.

Failure cases / anti-patterns. - Transformation treated as terminal: the project is declared "done" and monitoring stops. Drift then accumulates invisibly until the next audit. - Blind spots: monitoring only the assets that were converted, not the templates and pipelines that spawn new ones — so drift enters through a channel that is never watched. - Silence conflated with conformance: no receipt when nothing drifts, so "no news" is indistinguishable from "not checked."

Conformance tests. - CT-11.1 (MUST): Given a transformed estate, when time passes, then the estate MUST continue to be monitored for drift; monitoring MUST NOT terminate with the transformation. - CT-11.2 (MUST): Given a drift event, when detected, then it MUST be characterized (asset, regression, detection time) and emitted as evidence. - CT-11.3 (SHOULD): Given a monitoring interval with no drift, when it completes, then a receipt SHOULD still be emitted so that "checked-and-clean" is distinguishable from "not checked." - CT-11.4 (SHOULD): Given the estate's provisioning channels (templates, pipelines), when monitoring scope is set, then it SHOULD include the sources of new assets, not only existing ones.

Implementation notes. Continuous Operation re-invokes the Discovery function (Stage 2) on a standing basis, comparing current observation against the Evidence Graph's record of what should be true. Its output is the primary trigger for Stage 12. The subtle requirement is CT-11.3: emitting evidence of conformance, not only of drift, so the audit trail is continuous rather than punctuated by incidents.

Stage 12 — Continuous Adaptation

• Objective: re-enter the lifecycle as intent, environment, or standards change — governing and proving each adaptation as a first-class cycle.
• Inputs: drift detections (Stage 11); new or changed intent; changed standards (e.g., an algorithm deprecation).
• Outputs: a re-opened lifecycle — a new Stage 1 intent — with versioned deltas linking this cycle to the last across all three graphs.
• Authority required: the authority to re-scope intent (a fresh Stage-1 authorization, not a reused one).
• Evidence generated: versioned lifecycle deltas linking each cycle to its predecessor.
• Graphs advanced: all three (the loop closes).

Worked example. Northwind's two drift detections from Stage 11 each open a new cycle. The 8 RSA-serving load balancers trigger a re-scoped intent to convert the drifted endpoints and fix the source template, re-entering Discovery → … → Evidence with deltas linking it to the original cycle. The now-viable 43 partner endpoints trigger a second re-scoped intent to convert them to hybrid, its authority freshly granted (not reused from the expired original grant). A year later, a hypothetical deprecation of the original ML-DSA parameter set arrives as a changed standard, opening a third cycle to re-convert — demonstrating T7 (cryptographic-agility) handled by the loop itself. Each adaptation is authorized, executed, and proven exactly as a first cycle is; none is a silent patch.

Failure cases / anti-patterns. - A lifecycle that ends: treating adaptation as exceptional maintenance rather than the steady state. This is the definitional failure the whole loop exists to prevent (P6). - Adaptation without re-authorization: re-using the original expired grant to make the new change "because it's the same kind of work." Every new action needs fresh authority traceable to a current intent. - Unlinked cycles: a new cycle with no delta linking it to the prior one, breaking the ability to reconstruct the estate's full history.

Conformance tests. - CT-12.1 (MUST): Given a drift detection or changed standard, when adaptation occurs, then it MUST re-enter the lifecycle at Stage 1 with a fresh, authorized intent. - CT-12.2 (MUST): Given a new cycle, when it acts, then its actions MUST consume fresh authority traceable to the new intent, never reuse expired grants. - CT-12.3 (MUST): Given successive cycles, when the history is reconstructed, then each cycle MUST be linked to its predecessor by a versioned delta across all three graphs. - CT-12.4 (MUST): Given the discipline as a whole, when any point in time is inspected, then there MUST be no terminal state; the loop MUST be continuous.

Implementation notes. Continuous Adaptation is the edge that turns a project into an operating model. It is deliberately a full re-entry into Stage 1, not a shortcut back into Execution, because a shortcut would skip re-authorization and re-simulation — exactly the governance and safety a novel change most needs. The versioned deltas are what let a verifier reconstruct not just the current state but the entire trajectory that produced it.

5. Stage transitions and gating

The stages are ordered because each consumes a specific output of the prior. Between each pair of stages is a gate: a set of conditions that MUST be true before the transition may occur. A gate is not a checkpoint meeting; it is a machine-checkable predicate over the graphs and artifacts produced so far. Gate failure is a first-class outcome, not an error.

5.1 The gates

5.2 Two gates that are stricter than the rest

Two transitions are fail-hard and deserve separate emphasis, because a soft failure at either is where real-world transformations cause outages or become unprovable:

• 6 → 7 (Simulation to Execution). This is the last gate before reality changes. An unresolved material predicted failure MUST NOT be waved through; it must be resolved, or accepted with signed, evidenced justification naming who accepted the residual risk. The Northwind handshake-size failure (Stage 6) is the archetype: cheap to catch here, an outage if waved through.
• 7 → 8 and the I2 rule. If Execution ever produces a change without valid authority at the moment of action, the correct behavior is not "log a warning and continue" — it is fail closed, produce no change, produce no evidence (CT-7.1). A change that occurred outside authority poisons the Governance join (Stage 10) and cannot be made legitimate after the fact.

     gate           gate          gate            gate
[6 Simulation] ──►X──► [7 Execution] ──►X──► [8 Verification]
      │  material predicted        │  authority absent
      │  failure unresolved        │  at moment of action
      ▼                            ▼
  return to Planning/         fail closed:
  Authority (revise)          no change, no evidence

6. Workload generality

The twelve stages and the three graphs are invariant across workloads. Only the meaning of "asset," "change," and "target state" varies:

• Agentic Post-Quantum Conversion — asset = cryptographic use; change = classical→PQ. (The first and reference workload; carried through Section 4 as Northwind Financial.)
• Agentic Identity Modernization — asset = identity/credential; change = legacy→modern federation.
• Agentic PKI Modernization — asset = certificate/CA; change = legacy→PQ-ready hierarchy.
• Agentic Secrets Modernization — asset = secret/credential store; change = exposed→governed use.
• Agentic Cloud Migration — asset = workload; change = source→target platform.
• Agentic Compliance Automation — asset = control; change = self-reported→continuously-evidenced.

Because the lifecycle is shared, the system that runs it is, by construction, a platform (see APQC-CORE-001 §10).

6.1 Second worked example (summary depth): Agentic Identity Modernization

To prove the lifecycle is not secretly PQC-specific, here is the same twelve stages driving a workload whose assets are identities and credentials, not cryptographic keys. The organization, Contoso Health, is retiring a legacy on-premises identity store (LDAP + password + a homegrown SSO) in favor of modern federated identity with phishing-resistant authentication.

• 1 Intent Established. The CISO authorizes: "Migrate all workforce and service identities to federated, phishing-resistant authentication within three quarters, retiring the legacy password store, with zero standing lockout." Signed; root of the Authority Graph.
• 2 Discovery. Read-only observation enumerates 9,400 workforce identities, 2,100 service accounts, 41 applications consuming legacy SSO, and 6 identity sources of truth. Coverage stated: 3 applications authenticate via an undocumented direct-LDAP bind — a known gap carried forward.
• 3 Understanding. Classification resolves dependencies: 214 service accounts have hardcoded credentials in application config (blast radius: rotating them without app changes breaks those apps); 12 applications cannot do modern federation and require a bridge. The Knowledge Graph now holds identities as nodes and "authenticates-against" edges.
• 4 Authority Assignment. Grants are scoped: an identity-migration grant over the 9,400 workforce identities; a service-account grant excluding the 214 hardcoded ones (no grant — breaking action impossible by construction) until app remediation; each time-bounded and revocable by the identity governance board.
• 5 Planning. Ordered plan: pilot cohort first, then department-by-department by blast radius; the 12 non-federatable apps scheduled behind a federation bridge; every cohort carries a reversal path (re-enable legacy auth for that cohort).
• 6 Simulation. Predicts that migrating the finance cohort during quarter-close would collide with a change freeze (a policy constraint) and that the federation bridge adds a login round-trip exceeding one legacy app's timeout. Both surfaced before any identity is touched; plan revised.
• 7 Execution. Identities are migrated cohort by cohort under least exposure — credentials are re-bound to the federated provider without the migration agent reading any password material. An attempt to migrate a hardcoded service account fails closed (no grant), changing nothing.
• 8 Verification. Independently confirms each migrated identity can authenticate via the new phishing-resistant path and that the legacy path is disabled; negative test confirms a replayed legacy credential is now rejected. Catches 3 identities left with both paths active.
• 9 Evidence. Emits portable, offline-verifiable proof per identity: identity migrated to federated phishing-resistant auth at time T, legacy path disabled, under grant G traceable to intent E1 — verifiable by an auditor years later without contacting Contoso.
• 10 Governance. Proves over the whole population: 11,286 identities migrated under valid authority, 214 deferred pending app remediation (owner + reopen trigger), 3 pending discovery, zero migrations outside a grant.
• 11 Continuous Operation. Detects drift: a new SaaS onboarding created 40 identities via the legacy path (the legacy store was thought retired but a template still pointed at it). Characterized and emitted; clean-interval receipts emitted otherwise.
• 12 Continuous Adaptation. Re-scopes intent to migrate the 40 drifted identities and fix the onboarding template; fresh authority, delta-linked to the prior cycle. When the app team remediates the 214 hardcoded accounts, the deferral's reopen trigger fires and a new cycle converts them.

Every stage, every graph, every invariant behaves identically to the PQC example — only "asset" (identity vs. cryptographic use), "change" (federate vs. convert), and "target state" (phishing-resistant federation vs. post-quantum primitive) differ. This is the workload-generality claim, demonstrated rather than asserted.

6.2 What generality does and does not mean

Workload generality means the decisions and their governance are invariant; it does not mean the mechanisms are shared. The technique that converts a TLS endpoint has nothing in common with the technique that federates an identity — and this specification says nothing about either mechanism (§7). What is shared is that both must establish bounded intent, discover with stated coverage, understand blast radius, derive authority from intent, plan reversibly, simulate before production, execute under authority and least exposure, verify independently with negative tests, seal portable proof, govern population-wide, monitor for drift, and adapt continuously. The mechanism is the workload's business; the decision sequence is the discipline's.

7. Not In Scope

This specification does not cover: - Cryptographic algorithm selection or design (NIST's role). - Vendor implementations, product names, or APIs (APQC-REFERENCE-010). The clearly-marked "Reference implementation" notes in Section 4 are informative pointers only and are not part of the normative body. - Programming languages, data formats, or wire protocols. - Cloud providers or infrastructure vendors. - Workload-specific transformation techniques (defined per workload) — including the mechanism of any TLS conversion, identity federation, PKI reissuance, secret rebinding, cloud move, or control instrumentation. - The internal construction of the three graphs (data model, storage, query) — conceptual treatment is APQC-MODEL-003; realization is APQC-ARCH-005 and APQC-REFERENCE-010. - The formal decision object and its state machine (reserved for APQC-DECISION-011).

The lifecycle specifies the decisions and their governance, not the mechanism of any single change. It defines what an autonomous system decides, in what order, under whose authority, and how each decision is proven — identically for every workload, which is why the system that runs it is a platform and not a tool.