The Agentic Post-Quantum Conversion Reference Architecture

Figure 1 — The APQC Architecture. Know, permit, act, prove; govern continuously.

How an enterprise implements the discipline: five engines, three graphs, one transformation core — the canonical architecture of agentic transformation.

Document: APQC-ARCH-005 — Reference Architecture
Status: Draft 0.1
Version: 0.1
Date: 2026-07-02
Editor / Authoring body: H33.ai, Inc.

This is the how of the discipline — the reference architecture an architect, CISO, or analyst can implement or redraw. It introduces no new concepts: it is the composition of the primitives already defined (the three graphs of APQC-MODEL-003, the Authority Model of APQC-AUTH-006, the Evidence Model of APQC-EVIDENCE-007) into a working system. It names engines, not products. The reference implementation is APQC-REFERENCE-010.

RFC 2119 keywords apply where used.

0. Front Matter

0.1 Normative References

APQC-CORE-001; APQC-GLOSSARY-000; APQC-MODEL-003; APQC-LIFECYCLE-004; APQC-AUTH-006; APQC-EVIDENCE-007.

0.2 Informative References

APQC-PROBLEM-002.

APQC-MATURITY-008 (defines maturity as engine adoption); APQC-STANDARDS-009 (maps each engine to existing standards); APQC-REFERENCE-010 (a conforming implementation).

0.4 Conformance Dependencies

Depends on: APQC-CORE-001, APQC-GLOSSARY-000, APQC-MODEL-003, APQC-LIFECYCLE-004, APQC-AUTH-006, APQC-EVIDENCE-007.
Referenced by: APQC-MATURITY-008, APQC-STANDARDS-009, APQC-REFERENCE-010.

1. Purpose

The preceding specifications establish what the discipline is and why. This document establishes how an enterprise builds it. It resolves the three graphs and the lifecycle into a small, fixed set of engines and one canonical picture, so that any organization can locate its current state, plan its next step, and recognize the architecture on sight.

The architecture is deliberately small. There are exactly five engines and exactly three graphs, no more and no fewer, because each element answers a question the discipline cannot omit and no element answers two. An architect who has internalized Figure 1 can reconstruct the entire discipline from it, the way an OSI diagram lets one reconstruct a network stack. That recognizability is a design goal, not an accident: a discipline the market can draw is a discipline the market can adopt, audit, and compare vendors against. This document therefore treats Figure 1 as canonical and immutable, and everything that follows as its elaboration.

Nothing here is a product. An engine is an architectural role — a bounded set of responsibilities with named inputs and named outputs. One product MAY implement several engines; one engine MAY be realized by several cooperating systems; an engine MAY be centralized in one process or distributed across a continent. What is normative is what each engine is responsible for and what it hands to the others, never how it is packaged. Where this document must point at a concrete build to make a role tangible, it does so only in clearly-marked informative "Reference implementation" notes that defer to APQC-REFERENCE-010.

2. The canonical architecture

The discipline is not a linear pipeline. At its center a Transformation Engine acts at the intersection of three persistent graphs — it reads the Knowledge Graph (what exists), is gated by the Authority Graph (what is permitted), and emits to the Evidence Graph (what is proven) — while a Governance Engine encloses the whole and drives continuous adaptation.

Figure 1 — The APQC Architecture (the canonical figure of the discipline)

┌──────────────────────────  ENTERPRISE ESTATE  ──────────────────────────┐
│                 keys · certs · TLS · protocols · HSMs · secrets          │
└─────────────────────────────────────┬────────────────────────────────────┘
                                       │  sense
 ╔══════════════════════════  GOVERNANCE ENGINE  ══════════════════════════╗
 ║          continuous compliance · drift · risk · adaptation               ║
 ║                                                                          ║
 ║                          ┌────────────────────┐                          ║
 ║                          │   KNOWLEDGE GRAPH   │   what is known          ║
 ║                          └─────────▲──────────┘                          ║
 ║                                    │ reads                               ║
 ║   ┌────────────────────┐           │           ┌────────────────────┐    ║
 ║   │   AUTHORITY GRAPH   │◄──gates───┼──emits──►│   EVIDENCE GRAPH    │    ║
 ║   │  what is permitted  │           │           │   what is proven    │    ║
 ║   └────────────────────┘           ▼           └────────────────────┘    ║
 ║                          ┌────────────────────┐                          ║
 ║                          │   TRANSFORMATION   │  plan · simulate ·       ║
 ║                          │       ENGINE       │  execute · roll back     ║
 ║                          └────────────────────┘                          ║
 ║                                                                          ║
 ╚═════════════════════════════════════╤════════════════════════════════════╝
                                        │  continuous adaptation
                                        └──────────────►  re-enter

The four components at the core — three graphs plus the Transformation Engine — are the whole discipline in one image: know, permit, act, prove; govern continuously. Everything else in this document elaborates this figure.

