The Agentic Post-Quantum Conversion Canonical Glossary

The single authoritative dictionary for the discipline. Every other specification uses these terms exactly as defined here.

  • Document: APQC-GLOSSARY-000 — Canonical Glossary
  • Status: Draft 0.1
  • Version: 0.1
  • Date: 2026-07-02
  • Editor / Authoring body: H33.ai, Inc.

A discipline lives or dies by consistent terminology. Where common usage treats verification, validation, proof, and attestation as interchangeable, this glossary makes them distinct and non-substitutable. Numbered 000 because every specification depends on it and it depends on none.

RFC 2119 keywords apply where used.

0. Front Matter

0.1 Normative References

  • None. This document is the terminological root.

0.2 Informative References

  • APQC-CORE-001; APQC-MODEL-003; APQC-LIFECYCLE-004; APQC-ARCH-005; APQC-AUTH-006; APQC-EVIDENCE-007.
  • Every specification in the corpus references this glossary.

0.4 Conformance Dependencies

  • Depends on: none.
  • Referenced by: all APQC specifications.

1. Conventions

A term in bold within a definition is itself defined in this glossary. Each entry carries, where useful, a usage note (how the term is used across the corpus), a one-line example, and a Defined in: pointer to the specification that owns the term's full treatment. Where two terms are commonly confused, an explicit Distinct from contrast is given; these contrasts are normative — substituting one term for another is a defect, because non-substitutability is the entire point of this document. The glossary is the terminological root: it defines the words, but the owning specification governs the full semantics.

2. Terms

Agent — an autonomous software system that performs stages of the lifecycle on behalf of an authorizing party, acting only within granted authority. An agent proposes or executes; it holds no standing authority beyond what is delegated, and no badge, manager, or conscience to check it — it has exactly its authority and nothing else. Usage note: the discipline's safety rests not on an agent's good behavior but on the structure that bounds it; over-reach must be inconceivable, not merely disallowed. Example: a discovery agent and an execution agent may share one identity yet hold different authority. Defined in: APQC-CORE-001 §7; APQC-AUTH-006 §1.

Agentic — performed by agents operating a defined lifecycle, as opposed to by humans executing a runbook or by static automation without an authority model. One of the three mandatory properties of APQC (agentic · governed · proven). Usage note: a process that lacks the agentic property is a predecessor to the discipline, not an instance of it. Defined in: APQC-CORE-001 §2.

Anchor — an independent, tamper-evident record (e.g., on a public ledger) of an evidence commitment, providing a timestamp that no party — including the issuer — can alter. Anchoring establishes existence-at-a-time, not content: the ledger sees only a commitment. Usage note: defeats backdating and gives a whole Chain of Evidence an external time reference independent of every party's clock; a MAY in the normative body because the property (independent, unalterable time) is required while a public ledger is one way to get it. Distinct from a claimed timestamp, which the issuer writes and can backdate. Defined in: APQC-EVIDENCE-007 §7, §13.3.

APQC — Agentic Post-Quantum Conversion: the use of governed AI agents to discover, analyze, convert, validate, and continuously maintain an organization's cryptographic infrastructure, migrating classical primitives to NIST-standard post-quantum algorithms while producing portable, replayable, cryptographically-verifiable evidence of every change. Within this discipline the acronym always expands to Agentic Post-Quantum Conversion. Usage note: APQC is both the discipline's name and its first workload; the lifecycle and three graphs generalize to other workloads. Defined in: APQC-CORE-001 §2.

Attestation — the signing mechanism that binds a claim to the authority under which it was made. Attestation is the operation that produces proof. Usage note: a valid signature attests that a key signed a statement; only an authority-rooted attestation makes that statement legitimate rather than merely valid. Example: an execution agent attests "endpoint X converted at time T," binding the claim to the grant it consumed. Distinct from proof (the verifiable artifact attestation yields) and evidence (the graph-structured body of such artifacts). Defined in: APQC-EVIDENCE-007 §1.1.

