The Agentic Post-Quantum Conversion Conceptual Model

The shared mental model of the discipline: the abstractions, their relationships, and the invariants that hold across all of them — independent of any implementation.

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

This is the what of the discipline — the conceptual framework an analyst can redraw in their own report. It contains no products, no APIs, no vendor names, and no implementation detail. It defines the objects APQC reasons about and how they relate. How these concepts are realized is APQC-ARCH-005 and APQC-REFERENCE-010.

RFC 2119 keywords apply where used.

0. Front Matter

0.1 Normative References

  • APQC-CORE-001 — The APQC Constitution.

0.2 Informative References

  • APQC-PROBLEM-002 — Problem Definition.
  • APQC-LIFECYCLE-004 (operationalizes this model), APQC-ARCH-005, APQC-AUTH-006, APQC-EVIDENCE-007.

0.4 Conformance Dependencies

  • Depends on: APQC-CORE-001, APQC-PROBLEM-002.
  • Referenced by: APQC-LIFECYCLE-004, APQC-ARCH-005, APQC-AUTH-006, APQC-EVIDENCE-007, APQC-MATURITY-008.

1. Purpose

The Problem Definition (APQC-PROBLEM-002) establishes that cryptographic conversion must be agentic, governed, and proven. This document gives the discipline a single shared conceptual model: the set of abstractions those three properties require, and the flow that connects them. Everything downstream — lifecycle, architecture, authority, evidence, maturity — is an elaboration of this model.

A conceptual model earns its place by making a field discussable independently of its implementations. Before this document, an analyst comparing vendors, an auditor scoping a review, or a regulator drafting guidance had no common set of nouns and no shared diagram; each reconstructed the field from a product's marketing. The purpose here is to supply nouns and a diagram any party can adopt without adopting anyone's product — so that "did this system discover, understand, authorize, plan, execute, verify, prove, and govern?" means the same thing to a competitor, an analyst, and a court. The model is deliberately small: nine abstractions, three graphs, three invariants. Its value is not comprehensiveness but agreement.

1.1 How to read this document

Section 2 gives the overview and the canonical diagram — the figure an analyst is invited to redraw. Section 3 develops each of the nine core abstractions: a precise definition, its conceptual inputs and outputs, a worked illustration, and its relationship to the abstractions on either side. Section 4 develops the three-graph triad and the categorical-difference argument — why three graphs and not one, and what conflation hides. Section 5 develops the three invariants as cross-cutting conditions. Section 6 traces one transformation end-to-end. Section 7 states what in the model is state, action, and oversight. Section 8 relates the model to the lifecycle. Section 9 is Not In Scope.

Throughout, terms in bold are defined in APQC-GLOSSARY-000 and used here exactly as defined there; this document introduces no new vocabulary, only structure over the existing vocabulary.

2. Conceptual overview

APQC reasons about a cryptographic estate as a set of assets that are continuously sensed, organized into three linked graphs — a Knowledge Graph of what exists, an Authority Graph of what may be done, and an Evidence Graph of what has been proven — from which plans are derived, executed, and proven, under continuous governance, in a loop that never terminates.

        Cryptographic Estate (Assets)
                    │
                    ▼
               Discovery  ◄─────────────┐  (continuous sensing)
                    │                   │
                    ▼                   │
        Cryptographic Knowledge Graph   │
                    │                   │
                    ▼                   │
             Authority Graph            │
                    │                   │
                    ▼                   │
                Planning                │
                    │                   │
                    ▼                   │
                Execution               │
                    │                   │
                    ▼                   │
              Evidence Graph            │
                    │                   │
                    ▼                   │
                Governance              │
                    │                   │
                    ▼                   │
           Continuous Operation ────────┘

The three graphs — Knowledge (what is known), Authority (what is permitted), and Evidence (what is proven) — are the core this model builds; every stage advances at least one. A transformation missing any one is, respectively, blind, ungoverned, or unprovable.

Three invariants (Section 5) hold at every arrow: proof, authority, and least exposure.

The diagram above is the redraw-able artifact — the single figure the whole corpus points at. Read top to bottom it is a pipeline: an estate is sensed, its truth structured, permission derived over that truth, a plan formed within that permission, the plan executed, each execution proven, the whole governed against the permission, and the estate watched. Read as a whole it is a loop: the closing edge from Continuous Operation back to Discovery makes the figure a cycle rather than a line, and it is that edge — not any single stage — that distinguishes an operating model from a project (APQC-CORE-001 P6). The rest of this document elaborates this one figure; nothing in it introduces a stage the figure does not already contain.