Read the figure in three passes. First, the containment: the Governance Engine is the outer wall; nothing in the discipline runs outside its oversight. Second, the cross: the Transformation Engine sits at the center of a cross whose arms are the three graphs — it reads up from Knowledge, is gated left by Authority, and emits right to Evidence. Third, the loop: the estate is sensed at the top and the adaptation signal re-enters at the bottom, so the picture describes a cycle with no terminal state, not a flow with an end. Those three readings — containment, cross, loop — are the mnemonic; an architect who holds them can regenerate the figure from memory.

3. The core: three graphs and one engine

Knowledge Graph (APQC-MODEL-003 §3.3) — the persistent truth of the estate. The Transformation Engine reads it; it never acts without knowing blast radius.
Authority Graph (APQC-AUTH-006) — the persistent structure of permission. It gates the Transformation Engine: no action occurs without a valid Root-to-agent path. This is the discipline's fail-closed boundary.
Evidence Graph (APQC-EVIDENCE-007) — the persistent, verifiable history. The Transformation Engine emits to it on every material change.
Transformation Engine — the only component that changes reality, acting at the intersection under least exposure.

The three graphs are state; the Transformation Engine is action; Governance is oversight. Separating state, action, and oversight is what makes the architecture governable.

The three graphs are persistent and the Transformation Engine is transient: the graphs outlive any single transformation, any single agent, and — for Evidence, per APQC-EVIDENCE-007 §6.5 — the producer itself, whereas the Transformation Engine holds no durable state of its own beyond what it has committed to the graphs. This asymmetry is deliberate. If the Transformation Engine crashes mid-plan, nothing is lost that matters: the Knowledge Graph still describes reality, the Authority Graph still describes permission, the Evidence Graph still records what was proven up to the last committed change, and a fresh Transformation Engine can resume from the graphs. State that survives, action that does not — this is the source of the architecture's recoverability.

4. State, action, and oversight

The single most important structural claim of this architecture is that it separates three concerns that undisciplined automation fuses:

State — the three graphs. They describe: what exists (Knowledge), what is permitted (Authority), what is proven (Evidence). State asserts nothing about the future and takes no action; it is the world as currently known, permitted, and proven.
Action — the Transformation Engine. It is the only component that changes reality. It reads state, is gated by state, and produces new state (Evidence) and new facts (a changed estate).
Oversight — the Governance Engine. It judges action against state, continuously, over the whole population, and drives adaptation. It changes nothing in the estate itself; it changes what the system does next.

Why this separation is what makes the system governable: a system is governable exactly when its actions can be constrained before they occur and audited after they occur, by machinery distinct from the actor. Fuse action into state — let the executor also decide what is permitted — and the fail-closed boundary evaporates: the actor can grant itself authority. Fuse oversight into action — let the executor also judge itself — and governance becomes self-attestation, which is not governance. The architecture forbids both fusions structurally. The Transformation Engine cannot write the Authority Graph (it can only be gated by it), and the Governance Engine cannot execute (it can only observe and signal). Governability is therefore a property of the topology, not of any component's good behavior — which is exactly the guarantee APQC-CORE-001 P2 demands and the reason "an agent MUST NOT be able to exceed the authority it was granted" is achievable rather than aspirational.

This is also the answer to the question "why not four engines, or six?" Four engines would fuse two concerns; six would split one concern across two components and create an ungoverned seam between them. Five is the count at which each of {build-state × 3, act, oversee} has exactly one owner.

5. The five engines

Each engine has a single responsibility and maintains or acts on a specific part of the core. Engines are architectural roles, not products; one product may implement several, or one engine may be several systems. The following data-flow diagram shows how the estate, the five engines, the three graphs, and the governance loop compose. It is a supporting figure; Figure 1 remains canonical.

Figure 2 — Data flow across the five engines (informative; supports Figure 1)

                         ┌───────────────── GOVERNANCE ENGINE ─────────────────┐
                         │   reads all three graphs · judges · emits re-entry   │
                         └───▲──────────────▲──────────────▲───────────┬────────┘
                             │ (state)      │ (state)      │ (state)    │ re-entry
   ESTATE                    │              │              │            │
     │ sense                 │              │              ▼            ▼
     ▼              ┌────────┴───────┐  ┌───┴──────────┐  (loop back to sensing / intent)
 ┌────────────┐     │  KNOWLEDGE     │  │  AUTHORITY   │  ┌──────────────┐
 │ KNOWLEDGE  │────►│    GRAPH       │  │    GRAPH     │  │  EVIDENCE    │◄──┐
 │  ENGINE    │     └────────┬───────┘  └───┬──────────┘  │    GRAPH     │   │
 └────────────┘              │ reads        │ gates       └──────────────┘   │
 ┌────────────┐              │              │                     ▲          │
 │ AUTHORITY  │──────────────┼──────────────┘                     │ emits    │
 │  ENGINE    │  (intent →   │                                    │          │
 └────────────┘   grants)    ▼                                    │          │
 ┌────────────┐     ┌─────────────────────┐    per-change records │          │
 │TRANSFORM'N │────►│  TRANSFORMATION      │────────────────────────┘         │
 │  ENGINE    │     │  ENGINE (act)        │                                  │
 └────────────┘     └──────────┬──────────┘   execution+verification+authority│
      changes to estate ◄──────┘                     ────► ┌────────────┐     │
                                                            │  EVIDENCE  │─────┘
                                                            │  ENGINE    │
                                                            └────────────┘