Authority — a scoped, delegable, time-bounded, revocable right to perform a specified class of transformation on a specified class of asset, rooted in a verifiable trust anchor. A first-class, structured, portable object with lineage, bounds, and a lifetime — not a role label, permission flag, or momentary yes/no. Usage note: authority is what makes a signature legitimate, not merely valid — a party that generates its own keys has valid signatures and zero authority. Example: {action: convert, asset: estate/prod/tls-eu-*}, 24-hour lifetime, revocable by the CISO, traceable to a Root. Distinct from policy (constrains how authority is used), identity (who a party is), authentication (proving it), authorization (a discarded instant), and credential (proves a fact, not a right). Defined in: APQC-AUTH-006 (whole).

Authority Graph — the structure of all authority grants in force and their lineage: who delegated what to whom, within what bounds, and who may revoke it. A directed acyclic graph rooted in an Authority Root, with authorities as nodes and delegations as edges. Answers "what is permitted?" — one of the three graphs. Usage note: an action is possible only at the intersection of the Authority Graph and the Knowledge Graph — a permitted action on an asset that exists. Distinct from the Knowledge Graph (which describes reality, not permission) and the Evidence Graph (which records what was actually done). Defined in: APQC-AUTH-006 §4; APQC-MODEL-003 §3.4.

Authority Replay — the operation of reconstructing the exact state of the Authority Graph as it existed at any past moment — every grant, constraint, and revocation in force when an action occurred — deterministically and offline, from retained data alone. Turns authority from a live permission check into historical, provable fact. Usage note: the authority-side counterpart to Evidence Replay; the two compose to reconstruct both what was permitted and what happened at any past instant. Example: an auditor answers "under what right did the agent convert tls-eu-42 at 15:00 on Feb-03?" years later, with no live system consulted. Defined in: APQC-AUTH-006 §10.

Authority Root — the verifiable trust anchor from which all authority in a transformation descends; the point at which the chain of "delegated from" terminates. A conforming Root is independently verifiable offline, durable across the retention horizon (a post-quantum requirement), and non-forgeable / non-silently-replaceable. Usage note: rootedness is the scarce property — cryptographic validity is free. Authority presented without a verifiable path to a Root is un-rooted, and un-rooted authority is treated exactly as no authority; there is no partial credit. Distinct from an anchor, which timestamps evidence rather than originating authority. Defined in: APQC-AUTH-006 §3.

Blast radius — the set of dependents that break if a given asset changes; the enumerated downstream impact of a transformation, computed from the Knowledge Graph's dependency edges. Usage note: blast radius MUST be enumerable, not asserted — an unmeasured blast radius is an unbounded one. It is produced in Understanding, consumed by Planning (sequencing) and Simulation (predicted failure surface), and used to sequence low-impact changes before high-impact ones. Example: a code-signing key with 312 downstream artifacts is not one change but a change with 312 dependents. Defined in: APQC-LIFECYCLE-004 Stage 3; APQC-ARCH-005 §5.1.

Chain of Evidence — an ordered, tamper-evident linkage of Evidence Objects in which each object binds a cryptographic hash of its predecessor, so that no object can be inserted, removed, or reordered without detection. Establishes that a set of changes is whole and in order, supporting completeness. Usage note: ordering is structural, not asserted — order is checkable without trusting any clock, unlike a log, where a deleted line leaves no trace. Example: deleting object EO_5 from a chain of 100 breaks the hash-link at EO_6, proving (not merely suspecting) the deletion. Defined in: APQC-EVIDENCE-007 §5.

Claim — an assertion that something is true (e.g., "this asset was converted"). A claim is not proof until it is attested and independently verifiable. Usage note: the discipline's core move is refusing to accept claims as evidence; assertion is not evidence. Defined in: APQC-EVIDENCE-007 §1.1; APQC-GLOSSARY-000.

Commitment — a compact, hiding-and-binding cryptographic function of a change (e.g., a salted hash over a canonical before ∥ after) that proves what changed to anyone later holding the original bytes while revealing nothing to anyone who does not. The "what" an Evidence Object binds. Usage note: evidence commits, it does not copy; commitment (always portable, always safe) is separated from disclosure (shown only to a party entitled to the content), letting one artifact serve both the regulator who must verify and the confidentiality regime that must not leak. All Evidence Objects commit, so a commitment never signals that this change was sensitive. Defined in: APQC-EVIDENCE-007 §3.1, §13.1.