3. Core abstractions

The model has nine core abstractions, in the order the diagram traverses them. Each is developed identically: a definition, its conceptual inputs and outputs (what it consumes and produces at the level of abstraction — never a data format), a worked illustration (kept light, since APQC-LIFECYCLE-004 carries the fully-developed example), and its relationships to the abstractions immediately upstream and downstream. Where an abstraction is fully specified by a dedicated document, that document is named; this section gives the conceptual treatment only.

3.1 The Cryptographic Estate

Definition. The estate is the complete population of an organization's cryptographic assets. An asset is any concrete use of a cryptographic primitive — a key, a certificate, a signing or key-exchange operation, a protocol endpoint, a library dependency, a hardware slot, or a stored secret. The estate is unbounded in practice, distributed across systems, and — critically — changing continuously. The model treats the estate as a live population, never as a fixed list.

Inputs / outputs. The estate has no inputs in the model; it is the given the discipline exists to operate on. Its only "output" is the surface Discovery senses. The estate is prior to the discipline, not produced by it.

Worked illustration. An enterprise's estate includes thousands of TLS endpoints, code-signing keys held in hardware, secrets embedded in configuration, certificate chains rooted in internal and external authorities, and library dependencies that negotiate primitives at runtime. No inventory of it is ever both complete and current: the moment one is written, a new deployment changes it.

Relationships. The estate is upstream of everything and downstream of nothing — the territory; the Knowledge Graph (§3.3) is the map. The property it carries forward is liveness: because the population changes continuously, Discovery (§3.2) cannot be a one-time act and the loop (§3.9) cannot terminate. Every later abstraction inherits its non-finality from this one fact about the estate.

3.2 Discovery

Definition. Discovery is the continuous sensing function that observes the estate and reports assets. Discovery is not an event; it is an always-on process, because §3.1's population changes. Discovery produces observations; it does not itself change anything and holds no authority to do so.

Inputs / outputs. Input: observe access to the estate, and the bound of relevance set by the authorized outcome. Output: raw observations, each carrying provenance (where and when observed, by what sensor) and — indispensably — a stated coverage: what fraction of the relevant population was observed and what was not. Discovery's honest output is never "here is the estate"; it is "here is what was observed and what could not be."

Worked illustration. Sensing observes endpoints from configuration, from public certificate transparency records, and from live probes; it reports that 1,223 of an estimated 1,240 endpoints were characterized and 17 timed out behind a firewall — reporting the 17 as an explicit gap, not rounding them away.

Relationships. Discovery sits between the estate (§3.1) and the Knowledge Graph (§3.3), and the boundary on each side is load-bearing. Upstream it is strictly read — it senses reality but never touches it, the first appearance of the least-exposure and authority invariants (§5). Downstream it hands raw observations to the Knowledge Graph, not a finished map: population, not structure. Keeping observation separate from structuring lets a later error be attributed to sensing rather than to interpretation.

3.3 The Cryptographic Knowledge Graph

Definition. Observations are organized into the Knowledge Graph: the canonical, deduplicated representation of what cryptography exists and what depends on it. Nodes are assets; edges are dependencies (this service uses that certificate; this certificate chains to that root; this protocol negotiates that primitive). The Knowledge Graph answers "what do we have, and what breaks if we change it." It is the map.

Inputs / outputs. Input: the raw observations from Discovery, with their coverage statement. Output: a structured graph in which each asset is classified and each dependency is an explicit edge, so that for any asset the blast radius — the set of things that break if it changes — is enumerable rather than guessed. An observation that cannot be classified is not dropped; it is carried as an explicit unclassified node, so the map never silently omits its own uncertainty.

Worked illustration. Structuring turns a flat list of endpoints into a graph that reveals a subset fronting a partner whose client library rejects any non-classical certificate (a dependency edge making those endpoints non-convertible to a pure post-quantum primitive without breaking the partner), and a single signing key with hundreds of downstream artifacts validated against it (a blast radius turning "rotate the key" into "invalidate hundreds of artifacts unless a transitional path is used").