Read Figure 2 as: the Knowledge, Authority, and Evidence engines build their respective graphs (state); the Transformation engine consumes Knowledge and is gated by Authority to act, feeding execution and verification results into the Evidence engine, which builds the Evidence Graph; and the Governance engine reads all three graphs to judge and emit the re-entry signal that reopens the loop.

5.1 Knowledge Engine — builds the Knowledge Graph

Responsible for: discovery, inventory, classification, dependency mapping — turning the raw estate into the canonical, deduplicated Knowledge Graph (APQC-MODEL-003 §3.3).
Graph it maintains: the Knowledge Graph (nodes = assets; edges = dependencies). It is the sole writer of this graph.

Interfaces (neutral contracts, not APIs). - Input — Estate Sensing: a continuous stream of observations of cryptographic assets (keys, certs, TLS endpoints, protocol handshakes, library calls, HSM slots, secrets) sensed from the live estate. Carries observation provenance and a stated coverage boundary. Read-only; discovery holds no change authority (Glossary: Discovery). - Output — Knowledge Graph View: the current classified, deduplicated asset population with dependency edges and, for each asset, its blast radius (what breaks if it changes). Consumed by the Transformation Engine (planning, simulation) and the Governance Engine (drift baseline).

Internal responsibilities. Deduplication (the same key seen through five systems is one node, not five); classification (which primitive, which risk tier, which mandate applies); dependency resolution (this service uses that cert; that cert chains to this root); coverage accounting (stating what fraction of the estate is observed, never assuming completeness).

Worked example. Discovery reports a TLS endpoint negotiating RSA-2048 on port 8443, a certificate svc-billing.example with issuer chain to an internal root, and a library manifest showing libcrypto linked by three services. The Knowledge Engine resolves these into: one asset node (the RSA key), three dependency edges (the three services), a chain edge (cert → root), and a blast-radius annotation ("rotating this key restarts three services; the cert must be reissued first"). The Transformation Engine will later read exactly this blast radius before it sequences a plan.

Failure cases. - Knowledge without coverage accounting → the estate is understated; the Transformation Engine plans against a partial world and misses assets. Mitigated by making coverage an explicit, stated output (Lifecycle Stage 2 success criterion). - Missed dependency edge → a change breaks a consumer nobody knew existed. This is the classic migration failure; the Knowledge Engine's dependency resolution exists to prevent it. - Stale graph → the estate changed but the graph did not; the Transformation Engine acts on a fiction. Mitigated by continuous sensing (the estate is a live population, not a fixed list).

Implementation notes (neutral). The Knowledge Engine is naturally distributed: sensors run wherever assets live (hosts, network taps, cloud APIs, HSM interfaces) and feed a convergent graph store. It scales by sharding the estate by domain and reconciling into one deduplicated view. It MAY be built on existing asset-management and CMDB substrates (APQC-STANDARDS-009 maps this engine to asset management), but it MUST produce dependency edges and blast radius, which generic inventories typically omit.

5.2 Authority Engine — builds the Authority Graph

Responsible for: capturing human intent, deriving delegated grants, attaching policy and constraints, and executing revocation — the full authority lifecycle of APQC-AUTH-006.
Graph it maintains: the Authority Graph (nodes = authorities; edges = delegations), rooted in an Authority Root (APQC-AUTH-006 §3). It is the sole writer of this graph.

Interfaces (neutral contracts, not APIs). - Input — Intent & Root: the authorized business outcome (Glossary: Intent), its constraints and risk tolerance, its authorizing party, and the verifiable Authority Root from which all downstream authority descends. - Output — Authority Graph View (Gating Interface): for any prospective action, the answer to "does a valid, unexpired, unrevoked path exist from a Root to this agent permitting this action on this asset?" This is the only interface the Transformation Engine may consult to be permitted to act (§7). It is fail-closed by construction (APQC-AUTH-006 A5). - Output — Authority Reference: for any action the Transformation Engine takes, the specific grant path it consumed, handed onward so the Evidence Engine can bind proof to authority (§7).

Internal responsibilities. Rooting every authority (no un-rooted authority exists, A1); binding Scope, Lifetime, Provenance to each grant (A3); enforcing monotonic-decreasing delegation and inherited constraints (A4, §6–§7 of AUTH-006); immediate propagating revocation (A6); preserving continuity across turnover and time (A7); supporting deterministic offline Authority Replay (A8).