Conformance — the property of a process, implementation, or artifact that satisfies all mandatory (MUST-level) requirements of a specification. Each specification defines its own conformance tests (e.g., CT-*, A*, E*, C*); a claim of conformance names the specification and its test suite. Usage note: partial adoption MAY be described by maturity level but MUST NOT be described as "APQC" without all three mandatory properties (agentic · governed · proven). Defined in: APQC-CORE-001 §14; per-spec conformance sections.

Continuous Operation — the lifecycle stage (Stage 11) that monitors an estate continuously for drift after transformation, emitting characterized drift detections and clean-interval receipts (so "checked-and-clean" is distinguishable from "not checked"). Recognizes that the lifecycle has no terminal state. Usage note: re-invokes the Discovery function on a standing basis and is the primary trigger for Continuous Adaptation. Distinct from Discovery, which seeds the first cycle; Continuous Operation re-checks against what should already be true. Defined in: APQC-LIFECYCLE-004 Stage 11; APQC-MODEL-003 §3.9.

Continuous Adaptation — the lifecycle stage (Stage 12) that re-enters the lifecycle as intent, environment, or standards change, governing and proving each adaptation as a first-class cycle with fresh authority and versioned deltas linking it to the prior cycle. Usage note: a full re-entry into Stage 1, never a shortcut back into Execution, so re-authorization and re-simulation are never skipped. This edge is what turns a project into an operating model. Defined in: APQC-LIFECYCLE-004 Stage 12.

Conversion — a transformation whose target is a change of cryptographic primitive (classical → post-quantum or hybrid). Conversion is the specific transformation of the APQC workload. Usage note: other workloads transform other asset classes (identities, certificates, secrets); "conversion" is reserved for the cryptographic-primitive change. Distinct from migration, which names the goal without implying authority or proof. Defined in: APQC-CORE-001 §2, §5.

Credential — an artifact that proves a fact — an identity, an attribute, or possession of a key. Usage note: holding a credential (even a signing key) is not the right to act. Distinct from authority, which grants an action: "a party that generates its own keys has valid signatures and zero authority." Self-signed trust anchors and rogue internal CAs are this conflation. Defined in: APQC-AUTH-006 §2.5.

Cryptographic asset — see asset. Specifically, any concrete use of a cryptographic primitive: a key, certificate, TLS endpoint, signing or key-exchange operation, protocol handshake, library call, HSM slot, or stored secret. Defined in: APQC-CORE-001 §5.

Delegation — the act of granting a subset of one's authority to another party, recorded as a directed edge (delegator → delegate) in the Authority Graph. Delegation MUST be monotonic (§ monotonic delegation): a delegate never receives more scope, longer lifetime, or weaker constraints than its delegator holds; a widening delegation is void, not merely disallowed. Usage note: traceable, bounded, and revocable; delegation to a party already holding ancestor authority creates a new, weaker node, never a cycle. Defined in: APQC-AUTH-006 §7; APQC-MODEL-003 §3.4.

Discovery — the continuous sensing function (lifecycle Stage 2) that observes an estate and reports assets, each with provenance and a stated coverage boundary. Discovery holds no authority to change anything. Usage note: Discovery produces raw observations; turning them into meaning is Understanding. It is always-on, not a one-time scan, because the estate is a live population. Distinct from Understanding (classification and structure) and from any change action — an "observation mistaken for change" violates the least-exposure and authority invariants. Defined in: APQC-LIFECYCLE-004 Stage 2; APQC-MODEL-003 §3.2.

Drift — the reappearance, after transformation, of the pre-transformation state (e.g., new classical primitives from an old template, rollbacks, shadow systems). Drift re-opens the lifecycle via Continuous Operation → Continuous Adaptation. Usage note: drift is why the discipline is an operating model, not a project; it is the standing threat that continuity (P6) exists to answer. Example: a load balancer provisioned from an old template starts serving RSA-2048 inside converted scope. Defined in: APQC-CORE-001 §5; APQC-MODEL-003 §3.9.