Relationships. The Knowledge Graph is downstream of Discovery (which gives it population) and upstream of both the Authority Graph (§3.4) and Planning (§3.5). Its relationship to the Authority Graph is the model's central structural fact, developed in §4: Knowledge describes reality, Authority describes permission, and the two must never be conflated. Its relationship to Planning is that blast radius computed here caps every plan's quality: a plan is no safer than the dependency map it sequences against.

3.4 The Authority Graph

Definition. Parallel to the Knowledge Graph is the Authority Graph: the representation of what may be done, by whom, to what, and within what bounds. Nodes are authorities (scoped, delegable, time-bounded, revocable rights); edges are delegations from a trust anchor down to the entity that will act. The Authority Graph answers "who is permitted to change this, and to what extent." It is the permission structure. (Fully specified in APQC-AUTH-006.)

Inputs / outputs. Input: the authorized outcome (the root from which all authority descends) and the Knowledge Graph (so grants bind to specific assets, not abstractions). Output: a directed acyclic structure of grants, each scoped to a class of action on a class of asset, each time-bounded and revocable, each traceable up a delegation chain to a verifiable root. A conceptually crucial output is the grant that does not exist: for an action the Knowledge Graph proves would break a dependency, the Authority Graph declines to grant authority at all, making the harmful action impossible by construction rather than merely discouraged.

Worked illustration. From an authorized outcome, the Authority Graph derives a conversion grant scoped to the convertible endpoints, time-bounded to the intended window and revocable by a named party — and issues no grant for the partner-locked endpoints, so no agent can even attempt to convert them.

Relationships. The Authority Graph is downstream of the Knowledge Graph (which is why authority is assigned after understanding — you cannot scope a grant to "the convertible endpoints" until you know which are convertible) and upstream of Planning (§3.5) and Execution (§3.6). Its relationship to Knowledge is intersection: an action is conceivable only where a Knowledge asset and an Authority grant overlap (§4.4). Its relationship to Governance (§3.8) is that Governance later joins this graph against Evidence to prove no action exceeded its grant — possible only because the Authority Graph is maintained separately from the record of what was done. The two graphs must never be conflated: Knowledge describes reality, Authority describes permission — the distinction §4 shows makes the discipline's most dangerous failure detectable.

3.5 Planning

Definition. Planning consumes both graphs and produces a plan: for each asset requiring change, the target state, the transformation path (direct or transitional/hybrid), the sequence relative to dependencies, and the reversal path. A plan is a proposal bounded by the Authority Graph — it may only propose actions for which authority exists or can be delegated.

Inputs / outputs. Input: the Knowledge Graph (what exists and depends on what) and the Authority Graph (what is permitted). Output: an ordered set of proposed actions, each bounded by an existing grant, respecting dependency order, and carrying a reversal path. Planning reserves the grants it will consume without yet consuming them — it reasons about a change without making it, so that reasoning about a plan is never mistaken for permission to execute it.

Worked illustration. Because the signing key has many dependents, Planning does not rotate it in place; it schedules a transitional dual-path so old verifiers keep working while new ones gain post-quantum assurance, and sequences low-blast-radius changes first — accumulating evidence and confidence before touching the assets whose failure would be most costly.

Relationships. Planning is downstream of both graphs and upstream of Execution (§3.6). It is where the two graphs are first used together: Knowledge tells Planning what breaks if things move in the wrong order; Authority tells Planning which moves it may even propose. A plan proposing an action for which no grant exists is not merely unwise — it is unexecutable, and its presence signals that Planning ignored the Authority Graph.

3.6 Execution

Definition. Execution carries out a plan: it performs the conversion of an asset from a classical to a post-quantum (or hybrid) primitive, in the live estate. Execution is the only function that changes reality, and it may act only within the authority the plan carries. Execution operates under least exposure (Section 5): it transforms sensitive material without needing to read it.

Inputs / outputs. Input: the plan, the reserved grants, and (where required) the resolution of any predicted failure before reality is touched. Output: the transformed assets, the Knowledge Graph advanced to its actual post-change state, and — for each change — a raw execution record bound to the specific grant it consumed. Authority is checked at the moment of each action, not at plan-approval time, because a grant can expire or be revoked between planning and acting.

Worked illustration. An execution agent presents its reserved grant, performs one endpoint's certificate change, and emits a per-change record binding which endpoint, from which primitive to which, at what time, under which grant. Reaching an asset whose grant is not yet valid — because a required precondition is unconfirmed — the action fails closed, changes nothing, and produces no record, exactly as the authority invariant requires. Sensitive key material is generated and used inside protected hardware; it never enters the agent orchestrating the change.