Worked example. A human authorizer establishes intent: "convert all externally-facing RSA to ML-KEM/ML-DSA hybrid by Q4, no production change during the December freeze." The Authority Engine roots this at the Authority Root and derives a grant for the execution agent scoped to action: convert-tls-key, asset-class: external-facing, lifetime: expires 2026-12-01, with an inherited constraint no-production-change-during-freeze. When the execution agent later attempts a change on an internal asset, the Gating Interface finds no path and returns inconceivable, not merely denied — the action produces no effect and no evidence.

Failure cases. - Standing / unexpiring authority → a grant that never dies is a permanent liability; A3 forbids it. An architecture that lets the Authority Engine issue unexpiring grants is non-conformant. - Authority fused into the actor → if the Transformation Engine could write the Authority Graph, it could self-authorize; the architecture forbids this (§4). The Authority Engine is the sole writer. - Revocation that does not propagate → a revoked ancestor whose descendants still act leaves an open window; A6 requires immediate, propagating, evidenced revocation.

Implementation notes (neutral). The Authority Root is the one element that MUST be durable across the full retention horizon and unforgeable/unreplaceable (A1 (c)); a reference implementation roots it in a post-quantum trust anchor (APQC-REFERENCE-010, informative). The graph itself can be distributed and cached at the edge for low-latency gating, provided every cache is fail-closed on staleness — a gating decision MUST NOT succeed on a cache that cannot confirm non-revocation. Delegation is naturally federated (§9): each organization or domain roots its own subtree under a common Root or a cross-certified Root set.

5.3 Transformation Engine — acts at the core

Responsible for: planning, simulation, execution, and rollback — the only component that changes reality (APQC-MODEL-003 §3.6). It maintains no graph of its own; it reads Knowledge, is gated by Authority, and emits to Evidence.
Graph it acts on: all three — it reads Knowledge, is gated by Authority, emits to Evidence.

Interfaces (neutral contracts, not APIs). - Input — Knowledge Graph View: the asset population and blast radius it must plan against. - Input — Gating Interface (Authority): the fail-closed permission check consulted at planning (which actions may even be proposed) and again at the instant of each execution (which actions may proceed now). A gated action carries its Authority Reference. - Output — Estate Changes: the actual conversions applied to live assets, under least exposure (sensitive material acted upon, never revealed to the actor; Glossary: Least Exposure). - Output — Execution & Verification Records + Authority Reference: the per-change record, its verification result, and the authority path consumed — the exact inputs the Evidence Engine needs to seal proof (§7).

Internal responsibilities. Planning (an ordered, dependency-safe, reversible plan, each action pre-bounded by an existing grant, Lifecycle Stage 5); simulation (predict outcome, failures, blast radius before touching production, Stage 6); execution (governed change, authority presented at the instant of action, Stage 7); rollback (every change stageable and, where feasible, reversible, per P5). It presents authority at the moment of each action; an out-of-scope action fails closed and produces nothing.

Worked example. Given the Knowledge Graph View above (RSA key, three dependent services, cert-before-key ordering) and a grant scoped to external-facing TLS conversion, the Transformation Engine plans: reissue cert as hybrid → deploy hybrid key → drain-and-restart the three services in dependency order → verify handshake negotiates ML-KEM → retain rollback to the classical key for 72 hours. It simulates the plan and predicts one service will fail its health check under hybrid; it flags this before production. On execution, each step presents its grant to the Gating Interface, applies the change without ever reading the private key material (least exposure), and hands each per-change record plus its Authority Reference to the Evidence Engine.

Failure cases. - Transformation without Authority = ungoverned automation hazard. A Transformation Engine that can act without consulting the Gating Interface is exactly the "automated scripting without an authority model" that APQC-CORE-001 §3 declares explicitly not APQC. It is the single most dangerous failure the architecture exists to prevent: fast, autonomous, and unbounded. The fail-closed boundary (§7, A5) is the structural cure. - Transformation without Evidence → changes occur but cannot be proven; the migration is unprovable (Glossary §3). Every material change MUST emit to the Evidence Engine (E1). - Transformation without Knowledge → the engine acts blind to blast radius and breaks dependents. It MUST read the Knowledge Graph first. - Exposure during change → keys/secrets leaked to the actor violate least exposure (I3, T5). Execution MUST transform without revealing.

Implementation notes (neutral). The Transformation Engine is stateless with respect to durable truth (§3) and therefore scales horizontally: many execution workers, each gated identically, each emitting evidence, none holding authoritative state. Least-exposure execution is typically realized by credential-bound or enclave-mediated operations in which the worker directs a change to sensitive material it cannot read (a reference implementation binds execution to credentials without exposure; APQC-REFERENCE-010, informative). Workload-generality lives here: the engine role is fixed, only the transformation semantics (what "convert" means for this asset class) vary per workload (§8).

5.4 Evidence Engine — builds the Evidence Graph