Engine — an architectural role: a bounded set of responsibilities with named inputs and outputs. An engine is not a product — one product MAY implement several engines and one engine MAY be several cooperating systems; what is normative is what each is responsible for and what it hands to the others, never how it is packaged. The reference architecture defines exactly five engines, no more and no fewer:

  • Knowledge Engine — builds the Knowledge Graph: discovery, classification, dependency mapping, blast radius, coverage. Sole writer of the Knowledge Graph.
  • Authority Engine — builds the Authority Graph: captures intent, derives grants, attaches policy/constraints, executes revocation; exposes the fail-closed gate. Sole writer of the Authority Graph.
  • Transformation Engine — acts: plan, simulate, execute, roll back. The only component that changes reality; reads Knowledge, is gated by Authority, emits to Evidence, holds no durable graph of its own.
  • Evidence Engine — builds the Evidence Graph: evidence generation, verification support, replay, preservation. Sole writer of the Evidence Graph.
  • Governance Engine — encloses and adapts: continuous compliance, drift detection, risk, adaptation. Reads all three graphs, writes none; oversight, not action.

Usage note: separating state (three graphs), action (Transformation Engine), and oversight (Governance Engine) is what makes the architecture governable — the actor cannot grant itself authority and no engine judges itself; each graph has exactly one writing engine (the sole-writer rule). Defined in: APQC-ARCH-005 §1, §4, §5, §7.

Estate — the complete population of an organization's assets relevant to a workload. Treated as a live, changing population, never a fixed list. Usage note: the estate's continuous change is why Discovery is always-on and why authority is issued over classes of asset rather than instances. Defined in: APQC-MODEL-003 §3.1; APQC-CORE-001 §3.

Evidence — the body of portable, independently-verifiable artifacts recording what was actually done, confirmable without trusting — or contacting — the producer, for the full retention horizon. Evidence answers "what provably happened." Usage note: the discipline's governing refrain is "evidence is not logging" — the two are different kinds of object with different trust models, not points on a spectrum. Evidence is structured into the Evidence Graph. Distinct from a log (editable, issuer-bound, mortal with its system); distinct from proof (a single artifact — evidence is the graph-structured body of many), attestation (the mechanism), and verification (the act of checking). Defined in: APQC-EVIDENCE-007 (whole).

Evidence Graph — the cryptographically-verifiable history of every transformation, with Evidence Objects as nodes and chain / authority / knowledge edges, cross-linked to the other two graphs. Answers "what is proven?" — one of the three graphs. Append-only: correction is a new superseding node, never an edit. Usage note: the discipline's memory — the thing that makes "converted" demonstrable rather than asserted; it is not a log of execution but a set of proofs about execution. Distinct from the Knowledge Graph (reality) and Authority Graph (permission). Defined in: APQC-EVIDENCE-007 §4; APQC-MODEL-003 §3.7.

Evidence Object — the atomic unit of the Evidence Graph: a compact, canonical, cryptographically-signed commitment produced for every material transformation, binding what (commitment), when (backdate-resistant time), who / under what authority, and an integrity binding (post-quantum signatures over all of the above). Verifiable in isolation. Usage note: the neutral term for what the reference implementation calls a substrate. No Evidence Object is produced for an unauthorized action — such an action yields no effect and no evidence. Defined in: APQC-EVIDENCE-007 §3.

Evidence Replay — the operation of deterministically reconstructing a past transformation or entire incident from the Evidence Graph — what happened, in what order, under whose authority, with what result — examined like a recording rather than inferred from fragments, offline, years later. Usage note: composes with Authority Replay; determinism is achieved by reconstructing solely from committed, signed content and chain of evidence order — never from mutable state. Defined in: APQC-EVIDENCE-007 §9.

Execution — the lifecycle stage (Stage 7) that makes governed changes in the live estate, consuming reserved grants under least exposure. The only function that changes reality. Usage note: authority is presented at the moment of each action, not at plan-approval time; an out-of-scope action fails closed, changes nothing, and produces no evidence. Defined in: APQC-LIFECYCLE-004 Stage 7; APQC-MODEL-003 §3.6.