Relationships. Execution is the hinge of the model: everything before it is state and proposal, it is the single point of action, and everything after it is proof and oversight (see §7). Upstream it consumes a plan bounded by authority; downstream its raw records are the material the Evidence Graph seals into portable proof, and its actual post-change state is what Verification independently confirms. Being the only abstraction that mutates reality, it is the only one where the invariants are tested against an adversary rather than a checklist.

3.7 The Evidence Graph

Definition. Every material change produces a link in the Evidence Graph: a portable, independently-verifiable commitment binding what changed, when, and under whose authority. The Evidence Graph is not a log of execution; it is a set of proofs about execution that a third party can verify without trusting the actor. The chain is the memory of the discipline — the thing that makes "converted" demonstrable rather than asserted. (Fully specified in APQC-EVIDENCE-007.)

Inputs / outputs. Input: the raw execution records (what was done), their independent verification (that it occurred as intended), and the authority under which they occurred. Output: durable proof artifacts, each committing to (not exposing) the change, each cross-linked to the asset it changed (into Knowledge) and the grant that permitted it (into Authority), each ordered into a tamper-evident chain, each verifiable offline for the full retention horizon. No proof is produced for an action that lacked authority — an unauthorized attempt yields no effect and no evidence.

Worked illustration. For each converted asset, a compact commitment binds asset X converted from primitive P to primitive Q, verified at time T, under grant G traceable to the authorized outcome. Years later, a party who was not present and does not trust the actor can confirm the change happened, when, and under whose authority — without contacting the organization or any tool vendor.

Relationships. The Evidence Graph is downstream of Execution and Verification, and is the only place all three graphs meet: each proof cross-links up to Authority and across to Knowledge at the versions in force when the change occurred (§4.5). This tri-linkage is what makes Governance's join possible and a past transformation replay-able. Its relationship to Governance (§3.8) is one of material: Governance reasons over Evidence joined against Authority; it adds to neither.

3.8 Governance

Definition. Governance is the continuous function that holds execution accountable to the Authority Graph: it confirms that every action stayed within its granted authority and surfaces any that did not. Where Execution is bounded by authority before it acts, Governance verifies that boundary after, over the whole population, continuously. Governance is how the Authority Graph's promises become auditable facts.

Inputs / outputs. Input: the three graphs. Output: a population-wide finding — a confirmation that every recorded action consumed a valid, scoped, unexpired grant, together with the exact exceptions (deferrals, pending items, reversions), each carried with an owner and, for deferrals, a reopen condition. Governance reads; it does not write authority. If Governance ever broadened a grant to make an action retroactively legitimate, it would have stopped judging and started permitting — a category error, not merely a policy violation.

Worked illustration. Governance joins Evidence against Authority and produces the sentence an auditor actually wants: over the in-scope population, so many assets converted under valid authority, so many deferred by policy (with a reopen trigger), so many pending discovery, and zero actions outside a grant.

Relationships. Governance is downstream of the Evidence Graph and upstream of Continuous Operation (§3.9). Its defining relationship is to the Authority Graph, which it holds constant and judges against, never mutates. This is precisely why the model keeps three separate graphs: Governance's central question — "did what happened stay inside what was permitted?" — is a join between two independently-maintained graphs, and a join is meaningful only when its sides were maintained separately (§4.3).

3.9 Continuous Operation

Definition. The output of Governance and monitoring feeds back into Discovery: drift (the reappearance of classical primitives) re-enters the estate as new observations, re-opening the loop. Continuous Operation is the recognition that the discipline has no terminal state. Cryptographic infrastructure is never "done"; it is operated. This closing edge is what distinguishes an operating model from a project.

Inputs / outputs. Input: the live estate and the record of what should be true (the Knowledge and Evidence Graphs). Output: characterized drift detections — and, on intervals where nothing drifted, receipts proving the estate was checked and found conformant, so "clean" is a proven fact rather than an absence of news. These outputs re-enter Discovery as fresh observations, closing the loop.

Worked illustration. Weeks after a conversion, monitoring detects a newly-provisioned component — spawned from an old template — serving a classical primitive inside the converted scope; drift has reappeared. It also notices that a previously-blocking precondition has since been satisfied, reopening a deferred set of assets. Both re-enter Discovery as new observations, and a new pass begins.

