The Agentic Transformation Maturity Model

An organization's maturity is which engines it operates. Six levels, from no engines to continuous autonomous governance.

• Document: APQC-MATURITY-008 — Maturity Model
• Status: Draft 0.1
• Version: 0.1
• Date: 2026-07-02
• Editor / Authoring body: H33.ai, Inc.

This specification makes maturity concrete and self-assessable: it is defined as the progressive adoption of the five engines (APQC-ARCH-005), so an organization can locate itself by asking, plainly, which engines it operates today. It references every prior specification, so its levels are grounded rather than opinion.

RFC 2119 keywords apply where used.

0. Front Matter

0.1 Normative References

• APQC-CORE-001; APQC-GLOSSARY-000; APQC-ARCH-005 (the five engines); APQC-AUTH-006; APQC-EVIDENCE-007.

0.2 Informative References

• APQC-MODEL-003; APQC-LIFECYCLE-004; APQC-PROBLEM-002.

0.3 Related Specifications

• APQC-STANDARDS-009; APQC-REFERENCE-010.

0.4 Conformance Dependencies

• Depends on: APQC-CORE-001, APQC-ARCH-005, APQC-AUTH-006, APQC-EVIDENCE-007, APQC-GLOSSARY-000.
• Referenced by: APQC-STANDARDS-009, APQC-REFERENCE-010.

1. Purpose

Maturity models fail when they are subjective. This one is not: each level is defined by a specific, observable fact — which of the five engines (APQC-ARCH-005 §4) the organization operates — and each engine adds exactly one capability the previous level lacked. The model is a ladder: every rung adds an engine, and the top rung is all five running continuously.

The subjectivity this design removes is the historical failure of every maturity framework that scored organizations on adjectives ("developing," "defined," "optimized") — two assessors reading the same estate against an adjective scale disagree, because the adjective describes a feeling about a program rather than a fact about a system. This model replaces the adjective with an engine census: an assessor points at the running architecture (APQC-ARCH-005 Figure 1) and shades in the engines that genuinely operate. Two honest assessors reach the same level because they count the same components against the same conformance tests. The model is therefore non-inflatable: an organization cannot buy a level, brand its way to one, or claim one on the strength of a roadmap. It either operates the Authority Engine (with the properties of APQC-AUTH-006) or it does not; the Gating Interface either fails closed (APQC-ARCH-005 C3) or it does not. This is deliberate — the discipline exists because unprovable claims are worthless (APQC-CORE-001 §1), and a maturity claim is just another claim that must be grounded in something an outside party can check.

2. The model

Each level adds one engine to the prior level. An organization is at the highest level for which it operates all required engines.

This refines the summary levels of APQC-CORE-001 §13; where they differ, APQC-MATURITY-008 is authoritative (reconciled at CORE-001 v1.0).

The ordering is not arbitrary. Each engine is a strict prerequisite of the next, forced by the dependency structure of the discipline: you cannot govern what you cannot see (Authority over an undiscovered asset is authority over nothing — APQC-AUTH-006 §4.3); you cannot safely transform what you cannot govern (a Transformation Engine with no Gating Interface is ungoverned automation — APQC-ARCH-005 §5.3); you cannot prove a change you did not make (Evidence is proof of transformation); and you cannot continuously operate what you cannot prove (with no Evidence Graph to read, "governance" degrades to opinion — APQC-ARCH-005 §5.5). Because the prerequisite chain is total, a missing lower engine caps the level regardless of any higher engines present — the model's load-bearing rule, stated formally in §4.

3. Level definitions

Each subsection below expands one level into: the engines operating, the capabilities gained, what the organization still cannot do, entry criteria (what makes the level real), exit criteria (what to build to advance), typical failure modes, and a worked assessment of a hypothetical organization.

Level 0 — Unaware

Engines operating: none.

Capabilities gained: none. The cryptographic estate is used but not catalogued; keys, certificates, TLS endpoints, protocol handshakes, library calls, HSM slots, and secrets exist and are relied upon, but no engine renders them visible, governable, changeable, provable, or continuously operated. Every downstream failure of APQC-PROBLEM-002 applies in full.