Fail-closed — the invariant behavior whereby an action lacking a valid authority path (expired, revoked, out-of-scope, or absent) produces no effect and no evidence, silently. The absence of a valid path is not an error to log; it is the normal, effect-free outcome. Usage note: a fail-closed action is inconceivable, not "denied" — denial leaves a trace and a foothold, inconceivability leaves nothing. The load-bearing property of the whole architecture; ambiguity at a revocation or partition boundary is resolved conservatively (treated as unauthorized). Defined in: APQC-AUTH-006 §4.2, A5; APQC-ARCH-005 §7, §8.

Gate — a machine-checkable predicate that MUST be true before a lifecycle transition occurs or before an agent acts. Between each pair of lifecycle stages sits a gate over the graphs and artifacts produced so far; the Authority Engine's gating interface is the fail-closed permission check the Transformation Engine consults to be permitted to act. Gate failure is a first-class outcome, not an error. Usage note: two lifecycle gates are fail-hard — Simulation→Execution and the moment-of-action authority check — where a soft failure causes outages or unprovability. Distinct from a checkpoint meeting: a gate is a predicate, not a discussion. Defined in: APQC-LIFECYCLE-004 §5; APQC-ARCH-005 §5.2, §7.

Governance — the continuous evaluation (lifecycle Stage 10) of a transformation against policy, authority, and risk; specifically, proving over the whole population, by joining the Evidence Graph against the Authority Graph, that no action exceeded its authority. Usage note: Governance judges after the fact over the whole estate; authority permits before the fact per-action — complementary, not redundant. Governance holds authority constant and never mutates it; a run that grants or broadens authority has stopped judging and started permitting — a conformance failure. Distinct from authority (which permits). Defined in: APQC-LIFECYCLE-004 Stage 10; APQC-MODEL-003 §3.8.

Hybrid — a deployment carrying both a classical and a post-quantum primitive simultaneously, used to de-risk transition. A valid conversion target state and the default de-risking posture during transition (P5). Example: an endpoint presenting classical + PQ together where a legacy partner rejects pure PQ. Defined in: APQC-CORE-001 §5, P5.

Inconceivable — the status of an action for which no valid path exists in the Authority Graph: it cannot be attempted, produces no effect, and produces no evidence. Usage note: deliberately stronger than denied. A denied action leaves a trace and a foothold; an inconceivable action leaves nothing an attacker can build on and nothing an auditor must sift. Achieved by construction — the illegitimate action is made impossible, not merely discouraged. Distinct from denied (which implies the action was considered and refused). Defined in: APQC-AUTH-006 §4.2.

Intent — the bounded, authorized business outcome a transformation must achieve; the root from which all downstream authority derives, established in lifecycle Stage 1. Usage note: intent is the only lifecycle artifact whose authorizing authority originates outside the system (a human authorizer or governing body); every other grant is derived by delegation. Intent is immutable within a cycle — a changed outcome is a new intent (a new Stage 1), linked by a Stage 12 delta. An unbounded intent poisons everything downstream; an unauthorized intent leaves the whole Authority Graph un-rooted. Defined in: APQC-LIFECYCLE-004 Stage 1.

Invariant — a condition that holds across every abstraction and every edge of the discipline, not a stage. The three invariants are I1 Proof (no transition is complete until it has produced independently-verifiable evidence), I2 Authority (no action occurs outside the Authority Graph; an unauthorized attempt produces no effect and no evidence), and I3 Least Exposure (sensitive material is acted upon without being revealed to the actor). Usage note: a stage may advance a graph but may never do so in violation of an invariant; an invariant violation is more severe than a stage-output failure because it is silent and cross-cutting. Defined in: APQC-MODEL-003 §4; APQC-LIFECYCLE-004 §3.2.

Knowledge Graph — the canonical, deduplicated representation of what assets exist and what depends on them: nodes are assets, edges are dependencies, and each asset carries its blast radius. Answers "what is known?" — one of the three graphs. The map of reality. Usage note: built by the Knowledge Engine; can be wrong (stale, incomplete) without any action being illegitimate, which is exactly why it is kept separate from the Authority Graph. Distinct from the Authority Graph (permission) and Evidence Graph (proof). Defined in: APQC-MODEL-003 §3.3; APQC-ARCH-005 §5.1.