Relationships. Continuous Operation is the closing edge of the loop: downstream of Governance and upstream — via the loop — of Discovery. Its relationship to the estate (§3.1) completes the circle the estate opened: because the estate is a live population, the discipline that operates it must never stop sensing. This edge turns nine abstractions in a line into a cycle, and is the structural expression of the estate's liveness.

4. The three-graph triad

The three abstractions §3.3, §3.4, and §3.7 are not merely three of the nine; they are the intellectual core the other six exist to build and maintain. Every stage advances at least one, and the discipline's guarantees are stated in terms of them.

  • Knowledge Graph — what is known (reality).
  • Authority Graph — what is permitted (delegation).
  • Evidence Graph — what is proven (verifiable history).

Every transformation maintains all three. One missing is, respectively, blind (no Knowledge — changing what it does not understand), ungoverned (no Authority — changing what it was never permitted to), or unprovable (no Evidence — unable to demonstrate what it changed). These three failures are why the triad, not any single graph, is the core.

4.1 Why three graphs and not one

A naive design collapses all three into one database of "facts about the estate": this asset exists, someone was allowed to change it, here is the record that it changed. The discipline refuses this collapse — the single most important structural decision in the model — because the three graphs fail categorically differently, and a single store cannot represent three independent failure modes:

  • The Knowledge Graph can be wrong — stale, incomplete, misclassified — without any action being illegitimate. A perfectly-authorized, perfectly-proven action can be performed on a misunderstood asset; the defect is in reality's map, not in permission or proof.
  • The Authority Graph can be over-broad — granting more than intended — while Knowledge is correct and Evidence is complete. Every action understood, every action proven, and yet an action permitted that never should have been.
  • The Evidence Graph can be complete — every action proven — while Authority was exceeded. The case that matters most: a transformation in which every change is faithfully, cryptographically recorded, and yet some were never authorized.

Because these failures are independent, no single store can distinguish them: in one table, the change that happened and the right to perform it are the same row — and in that arrangement the most dangerous failure becomes invisible.

4.2 The failure that conflation hides

A well-evidenced, unauthorized action.

Consider a change executed, faithfully recorded, its record verifying perfectly — but for which no valid grant ever existed. In a system that separates Authority from Evidence this is detectable: the proof cites an authority, and the join (§4.3) finds that authority resolves to no valid path at the moment the change committed. The action is exposed as illegitimate precisely because it was well-evidenced — the evidence names the authority it lacked.

In a system that conflates the two — one store, one row per change — the same action is invisible: "it happened" and "it was allowed" are asserted by the same entry, signed by the same party, at the same time. There is nothing to join against, because permission and record are one object. The system cannot tell "this change was authorized" from "this change asserts it was authorized" — the entire difference the discipline exists to make.

This is the shape of the self-authorization failure: an actor minting its own keys produces cryptographically valid signatures and zero legitimate authority (APQC-AUTH-006 §2.5). A conflated store accepts these forever; a separated triad rejects them at the join, because the cited authority resolves to no root. Keeping the graphs separate is what lets Governance ask "did execution stay inside authority?" as a real question with a checkable answer, rather than a tautology that answers itself.

4.3 The join is the point

Governance's central operation is a join between Evidence (what was done) and Authority (what was permitted): for every proven action, does a valid grant resolve for it, at the moment it committed? A join is meaningful only when its two sides were produced independently. If the process that recorded the change also asserted its own permission, the join compares a claim to itself and always succeeds. If permission is maintained by a separate structure — rooted, delegated, revocable, replayable (APQC-AUTH-006) — the join can fail, and its ability to fail is exactly its value. This is why Governance (§3.8) reads the Authority Graph and never writes it: the instant it could broaden a grant after the fact, the two sides are no longer independent and the join collapses into the §4.2 tautology. Separation of the graphs and read-only Governance are one principle at two altitudes.

4.4 The Knowledge ∕ Authority intersection