Responsible for: evidence generation, verification support, replay, and preservation — turning execution into portable, independently-verifiable proof (APQC-EVIDENCE-007).
Graph it maintains: the Evidence Graph (Evidence Objects linked into a tamper-evident Chain of Evidence), cross-linked to the Authority Graph (the grant each object cites) and the Knowledge Graph (the asset each object changed). It is the sole writer of this graph.

Interfaces (neutral contracts, not APIs). - Input — Execution & Verification Records + Authority Reference: from the Transformation Engine; the what/when/who and the authority under which it occurred. An object whose Authority Reference is invalid MUST NOT be produced (E2, A5) — evidence and authority are two views of one fact. - Output — Evidence Graph View: the cryptographically-verifiable history, offered to the Governance Engine for judgment and to any external Verifier for independent, offline confirmation. - Output — Evidence Object / Chain: the atomic, portable proof (Glossary: Substrate) and the ordered, tamper-evident chain, handed to anyone, verifiable without the producer.

Internal responsibilities. Producing an Evidence Object per material change (E1); binding what (commitment, not copy) / when (backdate-resistant time) / who-and-authority / integrity (post-quantum signature) (§3 of EVIDENCE-007); maintaining the Chain of Evidence and provable Completeness (E4); ensuring Portability, Retention, Survivability (E5); supporting Independent Verification offline (E6), Continuity across format/vendor change (E7), and deterministic Replay (E8).

Worked example. For each converted asset the Transformation Engine hands over a record and its Authority Reference. The Evidence Engine seals a compact commitment to the change (revealing no key material), stamps a backdate-resistant time, binds the acting agent and the grant path, signs it post-quantum, and links it into the chain after the previous object. Years later, an auditor with only the evidence and public parameters replays the incident offline: object by object, they watch the December-freeze constraint hold (no object bears a freeze-window timestamp), the ordering hold (cert before key), and every change trace to an unexpired grant — without contacting the producer, who may no longer exist (Survivability, §6.5).

Failure cases. - Evidence without authority binding → a valid signature over an unauthorized action: "valid and meaningless" (AUTH-006 §2). E2 forbids producing it. This is what distinguishes legitimate from merely valid. - Evidence that is a log → editable, vendor-bound, unverifiable offline; dies with the system. That is logging, not evidence (§2, EVIDENCE-007). The Engine MUST produce portable, independently-verifiable artifacts. - Silent completeness gap → some changes produced no object; "we migrated everything" becomes unprovable. E4 requires provable Completeness; gaps are a conformance failure.

Implementation notes (neutral). Because Evidence Objects are compact commitments (a reference implementation uses a 74-byte post-quantum substrate; APQC-REFERENCE-010, informative), a decade of per-change evidence is measured in gigabytes, not terabytes — cheap to retain forever and to hand to anyone. The Engine SHOULD anchor object commitments to one or more independent public ledgers for a timestamp no party can alter (§7). It MUST NOT make verification depend on its own availability; the whole point is offline verifiability. Storage is deliberately boring: the trust is in the signatures and the chain, not in the store's access control.

5.5 Governance Engine — encloses and adapts

Responsible for: continuous compliance, drift detection, risk evaluation, and adaptation — judging action against state over the whole population, continuously (APQC-MODEL-003 §3.8; Lifecycle Stages 10–12).
Graph it acts on: all three — it reads Knowledge, Authority, and Evidence; it writes none of them. It is oversight, not action (§4).

Interfaces (neutral contracts, not APIs). - Input — all three Graph Views: Knowledge (current truth), Authority (what was permitted), Evidence (what was proven). - Input — Estate Sensing: the live estate, for drift detection against the post-transformation baseline. - Output — Governance Findings: the provable statement, over the whole population, that no action exceeded its authority — and precisely where, if anywhere, it did. - Output — Re-entry Signal (Continuous Adaptation): the loop-closing output that reopens the lifecycle (drift, new intent, changed standards) back into the Knowledge and Authority engines.

Internal responsibilities. Continuous compliance evaluation (does Evidence, checked against Authority, show every action within bounds?); drift detection (has the pre-transformation state reappeared? Glossary: Drift); risk evaluation; and driving adaptation by emitting the re-entry signal. Governance judges after the fact and over the whole population, where Authority bounds before the fact and per-action — the two are complementary, not redundant.

Worked example. Continuously, the Governance Engine replays the Evidence Graph against the Authority Graph and confirms: every converted asset traces to an unexpired grant; no object bears a freeze-window timestamp; completeness holds for the external-facing scope. Then Estate Sensing reports a new RSA-2048 endpoint stood up last night — drift. The Governance Engine raises a finding and emits a re-entry signal; the Knowledge Engine ingests the new asset, the Authority Engine derives (or declines) a grant to reconvert, and the loop turns again. The estate is operated, not migrated-and-forgotten (P6).

Failure cases. - Governance as opinion, not verification → findings that assert compliance rather than prove it against the Authority Graph. Stage 10's failure mode exactly; governance MUST verify against state, not narrate. - Governance fused into action → an engine that both executes and judges itself is self-attesting, not governed (§4). The Governance Engine writes no graph and performs no change. - A loop that terminates → treating transformation as done; drift then accrues invisibly until audit. The re-entry signal exists to keep the loop open (Stage 12).