Least Exposure — the invariant (I3) that sensitive material (keys, secrets, regulated data) is acted upon without being revealed to the acting agent. Transformation does not require exposure. Usage note: typically realized by credential-bound or enclave-mediated operations in which the worker directs a change to material it cannot read; reading a private key "to make signing easier" is the archetypal violation. Defined in: APQC-CORE-001 P4; APQC-MODEL-003 §4 (I3).

Lifecycle — the twelve-stage, decision-based sequence by which an autonomous system transforms critical infrastructure under governed authority: Intent → Discovery → Understanding → Authority Assignment → Planning → Simulation → Execution → Verification → Evidence → Governance → Continuous Operation → Continuous Adaptation. Ordered but iterative and never-terminating; Stage 12 re-enters Stage 1. Workload-independent. Usage note: framed around decisions, not tools, so it outlives the technology that satisfies it; the workload changes, the lifecycle does not. Defined in: APQC-LIFECYCLE-004 (whole); APQC-CORE-001 §6.

Log — a chronological record a system emits about itself, for its own operators: editable by whoever controls the system, meaningful only in its native context, and mortal with its system. A log answers "what did this system say happened" and requires you to trust the system. Usage note: the recurring normative contrast of the discipline — "evidence is not logging." Access control or write-once storage reduce the ease of tampering but do not change the trust model. A deleted log line leaves no log line, so a log can never prove completeness. Not evidence and not proof. Defined in: APQC-EVIDENCE-007 §2.

Maturity level — a stated degree of APQC adoption on the six-level ladder (0 Unknown · 1 Inventory · 2 Visibility · 3 Governed Conversion · 4 Continuous Conversion · 5 Autonomous Cryptographic Infrastructure). Usage note: architecturally, maturity is engine adoption — which engines an organization operates (Knowledge → +Authority → +Transformation → +Evidence → +continuous Governance). Autonomy rises with level, but proof and authority are invariant from Level 3 up; maturity increases autonomy, never relaxes the invariants. Distinct from conformance (a binary MUST-satisfied property, not a level). Defined in: APQC-CORE-001 §13; APQC-ARCH-005 §11; APQC-MATURITY-008.

Migration — the broad, often-manual practice of moving from one state to another. Distinct from conversion / transformation in the discipline's sense: migration names the goal; the discipline names the governed, agentic, proven way of achieving it. "Migration" alone implies neither authority nor proof. Defined in: APQC-GLOSSARY-000; APQC-CORE-001 §5.

Monotonic delegation — the rule that delegation can only decrease effective authority down every path of the Authority Graph: a sub-authority's effective scope is the intersection of every ancestor's scope, its effective constraints are the union of every ancestor's constraints, and its effective lifetime is the intersection of every ancestor's window. Usage note: this is the single property that makes the graph sound — no leaf can hold effective authority its Root did not permit, and effective authority is computable from the graph alone. A delegation attempting to widen scope, extend lifetime, or weaken constraints is void, and no path runs through a void node. Defined in: APQC-AUTH-006 §7.1, §7.3, A4.

Plan — the ordered, dependency-safe, reversible sequence of changes (lifecycle Stage 5) that satisfies the intent without violating dependencies or authority; each planned action is bounded by an existing (reserved) grant and carries a reversal path. Usage note: a plan proposes only actions for which authority exists; it reserves grants but does not consume them (consumption happens in Execution), which is what lets Simulation reason over the plan without side effects. Defined in: APQC-LIFECYCLE-004 Stage 5; APQC-MODEL-003 §3.5.

Policy — a rule constraining how authority may be exercised (e.g., "no production change during a freeze window," "human approval above risk tier N"). Policy shapes the use of authority; it does not grant it. Usage note: in the Authority Model, policy-shaped limits ride down the delegation chain as inherited constraints that bind every descendant and cannot be loosened. Distinct from authority (which grants) and governance (which judges). Defined in: APQC-AUTH-006 §7.2, §8; APQC-GLOSSARY-000.