An action is conceivable only where the Knowledge Graph and the Authority Graph overlap — where an asset that exists is also reachable by a grant that permits acting on it. Authority over an asset that does not exist is inert; an asset over which no authority is held is untouchable. Only their intersection is actionable.

     KNOWLEDGE GRAPH                 AUTHORITY GRAPH
     (what EXISTS)                   (what is PERMITTED)
   ┌───────────────────┐         ┌───────────────────┐
   │                    │         │                    │
   │        ┌───────────┼─────────┼───────────┐        │
   │   A    │   INTERSECTION = the ACTIONABLE  │   B    │
   │ known, │   set: assets that EXIST and are │ permit-│
   │ NO     │   reachable by a PERMITTING grant│ ted,   │
   │ grant  └───────────┼─────────┼───────────┘ absent  │
   │  → UNTOUCHABLE     │         │      → INERT        │
   └───────────────────┘         └───────────────────┘

  Region A (known, unpermitted) — the SAFE default: a partner-locked endpoint
    the org understands but is deliberately granted NO authority to change sits
    here, impossible-to-change by construction, not by policy.
  Region B (permitted, unknown) — a grant over an asset Discovery never found:
    harmless while absent, a latent widening the moment it appears. This is why
    grants scope to bounded CLASSES and why drift re-enters Discovery — so B
    cannot silently become actionable unobserved.

The intersection is where Planning (§3.5) proposes and Execution (§3.6) acts. Everything outside it is, by construction, not conceivable as an action — the model's most important safety property expressed geometrically: the safe default is the region that is known but not permitted, and the discipline works to keep that region deliberate rather than accidental.

The Evidence Graph is where the triad closes. Each proof is not a free-standing artifact; it is cross-linked into the other two graphs — up to the Authority Graph (the grant it cites) and across to the Knowledge Graph (the asset it changed) — at the versions in force when the change occurred. The Evidence Object is the only place all three graphs meet.

   KNOWLEDGE GRAPH                        AUTHORITY GRAPH
   (what is known)                        (what is permitted)
        │                                        │
     asset_ref  (across: the asset changed)  authority_ref (up: the grant used)
        │                                        │
        ▼                                        ▼
   ┌──────────────────────────────────────────────────────┐
   │                    EVIDENCE GRAPH                      │
   │                  (what is proven)                      │
   │                                                        │
   │   EO_1 ◄──prev── EO_2 ◄──prev── EO_3 ◄──prev── ...     │  chain edges
   │    │  ▲           │  ▲           │  ▲                   │  (order, in time)
   │    │  └authority  │  └authority  │  └authority          │
   │    └asset         └asset         └asset                 │
   └──────────────────────────────────────────────────────┘

   Three kinds of edge:
   • chain edges (prev)       — order and completeness WITHIN evidence
   • authority edges (up)     — bind each proof to the RIGHT it was made under
   • knowledge edges (across) — bind each proof to the ASSET it changed

   From ONE proof a verifier traverses UP to the authority that permitted the
   act and ACROSS to the asset it changed, at the versions in force THEN. A
   proof whose authority edge resolves to no valid path is the well-evidenced-
   but-unauthorized action of §4.2 — caught HERE, at the link.

The cross-links are why the triad is a triad and not three parallel silos: the Evidence Graph binds the other two together at every proof, so the historical question "was this action, on this asset, permitted at that instant?" is answerable from the proof alone, offline, for the life of the evidence.

5. The invariants

Three properties are not stages but conditions that hold across every abstraction and every edge. Where the abstractions describe what happens, the invariants describe what must be true whenever anything happens. A stage may advance a graph but never in violation of an invariant — and an invariant violation is more severe than a failed stage output, because invariant violations are silent and cross-cutting: they do not announce themselves at one abstraction, they corrupt the guarantees of all of them.

5.1 I1 — Proof

No transition is complete until it has produced independently-verifiable evidence. This applies to every change, everywhere — not only Execution. Discovery's observations, Understanding's classifications, Authority's delegations, Planning's proposals, Verification's results, and Governance's findings each leave behind evidence a later party can check without trusting its producer. Proof makes the discipline's memory durable: a years-old transformation can still be examined because every transition sealed proof as a byproduct rather than relying on recollection. A transition that changed something but left no verifiable trace has not completed under this model; it has merely happened.

5.2 I2 — Authority

No action occurs outside the Authority Graph. An action without a supporting grant is not permitted, and — where attempted — produces no effect and no evidence. The distinction between "denied" and this — call it inconceivable — is load-bearing: a denied action leaves a trace and a foothold; an action for which no valid path exists leaves nothing an attacker can build on and nothing an auditor must sift. This is why the absence of a grant (region A of §4.4) is a safety mechanism, not a gap: the safest state of a known-but-dangerous asset is that no path reaches it, so no agent, however compromised, can even attempt the change. The invariant makes over-reach inconceivable rather than merely disallowed.

5.3 I3 — Least exposure