Implementation notes (neutral). The Governance Engine is read-mostly and embarrassingly parallel: population-scale checks over three append-friendly graphs. It MAY run continuously or on a cadence, centrally or per-domain, provided the whole population is eventually covered. Because it consumes only the graphs and public parameters, an external party (auditor, regulator, insurer) can run an equivalent governance pass independently — which is the deepest expression of "independently verifiable" applied to oversight, not just to individual objects.

6. How the lifecycle runs across the engines

The twelve-stage lifecycle (APQC-LIFECYCLE-004) is the motion of these engines:

Lifecycle stage	Engine
Intent Established	Authority Engine (root grant)
Discovery, Understanding	Knowledge Engine
Authority Assignment	Authority Engine
Planning, Simulation, Execution	Transformation Engine
Verification, Evidence	Evidence Engine
Governance	Governance Engine
Continuous Operation, Continuous Adaptation	Governance Engine → (loop to Knowledge Engine)

The architecture is the structure; the lifecycle is the structure in motion. Note that Verification (Stage 8) is supported by the Evidence Engine (it seals verification results) but performed against reality by the Transformation Engine's verify function or an independent verifier — the table assigns the sealing of verification to Evidence, consistent with Stage 9's inputs (execution and verification records).

7. Engine interactions and contracts

Engines are decoupled: each hands a named artifact to specific others, and invariants hold on every hand-off. The following per-engine interface diagram makes the hand-offs and their invariants explicit.

Figure 3 — Engine interfaces and hand-off invariants (informative; supports Figure 1)

 KNOWLEDGE ENGINE ──[ Knowledge Graph View ]────────────► TRANSFORMATION ENGINE
   (asset population, dependency edges, blast radius)          │  GOVERNANCE ENGINE
                                                               │
 AUTHORITY ENGINE ──[ Gating Interface (fail-closed) ]───────► TRANSFORMATION ENGINE
   inv: no valid Root→agent path ⇒ action inconceivable,       │
        no effect, no evidence (A5, P2)                        │
 AUTHORITY ENGINE ──[ Authority Reference ]──────────────────► EVIDENCE ENGINE
   inv: every Evidence Object MUST cite a valid grant path (E2) │
                                                               ▼
 TRANSFORMATION ENGINE ──[ Execution+Verification Records ]──► EVIDENCE ENGINE
   inv: every material change ⇒ exactly one Evidence Object (E1)
   inv: record carries the Authority Reference it consumed
 TRANSFORMATION ENGINE ──[ Estate Changes ]─────────────────► ESTATE
   inv: least exposure — sensitive material acted on, not read (I3)

 KNOWLEDGE / AUTHORITY / EVIDENCE ──[ Graph Views ]──────────► GOVERNANCE ENGINE
   inv: Governance reads all three; writes none (oversight, §4)
 GOVERNANCE ENGINE ──[ Re-entry Signal ]────────────────────► KNOWLEDGE + AUTHORITY ENGINES
   inv: the loop never terminates (Stage 12)

The normative hand-off invariants:

H1 — Gated action only. The Transformation Engine MAY receive an action from the Authority Graph's Gating Interface only if a valid, unexpired, unrevoked Root-to-agent path exists. Absent a path, the action is inconceivable: no effect, no evidence (A5, P2). No other path into "act" exists.
H2 — Authority reference required for evidence. The Evidence Engine MUST receive, with every execution record, the Authority Reference the action consumed, and MUST NOT produce an Evidence Object whose authority path is invalid (E2). Evidence without authority is "valid and meaningless."
H3 — Evidence per material change. The Transformation Engine MUST hand the Evidence Engine one record per material change; the Evidence Engine MUST seal one Evidence Object per record. Completeness (E4) is provable only if this hand-off is total.
H4 — Knowledge before action. The Transformation Engine MUST read the Knowledge Graph View (including blast radius) before planning or executing. It does not act blind.
H5 — Least exposure on estate changes. Every Estate Change hand-off transforms sensitive material without revealing it to the actor (I3).
H6 — Oversight reads all, writes none. The Governance Engine receives all three Graph Views and Estate Sensing, and hands back only the Re-entry Signal and Findings. It writes no graph and applies no change (§4).
H7 — Sole-writer per graph. Each graph has exactly one writing engine (Knowledge→Knowledge Engine, Authority→Authority Engine, Evidence→Evidence Engine). No engine writes a graph it does not own. This is what makes the graphs authoritative.

These seven invariants are the architecture's contract surface. A build that honors them is conformant regardless of how it packages the engines; a build that breaks any one of them is not APQC, whatever it is called.

8. Architectural properties