Proof — a portable artifact that lets a third party independently confirm a claim without trusting its issuer, for the full retention horizon. Produced by attestation; the thing a verification checks. Usage note: evidence is the graph-structured body of proofs; a single proof is one artifact within it. Distinct from verification (the act of checking), validation (checking correctness against a spec), attestation (the mechanism that produces proof), and evidence (the corpus). Defined in: APQC-EVIDENCE-007 §1.1; APQC-CORE-001 P1.

Reference Implementation — a specific realization of the discipline by named technology. The reference implementation of this corpus is H33 (APQC-REFERENCE-010); neutral specifications define the discipline, the reference implementation instantiates it. Usage note (informative): reference-implementation names — H33-Root (authority), H33-Key (credential-bound execution), H33-74 (a 74-byte post-quantum evidence substrate), Agent-Zero, HATS, Agent-008 — are illustrative only and MUST NOT appear in any conformance claim against a normative specification. Defined in: APQC-CORE-001 §9; APQC-REFERENCE-010.

Reference workload — the first and canonical workload, APQC (post-quantum conversion), against which the lifecycle, three graphs, and engines are worked through in full. Usage note: used throughout the corpus as the carried example (e.g., Northwind Financial converting 1,240 TLS endpoints and a code-signing pipeline); a second worked example (Agentic Identity Modernization) demonstrates workload generality by running the identical lifecycle over non-cryptographic assets. Defined in: APQC-CORE-001 §2.1; APQC-LIFECYCLE-004 §1, §6.

Revocation — the withdrawal of an authority by an appropriate ancestor at any time, propagating to all descendants immediately and verifiably; a revoked path fails closed for all future actions and the revocation is itself evidenced. Usage note: propagation runs down from the cut point (inheritance in reverse); "immediate" is a semantic requirement enforced at Authority Replay (any action at or after the revocation time on the revoked subtree is unauthorized, regardless of what a live cache believed). A revoked authority id MUST NOT be reused. Defined in: APQC-AUTH-006 §11.

Scope — the exact class of action and class of asset an authority permits, expressed as a bounded whitelist, never a role label or wildcard. Usage note: an authority permits precisely what it names and nothing adjacent; "Administrator" is not a scope, {action: convert, asset: estate/prod/tls-eu-*} is. A whitelist cannot widen by accretion, which makes scope creep visible in the graph rather than hidden in a role definition. Distinct from a role (which accretes meaning across systems). Defined in: APQC-AUTH-006 §6.1.

Simulation — the lifecycle stage (Stage 6) that predicts a plan's outcome before production execution, including predicted failures and blast radius. Holds no production authority. Usage note: the last, cheapest place to fail; a simulation that surfaces only the happy path is a demonstration, not a simulation. Its value is bounded by model fidelity, which SHOULD be checked against actual outcomes. Defined in: APQC-LIFECYCLE-004 Stage 6.

Substrate — the reference-implementation term for an Evidence Object: the canonical, compact, post-quantum-signed commitment that binds a transformation event to its authority, inputs, and outcome. Usage note: in normative text the neutral term is Evidence Object; "substrate" is the reference implementation's name for the same thing (a 74-byte artifact in the reference build). No substrate is emitted for an action lacking valid authority. Defined in: APQC-EVIDENCE-007 §3.1 (as Evidence Object); APQC-CORE-001 §8; APQC-REFERENCE-010.

Transformation — any governed change an autonomous system makes to a critical asset. Conversion is the transformation specific to the post-quantum workload; other workloads transform other asset classes. Usage note: the workload-general superclass; the lifecycle governs transformation in the abstract so one platform runs many workloads on one operational model. Defined in: APQC-GLOSSARY-000; APQC-MODEL-003 §3.

Understanding — the lifecycle stage (Stage 3) that turns raw Discovery observations into meaning: classification and dependency resolution, producing the structured Knowledge Graph including each asset's blast radius. Usage note: Discovery gives the Knowledge Graph its population; Understanding gives it its structure. Kept separate so classification errors are distinguishable from observation errors. Distinct from Discovery (raw sensing). Defined in: APQC-LIFECYCLE-004 Stage 3; APQC-MODEL-003 §3.3.