Sensitive material — keys, secrets, regulated data — is acted upon without being revealed to the actor. Transformation does not require exposure. This crosses the whole model, not just Execution: Discovery senses that an asset exists without reading its content; the Knowledge Graph records that a key is present without holding it; the Evidence Graph commits to a change without copying the sensitive bytes (which is why evidence is safe to hand to anyone, for decades); and Authority's provenance is verifiable without exposing the business content it governs. Least exposure lets the same artifacts serve the party who must verify a change and the confidentiality regime that must not leak it — provable and safe to disclose at once.

5.4 Why the invariants are cross-cutting

They are stated separately because they fail separately, but compose into one guarantee: every change is proven (I1), only ever within permission (I2), and never by exposing what it changed (I3). An implementation that satisfies every stage output but violates one invariant may resemble APQC and is not conformant (APQC-CORE-001 §14) — because the invariants are what an outside party actually relies on, relied on between the abstractions, at the edges, where a stage-by-stage checklist does not look.

6. The model in operation — one transformation, end to end

To show the abstractions as a working whole rather than a catalog, this section traces a single conceptual transformation — the conversion of one cryptographic asset — through the entire model, naming which graph advances and which invariants bear at each step. It is kept to one asset deliberately: the point is the flow, not the scale. (APQC-LIFECYCLE-004 develops the full, many-asset example.)

The asset: a single production signing key, currently a classical primitive, with many downstream artifacts validated against it.

  1. Estate (§3.1). The key exists in the live population — held in hardware, used by a signing pipeline, depended on by hundreds of artifacts. Nothing in the model has touched it; it is reality awaiting sensing.

  2. Discovery (§3.2) senses it. Under observe-only authority, sensing reports where it lives, that it is a classical signing primitive, and that a pipeline uses it. Graph: Knowledge (population). Invariants: I2 (no change authority), I3 (existence observed without reading the private key).

  3. Knowledge Graph (§3.3) structures it. The observation becomes a classified node; dependency resolution discovers the hundreds of downstream artifacts — the blast radius is now enumerable, and in-place rotation would invalidate every one. Graph: Knowledge (structure). Invariant: I1 (the classification is evidenced, traceable to its observation).

  4. Authority Graph (§3.4) permits it — within bounds. From the authorized outcome a grant is derived, scoped to convert this class of signing primitive, time-bounded, revocable, bound to this specific asset node. Graph: Authority. Invariant: I2 (the grant alone makes the coming action conceivable). By §4.4 the key is now in the actionable region — it both exists and is reached by a permitting grant.

  5. Planning (§3.5) sequences it — safely. Given the large blast radius, Planning proposes a transitional dual-path (old verifiers keep working; new ones gain post-quantum assurance) with a reversal path, and reserves — does not consume — the grant. Graphs: Knowledge (planned delta), Authority (reserved grant). Invariant: I1 (plan evidenced, bound to the grant).

  6. Execution (§3.6) changes reality — once, within authority, without exposure. The agent presents its reserved grant at the moment of action, effects the transitional change, and emits a raw record binding this key, primitive P to Q, time T, grant G. The new private key is generated and used inside protected hardware, never entering the agent. Had the grant expired or been revoked since Planning, the action would have failed closed, changed nothing, produced nothing. Graphs: Knowledge (actual state), Evidence (raw record). Invariants: all three.

  7. Evidence Graph (§3.7) proves it. The verified change is sealed into a portable commitment: it commits to (does not copy) the change, cross-links up to grant G and across to the key's node, chains to the prior proof, and is signed to survive a future quantum adversary and verify offline for decades. Graph: Evidence (sealed). Invariants: I1, I3.

  8. Governance (§3.8) judges it — as a join. It joins the sealed proof against Authority: does grant G resolve to a valid, scoped, unexpired, unrevoked path at time T? It does — confirmed legitimate not because the actor said so, but because the cited authority resolves independently. Had it resolved to nothing (§4.2), Governance would catch it here. Invariant: I2, verified after the fact over the population; Governance reads Authority, never writes it (§4.3).

  9. Continuous Operation (§3.9) watches it — forever. Monitoring now holds "this key should be its post-quantum primitive" as a fact to check. A rollback or template that reintroduces the classical primitive re-enters Discovery as drift and the transformation begins again for that asset; clean intervals emit receipts proving it was checked and found conformant. Graphs: Knowledge (current truth), Evidence (drift/clean receipt). The loop closes.