Topology-agnostic. Engines MAY be centralized or distributed; the architecture constrains responsibilities and flows, not deployment (§9).
Fail-closed at the Authority boundary. The Transformation Engine cannot act outside an Authority Graph path (APQC-AUTH-006 A5; H1). This is the load-bearing property.
Evidence-complete. Every material change emitted by the Transformation Engine produces an Evidence Graph entry (APQC-EVIDENCE-007 E1; H3).
Workload-general. The same five engines serve every workload (APQC-CORE-001 §10); only the estate and transformation semantics differ. This is what makes the implementing system a platform.
Recoverable. Durable truth lives in the three graphs, not in the transient Transformation Engine (§3); a crashed actor loses no authoritative state.
Externally auditable. Because Governance consumes only graphs and public parameters, an outside party can run its own governance pass (§5.5), extending independent verification from objects to oversight.

9. Deployment topologies

The architecture is topology-agnostic (§8): it fixes responsibilities and hand-offs, not where components run. Three canonical topologies illustrate the range; all three remain conformant because all preserve §7's invariants.

Centralized. All five engines run as one system in one trust domain, sharing one Authority Root and one Evidence substrate. Simplest to operate and to reason about; suited to a single organization converting its own estate. Conformance is straightforward: the invariants are enforced by in-process contracts. Risk to watch: the temptation to fuse action and oversight for convenience (§4) — the sole-writer rule (H7) must still hold in code even when everything shares a process.

Distributed. The engines run as separate services, often across regions or clusters, cooperating over hand-offs. The Knowledge Engine's sensors are naturally at the edge; Transformation workers scale horizontally (§5.3); the Authority Engine caches gating decisions near the actors but fails closed on staleness (§5.2); the Evidence Engine writes an append-friendly, offline-verifiable store. Conformance requirement: the Gating Interface (H1) and Authority-Reference binding (H2) MUST hold across the network — a distributed system MUST NOT let latency or partition open a window in which an action proceeds without a confirmed, non-revoked path. Partition posture is fail-closed: if authority cannot be confirmed, the action does not occur.