What the organization still cannot do: see its own cryptography. It cannot answer "what do we have," "what breaks if we change it," "who may change it," or "did we change it" — because it operates no engine that produces those answers. It is exposed to harvest-now-decrypt-later (APQC-CORE-001 T6) with no way to measure the exposure.

Entry criteria (what places an organization here): the absence of a live, deduplicated Knowledge Graph with dependency edges and blast radius (APQC-ARCH-005 §5.1). A spreadsheet compiled once and already stale is not a Knowledge Engine; it is a snapshot of ignorance.

Exit criteria (build to advance to L1): stand up the Knowledge Engine — continuous estate sensing feeding a convergent, deduplicated Knowledge Graph with dependency edges, blast radius per asset, and explicit coverage accounting.

Typical failure modes at this level: believing a one-time inventory is knowledge; conflating a CMDB row-count with cryptographic visibility (a CMDB rarely carries cryptographic primitive, risk tier, or dependency edges); assuming completeness ("we know our estate") where no coverage figure has ever been stated.

Worked assessment. Northwind Logistics runs a large mixed estate. Security keeps a two-year-old spreadsheet of "known certs," updated ad hoc when an outage forces attention. There is no continuous sensing, no dependency resolution, no blast radius, and no stated coverage. Engines operating: none. Level: 0 — Unaware. The spreadsheet feels like inventory but produces none of the Knowledge Engine's required outputs; it is a stale snapshot, not a live graph.

Level 1 — Known

Engines operating: Knowledge.

Capabilities gained: the organization can answer "what do we have, and what breaks if we change it." The Knowledge Engine (APQC-ARCH-005 §5.1) produces a live Knowledge Graph — discovery, inventory, classification, and dependency mapping resolve the raw estate into a canonical, deduplicated asset population (one node per real asset), dependency edges, a per-asset blast radius (what breaks if it changes), and an explicit coverage figure (never assumed complete).

What the organization still cannot do: say who is permitted to change anything. It sees the estate but holds no Authority Graph; there is no scoped, revocable, rooted grant behind any prospective change. It can plan a migration on paper but cannot bound who may execute it, and any change it makes is ungoverned.

Entry criteria: a Knowledge Graph that is live (continuously sensed, not a snapshot), deduplicated, carries dependency edges and blast radius, and states coverage. Absent any one of these, the organization is still effectively Level 0 for the unsatisfied portion of its estate.

Exit criteria (build to advance to L2): stand up the Authority Engine — capture human intent, root it in a verifiable Authority Root (APQC-AUTH-006 §3), and derive scoped, time-bounded, revocable, provably-delegated grants for every prospective class of change, such that the Gating Interface can answer "does a valid Root-to-agent path permit this?"

Typical failure modes at this level: inventory theater — a beautiful dashboard with no dependency edges or blast radius, which looks like Knowledge but cannot tell the Transformation Engine what a change will break (§6.3); missed dependency edges (the classic migration break — a change severs a consumer nobody knew existed); stale graph (the estate moved, the graph did not, and any downstream planning acts on a fiction); coverage denial (claiming completeness where coverage was never measured).

Worked assessment. Harborview Health operates continuous discovery across its estate, resolves duplicates, maintains dependency edges, annotates blast radius, and reports 94% coverage with a named plan for the remaining 6%. It has no Authority Root and no delegation graph; changes are still made by ticket and human hands with no scoped grant. Engines operating: Knowledge. Level: 1 — Known. Genuine Level 1: the Knowledge Engine's outputs are all present and honest about coverage.

Level 2 — Governed

Engines operating: Knowledge + Authority.

Capabilities gained: change is now governable. The Authority Engine (APQC-ARCH-005 §5.2; APQC-AUTH-006) joins: intent, delegation, policy, constraints, and revocation produce an Authority Graph rooted in a verifiable trust anchor. Every prospective action maps to a scoped, time-bounded, revocable grant with provenance to a Root — even when change is still performed by human hands. This is the first level at which the discipline's safety property, fail-closed authority, exists: an action with no valid Root-to-agent path is not merely denied, it is inconceivable (APQC-AUTH-006 §4.2) — no effect, no evidence.