The single asset traversed all nine abstractions, advanced all three graphs, and honored all three invariants — and did not leave the loop. That is the model in operation: not a pipeline that ends, but a cycle a change enters and never structurally exits, because the estate it belongs to never stops changing.

7. State, action, and oversight — an explicit partition

The nine abstractions divide cleanly into three kinds, and naming the division sharpens the model. Everything is either state (a representation of how things are, may be, or have been), action (the one thing that changes reality), or oversight (a judgment about state and action). The partition is exact:

  • State — the Estate (§3.1), Knowledge Graph (§3.3), Authority Graph (§3.4), and Evidence Graph (§3.7). These represent: what exists, what is permitted, what is proven. Discovery (§3.2) and Planning (§3.5) are state-producing functions — sensing produces observed state, planning produces proposed state — but they change representations, not the estate. Nothing here alters reality.

  • Action — Execution (§3.6), alone. It is the only abstraction that mutates the estate. This isolation lets the invariants be enforced: because exactly one abstraction acts, there is exactly one place where authority must be present at the moment of effect (I2), one where sensitive material must not be exposed (I3), and one whose every output must become proof (I1). Concentrating all reality-change in one abstraction is what makes the model governable.

  • Oversight — Governance (§3.8) and Continuous Operation (§3.9). These judge and watch: Governance judges past action against permitted state (the join); Continuous Operation watches present state against proven state (drift). Neither acts on the estate; both read.

   STATE (represents)            ACTION (changes)         OVERSIGHT (judges/watches)
   ─────────────────────         ────────────────         ──────────────────────────
   Estate ................       Execution                Governance
   Discovery  (senses) ...          │                       (joins Evidence
   Knowledge Graph .......          │                        against Authority)
   Authority Graph .......    the ONLY abstraction         Continuous Operation
   Planning   (proposes) .    that mutates reality           (watches for drift)
   Evidence Graph ........

This partition makes two things obvious the linear diagram does not. First, the thinness of action: eight of the nine abstractions never touch reality; the entire safety burden concentrates on the one that does. Second, the asymmetry of oversight: oversight never changes the estate and never changes the Authority Graph — it only reads — which is exactly why the join it performs is trustworthy (§4.3). A model in which oversight could act would be one in which oversight could exonerate itself.

8. Relationship to the lifecycle

The twelve lifecycle stages of APQC-CORE-001 §6 and APQC-LIFECYCLE-004 are the operational unfolding of this model. Intent and Discovery seed §3.1–3.2; Understanding realizes §3.3; Authority Assignment realizes §3.4; Planning and Simulation realize §3.5; Execution realizes §3.6; Verification and Evidence realize §3.7; Governance realizes §3.8; Continuous Operation and Adaptation realize §3.9. The conceptual model is the shape; the lifecycle is the motion. Where this document says "Planning reserves grants," the lifecycle says how that reservation is gated, tested, and evidenced stage by stage. The two are the same discipline at two altitudes: an analyst who wants the nouns and the diagram reads this; an implementer who wants the ordered decisions and their gates reads APQC-LIFECYCLE-004.

9. Not In Scope (what this model is not)

  • It is not an architecture. It names no components, protocols, data formats, or products. Architecture is APQC-ARCH-005.
  • It is not an implementation. Where these concepts are realized by specific technology, that is APQC-REFERENCE-010.
  • It is not a maturity model. How much of this an organization has achieved is APQC-MATURITY-008.
  • It is not the lifecycle. The ordered decisions, their gates, and their per-stage conformance tests are APQC-LIFECYCLE-004; this document gives the abstractions the lifecycle moves through, not the motion itself.
  • It is not the authority or evidence specification. The formal Authority Graph (rooting, delegation math, revocation, replay) is APQC-AUTH-006; the formal Evidence Graph (Evidence Object, chain, completeness, offline verification, replay) is APQC-EVIDENCE-007. This document gives their conceptual role in the triad, not their internal structure.

It also defines no cryptographic algorithms (NIST's role), no vendor product names (APQC-REFERENCE-010), no programming languages, and no cloud providers. The model's job is singular: to give every party — competitors, analysts, auditors, customers, and automated systems reasoning about the field — the same conceptual vocabulary and the same diagram, so that the discipline can be discussed independently of who implements it. Everything in this document is meant to be redraw-able on a whiteboard from memory: nine abstractions, three graphs, three invariants, one loop.