Federated. Multiple organizations or domains, each operating its own engines and its own Authority subtree, cooperate under a common or cross-certified Authority Root. Delegation crosses organizational boundaries (a vendor granted a scoped, time-bounded, revocable right to convert a customer's external TLS); Evidence produced in one domain is independently verifiable in another precisely because it depends on no producer (§5.4, E6). Conformance requirement: every cross-domain grant is still a monotonic-decreasing delegation from a verifiable Root (A1, A4), and every cross-domain Evidence Object still cites a valid Authority Reference (H2). Federation adds no new engine; it distributes the same five and roots them commonly.

In all three, the picture in Figure 1 is unchanged. What varies is the number of processes and trust domains the five roles are spread across — never the roles, never the hand-offs, never the invariants. That is precisely what "topology-agnostic" means and why the architecture is safe to adopt incrementally and across organizational lines.

10. Two views, one architecture

Figure 1 is the structural view (what the components are). The lifecycle provides the operational view (the order in which they act):

Estate → Knowledge → Authority → Plan/Simulate → Execute → Evidence → Govern → Adapt ─┐
   ▲                                                                                  │
   └──────────────────────────────────────────────────────────────────────────────────┘

Both are the same architecture. The structural view is canonical (Figure 1); the operational view shows why it never terminates.

The two views answer different questions and both are needed. The structural view answers "what must exist and what may each part touch?" — it is how an architect builds, an auditor maps controls, and a buyer compares vendors. The operational view answers "in what order do the parts act, and where does the loop close?" — it is how an operator runs the system and how the discipline earns the word continuous (P6). The mapping between them is exact: every arrow in the operational flow is one engine writing or reading one graph in the structural figure (Knowledge writes Knowledge; Authority gates and is cited; Transformation reads-and-emits; Evidence seals; Governance reads-all and re-enters). Because the mapping is exact, the two figures are not two architectures to reconcile but one architecture seen from two angles — structure at rest and structure in motion. Keep both; neither replaces the other, and the structural figure remains canonical.

11. Basis for maturity and standards composition

This architecture directly enables the next two specifications, and the engine decomposition is what makes both expressible.

Maturity (APQC-MATURITY-008) is engine adoption. Because the five engines are separable roles with clean hand-offs, an organization can stand them up in order and its maturity level is simply which engines it operates: Knowledge → +Authority → +Transformation → +Evidence → +continuous Governance. This maps onto the Constitution's Level 0–5 ladder: inventory (Knowledge) precedes visibility (classified Knowledge), which precedes governed conversion (Authority + Transformation + Evidence together), which precedes continuous conversion and autonomous infrastructure (continuous Governance closing the loop). The architecture makes "how mature are we?" answerable by pointing at Figure 1 and shading in the engines you run. Crucially, the invariants that appear at Level 3 and above — fail-closed authority, evidence per change — are the same §7 invariants; maturity increases autonomy, never relaxes them.
Standards composition (APQC-STANDARDS-009) is engine composition. Because each engine is a role rather than a product, each maps cleanly to the body of existing standards that already address that role: Knowledge ↔ asset management / CMDB; Authority ↔ Zero Trust / IAM / ABAC (SP 800-207); Transformation ↔ PQC migration / crypto agility (SP 1800-38, FIPS 203/204/205); Evidence ↔ audit / chain-of-custody / non-repudiation; Governance ↔ CSF / ISO 27001 / PCI / HIPAA / FedRAMP. APQC does not compete with these standards; it composes them into one operating model by giving each a home engine and defining the hand-offs between them that no single existing standard specifies. The engine boundaries are, in effect, the seams along which the discipline stitches the existing standards together.

12. Reference implementation

A conforming implementation realizes the five engines on a shared authority root and evidence substrate, such that the Authority and Evidence graphs are two views of one cryptographic fact. The reference implementation is described in APQC-REFERENCE-010; it is a conforming implementation of this architecture, not the definition of it. This section is informative. Where earlier sections point at concrete mechanisms (a post-quantum Authority Root, credential-bound least-exposure execution, a compact post-quantum evidence substrate, continuous-compliance governance), those pointers are illustrative of the roles and defer entirely to APQC-REFERENCE-010; the normative content of this document is the engines, their interfaces, the hand-off invariants (§7), and the conformance tests (§13).

13. Conformance tests

A system implements this architecture if and only if the following checkable assertions all hold. Each is a test, not a description: it names an observable condition a verifier can attempt and observe pass or fail. These compose with, and do not weaken, the conformance clauses of APQC-CORE-001 §14, APQC-AUTH-006 §11, and APQC-EVIDENCE-007 §10.

C1 — Five engines present. All five roles (Knowledge, Authority, Transformation, Evidence, Governance) are identifiable in the system, each with the responsibilities of §5. Fails if any role is absent or two roles are fused such that no boundary exists between them (e.g., the actor also writes the Authority Graph).
C2 — Sole writer per graph. Each graph has exactly one writing engine (H7). Test: attempt to write the Authority Graph from the Transformation Engine — it MUST be impossible by construction, not merely disallowed by policy.
C3 — Fail-closed at the Authority boundary. Attempt an action with no valid Root-to-agent path (expired, revoked, out-of-scope, or absent). It MUST produce no effect and no evidence (A5, P2, H1). This is the load-bearing test; a system that "denies but logs" the attempt, or that produces evidence of a blocked action, fails.
C4 — No transformation without knowledge. Test: remove or stale the Knowledge Graph View for a target asset and attempt a change. The Transformation Engine MUST refuse to act blind to blast radius (H4).
C5 — Evidence-complete. For a defined scope, every material change produced exactly one Evidence Object and completeness over that scope is provable (E1, E4, H3). Test: execute N changes; confirm N objects, a whole chain, and no silent gap.
C6 — Authority-bound evidence. Test: attempt to seal an Evidence Object whose Authority Reference is invalid — it MUST NOT be produced (E2, H2). Conversely, every produced object MUST cite a valid grant path.
C7 — Independently verifiable, offline. A third party, using only the evidence and public parameters, verifies an Evidence Object and replays an incident without contacting the producer (E6, E8). Test: disconnect the producer entirely; verification still succeeds.
C8 — Least exposure. Test: audit an execution path for a sensitive asset; the acting worker MUST never have read the sensitive material it transformed (I3, H5).
C9 — Loop closes. Inject drift (reintroduce a classical primitive) and confirm the Governance Engine detects it and emits a re-entry signal that reopens the lifecycle (Stages 11–12, H6). Fails if the system treats transformation as terminal.
C10 — Workload-general. The same five engines and the same §7 invariants apply when the workload changes (e.g., identity or PKI in place of PQC); only transformation semantics differ (§8). Test: substitute a second workload and confirm no engine or invariant changes.
C11 — Topology-conformant. Under the system's actual topology (centralized, distributed, or federated), C3 and C6 still hold across every process and trust-domain boundary — in particular, no latency or partition opens a window in which an action proceeds without a confirmed, non-revoked authority path (§9).

A system that passes C1–C11 implements this architecture. A system that fails any of them MAY still be useful software, but MUST NOT be described as a conforming APQC architecture (APQC-CORE-001 §14).

14. Not In Scope

This specification does not define: specific products, vendors, or APIs (APQC-REFERENCE-010); cryptographic algorithms (NIST); deployment topologies, orchestration technologies, data formats, or wire protocols; or workload-specific transformation mechanics. It defines the engines, their responsibilities, and their composition — the recognizable shape of the discipline — not any single build of it.

In particular, §9 (Deployment topologies) is illustrative: it shows that the architecture stays conformant under centralized, distributed, and federated deployments, but it does not mandate, standardize, or design any of them. Choosing a topology, an orchestration technology, a storage system, a ledger, or a wire format is an implementation decision governed by APQC-REFERENCE-010 and by the implementer, constrained only by the requirement that the §7 hand-off invariants and the §13 conformance tests continue to hold. The architecture is the shape and the contract; the build is someone else's document.