What the organization still cannot do: perform governed change at machine scale, autonomously. It can say who may act and bound the action, but a Transformation Engine does not yet exist to plan, simulate, execute, and roll back under that authority. Governance of change is present; automation of change is not.

Entry criteria: an Authority Root that is independently verifiable, durable across the retention horizon, and non-silently-replaceable (APQC-AUTH-006 §3); grants that bind Scope, Lifetime, and Provenance (§6), with no standing/unexpiring authority and no wildcard scope; monotonic-decreasing delegation (§7); and immediate, propagating, evidenced revocation (§11). Crucially, the Gating Interface MUST genuinely fail closed (APQC-ARCH-005 C3) — a system that "denies but logs" has not reached Level 2.

Exit criteria (build to advance to L3): stand up the Transformation Engine — planning, simulation, execution, and rollback that read the Knowledge Graph and are gated by the Authority Graph at both planning and the instant of each action, operating under least exposure (APQC-ARCH-005 §5.3).

Typical failure modes at this level: permission-flag theater — an access-control table or role model presented as an Authority Graph, lacking rooting, provenance, mandatory expiry, or propagating revocation (all five conflations of APQC-AUTH-006 §2); standing authority that never expires; over-broad (estate/*) grants that poison every descendant's ceiling; revocation that stops at the cut point but not the subtree. Any of these means the "Authority Engine" is not the one APQC-AUTH-006 defines, and the organization has not truly reached Level 2.

Worked assessment. Meridian Bank has a mature Knowledge Graph and has stood up an Authority Engine: a post-quantum Authority Root, scoped/time-bounded grants with provenance, monotonic delegation, and evidenced revocation that propagates through subtrees. Conversions are still executed manually by change-management staff who must hold a valid grant to proceed; an out-of-scope attempt produces nothing. Engines operating: Knowledge + Authority. Level: 2 — Governed. The invariants (fail-closed authority) now hold, satisfying the requirement that they exist from Level 2 up (§4).

Level 3 — Transforming

Engines operating: Knowledge + Authority + Transformation.

Capabilities gained: governed change at machine scale. The Transformation Engine (APQC-ARCH-005 §5.3) joins: planning (an ordered, dependency-safe, reversible plan, each action pre-bounded by an existing grant), simulation (predict failures and blast radius before touching production), execution (authority presented at the instant of each action), and rollback. It reads the Knowledge Graph, is gated by the Authority Graph, and operates under least exposure. The organization performs fast, bounded, autonomous-where-safe change — and every action still fails closed absent a valid path.

What the organization still cannot do: prove the change independently. "We converted it" is still an assertion. There is no portable, offline-verifiable Evidence Object binding what/when/who/authority; a skeptical outsider — auditor, regulator, insurer, successor org — cannot confirm the change occurred without trusting the organization's word (APQC-EVIDENCE-007 §2.4). The migration is real but unprovable.

Entry criteria: a Transformation Engine that (a) reads the Knowledge Graph before acting (never acts blind to blast radius, APQC-ARCH-005 C4); (b) consults the Gating Interface at planning and at each execution instant, failing closed (C3); (c) executes under least exposure — the acting worker never reads the sensitive material it transforms (C8); and (d) stages and, where feasible, reverses changes (APQC-CORE-001 P5).

Exit criteria (build to advance to L4): stand up the Evidence Engine — emit one portable, tamper-evident, post-quantum-signed Evidence Object per material change, authority-bound and chained, independently verifiable offline (APQC-EVIDENCE-007).

Typical failure modes at this level: proof-less transformation — the change is made, is even governed, but emits no Evidence Object, so completeness cannot be proven and "we migrated everything" collapses to "we migrated the ones we happened to record" (APQC-EVIDENCE-007 §12.3); logs mistaken for evidence (a diligent SIEM trail that dies with the system and cannot be verified offline, §2); exposure during change (keys leaked to the actor, violating least exposure). The most dangerous adjacent failure — Transformation without Authority — is not a Level-3 failure mode; it is not Level 3 at all (§4).

Worked assessment. Cascade Cloud has Knowledge and Authority and has deployed a Transformation Engine: agents plan conversions against blast radius, simulate them, execute under credential-bound least-exposure operations, and each action presents its grant to the Gating Interface. But the system produces operational logs, not Evidence Objects; there is no committed population, no chain, no offline-verifiable proof. Engines operating: Knowledge + Authority + Transformation. Level: 3 — Transforming. Fast and governed, but every completed conversion remains an assertion — exactly the gap Level 4 closes.

Level 4 — Proven

Engines operating: Knowledge + Authority + Transformation + Evidence.

Capabilities gained: every material change becomes demonstrable. The Evidence Engine (APQC-ARCH-005 §5.4; APQC-EVIDENCE-007) joins: for each change it seals a compact, canonical, post-quantum-signed Evidence Object binding what (a commitment, not a copy), when (backdate-resistant time), who and under what authority (the consumed grant path), and integrity (multi-family signatures), then links it into a tamper-evident Chain of Evidence with provable Completeness over a pre-committed population. "We migrated" becomes independently verifiable, offline, by a party who neither trusts nor contacts the producer, for the full retention horizon. This is the level regulated enterprises need: governed and proven.

What the organization still cannot do: keep it true continuously without human prompting. The estate drifts (new RSA endpoints appear, rollbacks happen, shadow systems reintroduce classical primitives), and at Level 4 nothing detects and re-transforms that drift automatically. Proof is produced, but the system is migrated-and-watched, not self-maintaining.

Entry criteria: an Evidence Engine satisfying E1–E8 (APQC-EVIDENCE-007 §10): one object per material change; authority-bound (no object for an unauthorized action); tamper-evident and post-quantum signed over a canonical encoding; provable Completeness over a pre-committed scope with a tamper-evident chain; portable, retained, survivable independent of the producer; independently verifiable offline; continuity-preserving across parameter change; and deterministically replayable. The "delete the producer" test (§6.5) must pass.

Exit criteria (build to advance to L5): operate the Governance Engine continuously — drift detection, risk evaluation, and adaptation that re-enter the lifecycle without human prompting, judging Evidence against Authority over the whole population and closing the loop.

Typical failure modes at this level: treating transformation as terminal (the loop never closes, drift accrues invisibly until the next audit); vendor-locked or online-only "evidence" that fails the offline/portability tests and is really a log with better marketing (§12.1–12.2); silent completeness gaps where no population was pre-committed (§12.3); evidence bound to identity but not authority — "valid and meaningless" (§12.5).

Worked assessment. Sentinel Defense Systems operates all four engines: a live Knowledge Graph, a rooted Authority Engine, a least-exposure Transformation Engine, and an Evidence Engine emitting authority-bound, chained, offline-verifiable objects with completeness proven against a pre-committed population. An insurer verified a conversion set on an air-gapped laptop years after the fact. But drift detection is a quarterly manual sweep; nothing re-enters the lifecycle unattended. Engines operating: Knowledge + Authority + Transformation + Evidence. Level: 4 — Proven. Everything is provable; nothing is yet continuous.

Level 5 — Autonomous

Engines operating: all five, with Governance running continuously.

Capabilities gained: the estate is operated, not migrated. The Governance Engine (APQC-ARCH-005 §5.5) runs continuously: it reads all three graphs, replays Evidence against Authority over the whole population to prove no action exceeded its authority, detects drift against the post-transformation baseline, evaluates risk, and emits a re-entry signal that reopens the lifecycle — the Knowledge Engine ingests the new asset, the Authority Engine derives (or declines) a grant to re-transform, and the loop turns again. Conversion runs unattended within authority, with proof and governance as invariants. This is the steady state the discipline targets: no terminal state, no migrate-and-forget.

What the organization still cannot do: nothing further on this ladder — Level 5 is the steady state, not a lack. Autonomy here is bounded, never absolute: it never relaxes the Level-2 fail-closed authority invariant or the Level-4 evidence-per-change invariant (APQC-CORE-001 P2, P1; P3). A Level-5 system did not escape governance; it made governance continuous.

Entry criteria: a Governance Engine that (a) proves compliance against the Authority Graph rather than narrating it; (b) writes no graph and performs no change (it cannot self-attest); (c) detects reintroduced classical primitives and emits a re-entry signal that reopens the loop (APQC-ARCH-005 C9); and (d) covers the whole population eventually. Because Governance consumes only the graphs and public parameters, an external party can run an equivalent pass — independent verification applied to oversight.

Typical failure modes at this level: governance-as-opinion (findings that assert compliance instead of proving it against Authority); governance fused into action (an engine that judges itself is self-attesting, not governed); a loop that silently terminates ("done"); autonomy that quietly relaxes an invariant under operational pressure — the failure the model forbids by keeping P1/P2 invariant from their introduction upward.

Worked assessment. Aurora Federal Cloud runs all five engines continuously. Governance replays the Evidence Graph against the Authority Graph across the entire population on a rolling basis, confirming every converted asset traces to an unexpired grant and no object bears a freeze-window timestamp. When sensing reports a new RSA-2048 endpoint stood up overnight, Governance raises a finding and emits a re-entry signal; Knowledge ingests it, Authority derives a scoped grant, Transformation re-converts, Evidence proves it — all unattended, all within authority. An external auditor runs an independent governance pass from the graphs alone and reaches the same finding. Engines operating: all five, Governance continuous. Level: 5 — Autonomous.

4. Using the model

• Assessment is objective. Enumerate the operating engines; the level is the count of consecutive engines present starting from Knowledge. Not the total count — the count of the unbroken prefix Knowledge → Authority → Transformation → Evidence → continuous Governance.

• A missing lower engine caps the level, regardless of higher engines. This is the model's most important rule and the one most often violated. An organization with a Transformation Engine but no Authority Engine is not Level 3 — it is ungoverned automation, the single most dangerous failure the architecture exists to prevent (APQC-ARCH-005 §5.3): fast, autonomous, unbounded change with no fail-closed boundary. Ungoverned automation is not a maturity level at all; it is a hazard that sits below Level 1 in risk even while it superficially resembles Level 3 in capability. The same holds for Evidence without Transformation (proof of nothing), continuous Governance without Evidence (opinion, not verification), and any other gap in the prefix. You do not get credit for a higher engine while a lower one is missing; you get a hazard flag.

• Invariants hold from Level 2 up. Fail-closed authority (APQC-CORE-001 P2; APQC-AUTH-006 A5) is enforced at every level that changes anything — that is, from Level 3's first governed change, made possible by Level 2's Authority Engine. Evidence-per-change (P1; APQC-EVIDENCE-007 E1) is enforced at every level from 4 up. Autonomy (Level 5) never relaxes them; it increases the degree of unattended operation while the invariants remain fixed. A "more autonomous" system that drops an invariant has not advanced a level — it has fallen off the ladder.

• Per-workload assessment. Maturity is assessed per workload (APQC-CORE-001 §10), never as a single organizational grade. See §8.

5. Self-assessment questionnaire

An organization determines its level by answering the following yes/no diagnostics honestly, engine by engine. A "no" anywhere caps the level at the last engine for which all questions were "yes." The questions are phrased so that only a genuinely operating engine — not a claimed or planned one — earns a "yes"; each maps to an observable rubric in §6 and, ultimately, to an APQC-ARCH-005 §13 conformance test.

Knowledge Engine (gates Level 1). 1. Is there a live, continuously-sensed Knowledge Graph (not a one-time snapshot)? 2. Are duplicate observations of the same asset resolved to a single node? 3. Does every asset carry dependency edges and a computed blast radius? 4. Is coverage stated explicitly as a fraction of the estate, rather than assumed complete?

If any is "no" → Level 0. If all "yes," proceed.

Authority Engine (gates Level 2). 5. Does all authority chain to a verifiable, durable Authority Root (APQC-AUTH-006 §3)? 6. Does every grant bind Scope (bounded whitelist, no wildcards), Lifetime (mandatory expiry), and Provenance? 7. Is delegation monotonic-decreasing (a delegate never receives more than its delegator)? 8. Does the Gating Interface fail closed — an out-of-scope action produces no effect and no evidence (not "deny and log")? 9. Is revocation immediate, propagating to the whole subtree, and evidenced?

If any is "no" → Level 1. If all "yes," proceed.

Transformation Engine (gates Level 3). 10. Does the engine read the Knowledge Graph (blast radius) before planning or acting? 11. Does it simulate before touching production? 12. Is authority presented and checked at the instant of each execution, failing closed? 13. Does it execute under least exposure — the actor never reads the sensitive material it transforms?

If any is "no" → Level 2. If all "yes," proceed.

Evidence Engine (gates Level 4). 14. Does every material change emit exactly one Evidence Object (no silent gaps)? 15. Is each object authority-bound (and is no object produced for an unauthorized action)? 16. Is each object tamper-evident, post-quantum signed, and linked into a chain with provable Completeness over a pre-committed population? 17. Can a third party verify an object offline, with the producer deleted (portability/survivability)?

If any is "no" → Level 3. If all "yes," proceed.

Governance Engine (gates Level 5). 18. Does Governance run continuously (or on a cadence covering the whole population), not as a one-off? 19. Do findings prove compliance by replaying Evidence against Authority — rather than assert it? 20. Does Governance detect drift and emit a re-entry signal that actually reopens the lifecycle? 21. Is Governance strictly oversight — it writes no graph and performs no change (no self-attestation)?

If any is "no" → Level 4. If all "yes" → Level 5.

6. Per-engine assessment rubric

A "yes" in §5 is credible only if backed by observable evidence that the engine genuinely operates — not a slide, a policy document, or a roadmap. For each engine, the rubric below states what an assessor must be able to see the system do. These rubrics are the bridge from the questionnaire to the architecture's conformance tests (APQC-ARCH-005 §13); an engine that cannot demonstrate its rubric has not earned its level, whatever the org chart claims.

Knowledge Engine — observable evidence it operates: - Point at a changing graph: assets appear and disappear as the estate moves (proves continuous sensing, not a snapshot). - Query one asset and receive its dependency edges and a concrete blast radius ("rotating this restarts these three services; the cert must be reissued first"). - Ask for coverage and receive a number with a named boundary, not "we think we have it all." - Show two systems reporting the same key and confirm it resolves to one node (deduplication).

Authority Engine — observable evidence it operates (maps to APQC-ARCH-005 C2, C3): - Attempt an out-of-scope action and observe nothing happens and nothing is recorded — not a denial log (C3, the load-bearing test). - Present a grant and walk its provenance to the Root, offline (APQC-AUTH-006 CT-A2). - Attempt to issue an unexpiring or wildcard grant and observe it rejected (CT-A3). - Attempt to write the Authority Graph from the Transformation Engine and observe it impossible by construction, not merely disallowed (C2). - Revoke a mid-chain node and confirm its whole subtree fails closed while siblings are unaffected (CT-A6a).

Transformation Engine — observable evidence it operates (maps to C4, C8): - Stale the Knowledge Graph for a target and observe the engine refuse to act blind (C4). - Watch a simulation predict a failure before production is touched. - Audit an execution path for a sensitive asset and confirm the worker never read the key it converted (C8). - Observe a change staged and rolled back cleanly.

Evidence Engine — observable evidence it operates (maps to C5, C6, C7): - Execute N changes; confirm N objects, a contiguous chain, and no silent gap (C5); remove one and confirm a named missing asset is reported (APQC-EVIDENCE-007 CT-E1a). - Attempt to seal an object for an unauthorized action and observe it is not produced (C6, CT-E2a). - Disconnect the producer entirely and confirm a third party still verifies an object offline (C7, the "delete the producer" test). - Flip one bit of a bound field and confirm a signature fails (CT-E3).

Governance Engine — observable evidence it operates (maps to C9): - Inject drift (reintroduce a classical primitive) and confirm detection and a re-entry signal that reopens the lifecycle (C9); confirm the system does not treat transformation as terminal. - Read a finding and confirm it cites the replayed Evidence-vs-Authority result, not a narrative assertion. - Confirm Governance writes no graph and executes no change (it is topologically incapable of self-attestation). - Have an external party run an independent governance pass from the graphs alone and reach the same finding.

7. Anti-patterns

Each anti-pattern below is a common way an organization appears more mature than it is. Naming them is normative to this model's purpose: an assessor MUST test for them, because each one, if uncaught, inflates a level and defeats the objectivity the model exists to provide.

• Level-skipping. Claiming Level 3 or 4 while a lower engine is absent or degraded. The most common form is deploying automation and evidence tooling on top of a Knowledge Graph with no dependency edges or a "permission flag" masquerading as an Authority Engine. A level is a consecutive prefix from Knowledge (§4); you cannot skip a rung. Higher engines built on a missing lower one do not raise the level — they raise the risk.

• Ungoverned automation (Transformation without Authority). The single most dangerous anti-pattern: a fast, autonomous Transformation Engine with no fail-closed Gating Interface — precisely the "automated scripting without an authority model" that APQC-CORE-001 §3 declares explicitly not APQC. It looks like Level 3 (it changes things at machine scale) but it is not a level at all — it is a hazard that sits below Level 1, because an ungoverned automaton can exceed its authority across an entire estate at machine speed with nothing to check it. An assessor who finds this MUST flag it as a hazard, not score it.

• Inventory theater. A polished discovery dashboard that lacks dependency edges, blast radius, or a stated coverage figure — the appearance of Knowledge with none of its decision-supporting substance. It fails the Knowledge rubric (§6) because it cannot tell a would-be Transformation Engine what a change will break. Inventory theater is a Level-0 estate wearing a Level-1 costume.

• Proof-less transformation. Governed change at machine scale that emits logs, not Evidence Objects — a genuine Level 3 mistaken by its operators for Level 4. It fails offline verification, cannot prove completeness against a pre-committed population, and produces artifacts that die with the system (APQC-EVIDENCE-007 §2, §12). "We are audit-ready" here means "trust our logs," which is exactly the unprovable posture the discipline rejects (APQC-CORE-001 §1).

• Governance theater (opinion instead of verification). A "continuous compliance" function whose findings assert that everything is fine rather than prove it by replaying Evidence against Authority. It fails the Governance rubric (§6) and does not qualify for Level 5, because self-attesting oversight is not oversight (APQC-ARCH-005 §4).

• Invariant relaxation under pressure. Quietly loosening fail-closed authority (P2) or evidence-per-change (P1) to hit a deadline or a throughput target, while still claiming the level those invariants define. This is the failure the model forbids by holding the invariants fixed from their introduction upward (§4): a system that drops an invariant has not become "more efficient at its level" — it has fallen below it.

8. Per-workload maturity

Maturity is assessed per workload (APQC-CORE-001 §10), never as one organizational grade. The five engines are workload-general (APQC-ARCH-005 §8), but an organization stands them up for different workloads at different times, so its maturity is a profile across workloads, not a scalar. An organization may be Level 5 for Post-Quantum Conversion and Level 1 for Identity — because it built and matured the PQC workload first and has only begun to discover its identity estate.

Why per-workload and not per-organization. Each workload has its own estate, its own transformation semantics, and its own Knowledge, Authority, and Evidence graphs scoped to that estate. A mature PQC Authority Graph says nothing about whether an Identity Authority Graph exists. Averaging the two into a single "the org is Level 3" number would hide exactly the gap an assessor most needs to see: the workload where an engine is missing and therefore where the next investment belongs. A single organizational grade is an inflation vector; a profile is a map.

Worked multi-workload profile. Vantage Financial assessed across four workloads:

Read the profile as a work plan. Vantage's next investments are unambiguous and workload-specific: for Identity, build the Authority Engine (its cap is a missing Authority Root); for Secrets, build the Evidence Engine (governed transformation exists, proof does not); for PKI, operate Governance continuously (all four lower engines are present). Note two things the profile makes visible that an organizational average would hide: (1) Vantage is genuinely autonomous somewhere, which proves the capability exists and can be templated onto other workloads; and (2) Identity, at Level 1, is doing manual, ungoverned change today — a hazard to prioritize, not a comfort. A single "Vantage is Level 3-ish" grade would have erased both signals.

9. How to advance one level — playbooks

Advancement is always the same shape: build the next engine, and prove it operates against its §6 rubric. Below is a concise playbook per transition. Each names the engine to stand up, the invariant it must satisfy, and the observable proof that the level is genuinely reached.

0 → 1 (stand up the Knowledge Engine). Deploy continuous estate sensing (hosts, network taps, cloud APIs, HSM interfaces) feeding a convergent, deduplicated graph. Add dependency resolution and blast-radius annotation — these are what distinguish a Knowledge Graph from a generic inventory. State coverage as a number. Proof of arrival: the graph changes as the estate changes; any asset returns dependency edges, blast radius, and a coverage figure. Do not declare Level 1 on a one-time spreadsheet (inventory theater, §7).

1 → 2 (stand up the Authority Engine). Establish a verifiable, durable, non-silently-replaceable Authority Root. Capture human intent and derive scoped, time-bounded, provably-delegated grants (no wildcards, no standing authority). Implement monotonic-decreasing delegation and immediate, propagating, evidenced revocation. The one test that matters: make the Gating Interface genuinely fail closed — an out-of-scope action produces no effect and no evidence (APQC-ARCH-005 C3). Proof of arrival: an out-of-scope attempt does nothing and records nothing; provenance walks to the Root offline; a mid-chain revocation collapses its subtree. Do not ship a permission table and call it authority (§7).

2 → 3 (stand up the Transformation Engine). Build planning, simulation, execution, and rollback that read the Knowledge Graph and are gated by the Authority Graph at planning and at every execution instant, under least exposure. Proof of arrival: the engine refuses to act on a staled Knowledge view (C4); simulation predicts failures pre-production; the worker never reads the material it converts (C8); changes stage and reverse. Do not connect an executor to the estate without the Gating Interface in the path — that is ungoverned automation, a hazard, not Level 3 (§4, §7).

3 → 4 (stand up the Evidence Engine). Emit one authority-bound, tamper-evident, post-quantum-signed Evidence Object per material change; link objects into a chain; commit the target population before execution so completeness is provable; ensure offline, producer-independent verification. Proof of arrival: N changes yield N objects with no silent gap; removing one names the missing asset (CT-E1a); an unauthorized action yields no object (CT-E2a); a third party verifies offline with the producer deleted (C7). Do not accept logs as evidence (proof-less transformation, §7).

4 → 5 (operate the Governance Engine continuously). Run continuous (or whole-population-cadence) governance that replays Evidence against Authority to prove no action exceeded its authority, detects drift against the post-transformation baseline, and emits a re-entry signal that reopens the lifecycle — while writing no graph and executing no change. Proof of arrival: injected drift is detected and re-converted unattended within authority (C9); findings cite replayed proof, not narrative; an external party runs an equivalent governance pass from the graphs alone. Do not let the loop terminate or let governance self-attest (§7). Throughout, the Level-2 and Level-4 invariants remain fixed — autonomy is the reward for keeping them, never a license to relax them (P3).

10. Not In Scope

This specification does not define: scoring rubrics for specific tools; vendor certifications; cryptographic algorithms; or workload-specific assessment checklists. It defines maturity as engine adoption — nothing more, nothing subjective. The per-engine rubrics of §6 and the questionnaire of §5 assess whether an engine genuinely operates against its architectural role and conformance tests (APQC-ARCH-005 §13); they are not tool scorecards, product benchmarks, or workload-specific technical checklists, which remain out of scope and belong, respectively, to the implementer, the market, and each workload's own specification. What is normative here is the ladder, the prefix rule (a missing lower engine caps the level), the from-Level-2 invariants, and per-workload assessment — the objective, checkable core — and nothing beyond it.