Validation — confirming that a transformed asset is correct and functional against its specification (e.g., known-answer tests, interoperability suites). A technique employed during verification, and one that may itself be recorded as evidence — but validation is not evidence. Distinct from verification (which confirms the change occurred as intended) and proof (the artifact). Conflating the two hides the difference between "we changed the wrong thing correctly" and "we changed the right thing incorrectly." Defined in: APQC-EVIDENCE-007 §1.1; APQC-LIFECYCLE-004 Stage 8.

Verification — the act of confirming that a transformation occurred as intended, independently of the actor. Verification is performed against evidence; its durable output is proof. Usage note: must include negative (deliberate-mismatch) tests proving that tampering would be detected — a verifier that only passes the happy path cannot detect tampering. Verification's independence from Execution is structural: the verifier must not consume the executor's success report as an input to its own conclusion. Distinct from validation (correctness against a spec), attestation (the signing mechanism), and proof (the artifact). Defined in: APQC-EVIDENCE-007 §1.1; APQC-LIFECYCLE-004 Stage 8; APQC-CORE-001 §7.

Workload — a class of lifecycle work distinguished by its asset type and transformation goal (e.g., Agentic Post-Quantum Conversion, Agentic Identity Modernization, Agentic PKI Modernization). All workloads share the lifecycle, the three graphs, and the five engines; only the meaning of "asset," "change," and "target state" varies. Usage note: generality means the decisions and their governance are invariant, not that the mechanisms are shared — converting a TLS endpoint has nothing in common with federating an identity. Because the lifecycle is shared, the system that runs it is a platform, not a tool. Defined in: APQC-CORE-001 §10; APQC-LIFECYCLE-004 §6.

3. Term relationships

Terms cluster into families; grouping them shows siblings, super/subclasses, and where confusion is likeliest.

  • The three graphs. Knowledge Graph (known — reality), Authority Graph (permitted — delegation), Evidence Graph (proven — verifiable history). Every workload maintains all three; a transformation missing one is blind, ungoverned, or unprovable respectively. Kept categorically separate because they fail differently — Governance joins Evidence against Authority as two independently-maintained graphs. An action is possible only at the Knowledge∩Authority intersection; the Evidence Object is the one place all three meet.
  • The five engines. Knowledge Engine (builds Knowledge), Authority Engine (builds Authority + the gate), Transformation Engine (acts — the only mutator of reality), Evidence Engine (builds Evidence), Governance Engine (reads all three, writes none). Three build state, one is action, one is oversight; each graph has one writing engine; maturity level = which engines are operated.
  • The authority family. Authority is the spine, with Authority Root (origin), Authority Graph (structure), delegation / monotonic delegation (edges and their rule), scope/lifetime/provenance/constraints (fields), revocation (withdrawal), Authority Replay (reconstruction), inconceivable / fail-closed (behavior on absent authority), and intent (the external root). Held apart from five neighbors: identity, authentication, authorization, capability, credential.
  • The evidence family. Evidence is the body; within it, the Evidence Object / substrate (atomic unit), commitment (its "what"), anchor (independent time), Chain of Evidence (ordering), Evidence Graph (the whole), Evidence Replay (reconstruction). Permanent contrast: the log. Four routinely-confused neighbors: verification (act), validation (correctness check), attestation (mechanism), proof (artifact).
  • The lifecycle-stage terms. In order: intent (1) → Discovery (2) → Understanding (3) → Authority Assignment (4) → Planning (5) → Simulation (6) → Execution (7) → Verification (8) → Evidence (9) → Governance (10) → Continuous Operation (11) → Continuous Adaptation (12, re-enters 1). Between stages sit gates; across all stages hold the three invariants; the loop never terminates, because of drift.

4. Not In Scope

This glossary does not define: cryptographic algorithm names (see NIST — e.g., ML-KEM, ML-DSA, SLH-DSA); vendor product names or the reference implementation's internal construction (see APQC-REFERENCE-010); wire formats, encodings, data models, or APIs (owned by the specs that use them and by the implementer); or workload-specific technical terms (defined per workload). It defines the vocabulary of the discipline, not of any implementation. Where a term's full semantics live in an owning specification, this glossary fixes the word and defers the full treatment via each entry's Defined in: pointer.