The Agentic Post-Quantum Conversion Constitution

A specification for the discipline of governed, autonomous, and cryptographically-proven post-quantum cryptographic conversion.

Document: APQC-CORE-001 — The APQC Constitution
Status: v0.2 — foundation stabilizing pre-publication. v0.1 → v0.2 absorbs the elevation of the discipline to workload-general agentic transformation and the three-graph core. Re-freezes as a published RFC once APQC-LIFECYCLE-004, APQC-AUTH-006, and APQC-EVIDENCE-007 validate the foundation.
Version: 0.2
Date: 2026-07-02
Editor / Authoring body: H33.ai, Inc.
Reference implementation: H33 (Agent-008, H33-Root, H33-Key, H33-74, HATS, Agent-Zero)

This document defines what the discipline is, in terms that any vendor, auditor, regulator, or researcher can adopt and cite. It is normative about the discipline and neutral about the implementer. Section 9 identifies the reference implementation.

The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are used per RFC 2119.

0. Front Matter

Every specification in the APQC corpus opens with these four sections.

0.1 Normative References

RFC 2119 — Key words for requirement levels.
NIST FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA).

0.2 Informative References

NIST SP 1800-38 — Migration to Post-Quantum Cryptography.
NIST SP 800-207 — Zero Trust Architecture.
U.S. CNSA 2.0; NSM-10; OMB M-23-02; CISA PQC guidance.

The full APQC corpus, APQC-CORE-001 through APQC-REFERENCE-010 (Appendix B).

0.4 Conformance Dependencies

None. APQC-CORE-001 is the root of the corpus; every other specification depends on it, and it depends on no other APQC specification.

1. Purpose

Post-quantum migration is mandated (NIST FIPS 203/204/205; U.S. CNSA 2.0 timelines), enterprise-wide in scope, and today performed by hand. The result is slow (measured in years), expensive (measured in millions), and — critically — unproven: an organization that completes a migration usually cannot produce independently-verifiable evidence of what was converted, when, by whom, and under whose authority.

This is not a tooling gap but a category gap. Existing practice treats cryptographic migration as a project — executed by people, recorded in logs, attested by testimony — and each of those three assumptions fails under enterprise conditions. A project ends; a cryptographic estate does not, because new classical primitives arrive continuously through deployments, rollbacks, and shadow systems. People do not scale to hundreds of thousands of assets across every region on a mandated timeline. And logs, however diligently kept, are editable by whoever runs the system and mortal with it — so at the moment auditing matters, the record is only as trustworthy as the operator whose conduct is in question. The consequence is the observation above: organizations finish migrations they cannot prove.

Agentic Post-Quantum Conversion (APQC) exists to make cryptographic conversion autonomous where safe, governed everywhere, and cryptographically proven end-to-end. This document is the source specification from which all APQC lifecycle, architecture, evidence, governance, and conformance definitions inherit. It replaces the three failing assumptions with three durable ones: work performed by governed agents (not people executing runbooks); every action bound to a rooted, revocable right to act (not to an operator's discretion); every material change leaving portable proof that outlives the tool, vendor, and personnel that produced it (not a log that dies with its system). Sections 2 through 14 make each precise, checkable, and vendor-neutral.

2. Definition

Agentic Post-Quantum Conversion (APQC) is the use of governed AI agents to discover, analyze, convert, validate, and continuously maintain an organization's cryptographic infrastructure — migrating classical primitives (RSA, ECC, finite-field DH) to NIST-standard post-quantum algorithms — while producing portable, replayable, cryptographically-verifiable evidence of every change.

APQC is distinguished from adjacent practices by three mandatory properties. A process that lacks any one of them is not APQC:

Agentic — the work is performed by autonomous agents operating a defined lifecycle, not by humans executing a runbook.
Governed — every agent action is bound to delegated authority; an agent MUST NOT be able to exceed the authority it was granted.
Proven — every material change produces independent, offline-verifiable cryptographic evidence; assertion is not evidence.

The one-sentence test a competitor cannot pass by adding an LLM: autonomous cryptographic transformation, under cryptographic governance, with cryptographic proof of every change.

A worked example, to fix the boundary. Consider three organizations that each claim to be "modernizing cryptography with AI." Organization X runs an LLM assistant that reads configs, summarizes RSA usage, and drafts a runbook engineers then execute by hand — a human-run migration with an AI assistant: no agent acts, no authority binds action to a right, no evidence beyond editable tickets. It fails all three properties. Organization Y runs a script fleet that rotates certificates estate-wide on a schedule; the scripts act autonomously and at scale, but any script can change any certificate and the only record is its own log — static automation without an authority model (GLOSSARY-000 defines Agentic to exclude it): a shadow of property 1, a failure of properties 2 and 3. Organization Z runs discovery, planning, and execution agents that each hold a scoped, time-bounded, revocable grant traceable to an Authority Root; an execution agent given an out-of-scope action fails closed and changes nothing; and every conversion seals a portable, offline-verifiable proof binding what changed, when, by whom, and under whose authority. Only Z is doing APQC.

The discriminating fact is not that Z uses AI — all three do — but that Z's autonomy is bounded by authority and its changes are proven, not asserted. Everything downstream exists to make Z's posture specifiable, checkable, and reproducible.

2.1 A general discipline; APQC is its first workload

Although this corpus is named for post-quantum conversion, the lifecycle (§6) and the three-graph core (§2.2) describe the governed, autonomous, cryptographically-proven transformation of critical infrastructure in general. Post-Quantum Conversion is the first and reference workload; Identity, PKI, Secrets, Cloud, and Compliance are others (§10). The workload changes; the lifecycle does not — which is precisely why the system that runs it (§10) is an operating system, not a tool.

The generality is a structural consequence of framing the lifecycle around decisions rather than technology (§6). The decisions required to transform critical infrastructure safely — what is intended, what exists, what it means, who may act, what to do, what would happen, doing it, confirming it, proving it, judging it, watching it, adapting — are invariant across workloads; only the meaning of "asset," "change," and "target state" varies. Because the decisions and their governance are shared, the machinery that governs and proves them is shared, and one platform can run many workloads on one operational model. APQC-LIFECYCLE-004 demonstrates this by carrying a second, non-cryptographic workload (identity modernization) through the identical twelve stages.

2.2 The three graphs (Knowledge · Authority · Evidence)

Every stage of every workload advances one or more of three graphs. Together they are the intellectual core of the discipline:

Knowledge Graph — what is known: the estate and its dependencies.
Authority Graph — what is permitted: delegation — who may act, on what, within what bounds.
Evidence Graph — what is proven: the cryptographically-verifiable history of what was actually done.

A transformation missing one of the three is, respectively, blind, ungoverned, or unprovable. The lifecycle exists to build and maintain all three. (Full treatment: APQC-MODEL-003; per-stage detail: APQC-LIFECYCLE-004.)

Why three graphs and not one. A naive design collapses all three into a single "facts about the estate" database. The discipline refuses this because the three fail categorically differently, and only their separation makes the most dangerous failure detectable. Knowledge can be wrong (stale, incomplete) with no action illegitimate. Authority can be correct while Knowledge is wrong — a perfectly-governed action on a misunderstood asset. Evidence can be complete while Authority was over-broad — every action proven, some that should never have been permitted. Keeping them separate lets Governance (Stage 10) ask "did execution stay inside authority?" as a join between two independently-maintained graphs rather than a tautology. Conflate them and that question is unanswerable: a well-evidenced but never-authorized action becomes indistinguishable from a legitimate one. The separation is what makes self-authorization detectable. An action is conceivable only where a Knowledge asset and an Authority grant intersect; the Evidence Graph records, at that intersection, what was done and under which right — closing the loop between permitted and proven.

3. Scope

In scope. Discovery and inventory of cryptographic assets; classification and risk analysis; migration planning and sequencing; execution of conversions (hybrid and drop-in); validation of correctness; production of conversion evidence; authority and governance of the agents performing the work; continuous re-verification against drift; and the re-entry of the lifecycle when intent, environment, or standards change. In short, APQC governs the full closed loop from authorized intent to proven change to continuous re-verification, for the cryptographic-conversion workload and — via the shared lifecycle — for the workloads that inherit it (§10).

Out of scope (of this document). Selection or design of specific post-quantum algorithms (defined by NIST); the internal construction of any single vendor's agents; the mechanism of any individual conversion (how a TLS endpoint is re-keyed, how a signing pipeline is re-plumbed); the data model, storage, or query implementation of the three graphs (conceptual treatment is APQC-MODEL-003; realization is APQC-ARCH-005 and APQC-REFERENCE-010); and organizational change management. APQC governs how cryptographic change is performed and proven, not which algorithm is correct — that is settled by the standards in Section 12.

Explicitly not APQC. The following common practices resemble APQC and are not it; each fails at least one of Section 2's mandatory properties. Naming them is normative, so a reviewer can classify a candidate program.

(a) Human-run migration with an AI assistant. A person executes the runbook; the AI summarizes or drafts steps. Fails "agentic": no agent holds authority and acts. (Organization X, §2.)
(b) Automated scripting without an authority model. Scripts change the estate autonomously, but any script may change anything and no bounded, revocable grant makes over-reach impossible. Fails "governed": over-reach is disallowed by convention, not by structure. (Organization Y, §2.)
(c) Discovery/inventory tooling that does not convert. A scanner builds an inventory but performs no transformation. Fails "agentic" on the transformation half: it advances the Knowledge Graph only. Discovery is a stage of APQC (§6), not APQC.
(d) Conversion that cannot be independently verified. A change is made and logged, but no third party can confirm it without trusting the tool. Fails "proven": assertion is not evidence (§8).
(e) A well-run SIEM presented as an audit trail. Every change is logged in write-once storage with tight access controls and declared "fully auditable." Fails "proven": a log is editable by its operator, meaningful only in its native system, mortal with it, and cannot prove completeness (a missing line leaves no line). Access control makes tampering harder without changing the trust model, which remains "trust the operator." The most seductive non-APQC pattern, because it looks the most complete. (§8.)
(f) A conversion performed under a self-generated key. The change is signed and the signature verifies, but the key was minted by the actor, not delegated from a Root. Fails "governed": validity is a mathematical property of a signature relative to a key; it says nothing about whether the signer was permitted. A party that generates its own keys has valid signatures and zero authority (§9; APQC-AUTH-006 §2.5).

These are predecessors to, or counterfeits of, APQC — not instances of it. The line is the three mandatory properties, and Section 14 makes it checkable.

4. Principles

The seven principles below are the load-bearing commitments of the discipline. Each is stated normatively, then given its rationale and the concrete failure that results if it is absent — a principle whose violation causes no failure is decoration. They are seven faces of one commitment: that autonomous change to critical infrastructure must be bounded before it acts and provable after. They are numbered P1–P7, referenced by ID throughout the corpus, and not renumbered by later versions.

P1 — Proof over assertion.

Every material change MUST emit evidence that a third party can verify without trusting the tool that produced it.

Rationale. Trust extended to the producer is not proof; it is testimony. A conversion record's value is realized precisely when the producer cannot be trusted or reached — during an audit of the producer's own conduct, after the vendor is gone, years later before a regulator or insurer. Evidence therefore moves the root of trust off the producer's word onto mathematics and independent anchors (APQC-EVIDENCE-007 §2).

Failure if absent. Without P1 a program produces logs, and logs cannot answer what auditing demands: prove — to me, who does not trust you and cannot inspect your systems — that this change occurred, at that time, under proper authority, with nothing missing. The logs are only as trustworthy as the operator whose conduct is in question; the emitting system may be gone or unreadable; and completeness is unprovable because a missing line leaves no line. The "fully auditable" migration becomes unprovable — and unprovable is indistinguishable from did not happen — the exact failure §1 names as today's state of practice.

P2 — Authority precedes action.

An agent MUST hold valid, scoped, unexpired, unrevoked authority before acting. Absent authority, the action MUST NOT occur and no evidence is issued.

Rationale. An agent has no career, manager, badge, or conscience; it has exactly the authority delegated to it. A human who exceeds their role can be counseled; an agent that exceeds its authority simply acts — at machine speed, across an entire estate (APQC-AUTH-006 §1). Safety cannot rest on the agent's good behavior; it must rest on a structure that makes over-reach not merely disallowed but inconceivable: an action for which no path exists in the Authority Graph produces no effect and no evidence.

Failure if absent. Without P2 autonomy amplifies error and compromise — a single misdirected or subverted agent exercises whatever it can reach, on every asset it can touch, without pausing. This is the confused-deputy and broken-access-control class of incidents (APQC-AUTH-006 §2.1–2.2) scaled to machine speed. And because an unauthorized action that leaves a record poisons the governance join (§2.2, Stage 10), the corruption is not contained — it makes the whole population's governance statement unsound.

P3 — Autonomy is earned, not assumed.

The degree of unattended autonomy is a function of demonstrated reliability and risk (see the Maturity Model, Section 13). Full autonomy is the ceiling, not the default.

Rationale. Trust in an autonomous system is a gradient, not a switch, and should track evidence of reliability rather than optimism. The Maturity Model (§13) makes the gradient explicit: unattended execution is earned by first demonstrating governed, human-gated conversion that produces verifiable proof. Autonomy is granted where evidence of safe operation has accumulated and withheld where it has not.

Failure if absent. Without P3 a program either over-trusts — handing full unattended reach to unproven agents, so the first novel failure occurs at maximum blast radius — or over-controls, gating every action on a human and destroying the scale and continuity that motivated agentic conversion. P3 prevents both the reckless deployment and the theatrical one, tying the amount of autonomy to earned confidence so the system is never trusted more than it has been shown to deserve.

P4 — Least exposure.

Agents SHOULD operate on sensitive material (keys, secrets, regulated data) without being able to read it. Conversion does not require exposure.

Rationale. A conversion changes a primitive's use, not its contents. An execution agent can orchestrate a key rotation inside an HSM or re-bind a credential without the private material ever entering its memory. Because exposure is unnecessary to the task, permitting it adds only risk. This is invariant I3 (APQC-MODEL-003 §4) and the reason evidence commits to a change rather than copying it (§8).

Failure if absent. Without P4 every agent and context window that touches a conversion becomes a new place a key or secret can leak — threat T5 (§11). A compromised agent's blast radius expands from "the actions it can take" to "the secrets it has seen," and the evidence artifacts themselves risk carrying sensitive content into decades-long retention. Least exposure keeps sensitive material where it belongs and makes the proof safe to hand to anyone, forever.

P5 — Reversibility and staging.

Conversions SHOULD be stageable and, where feasible, reversible; hybrid classical+PQ deployment is the default de-risking posture during transition.

Rationale. Cryptographic changes have dependencies and blast radius (APQC-LIFECYCLE-004 §Stage 3), and the cheapest place to discover a failure is before it is irreversible. Staging lets low-blast-radius changes build confidence before high-blast-radius ones proceed; reversibility lets a misbehaving change be withdrawn without a crisis; and hybrid deployment lets an estate gain post-quantum assurance while remaining interoperable with parties not yet converted.

Failure if absent. Without P5 a single conversion becomes an all-or-nothing bet on a change with hundreds of dependents. The archetype (APQC-LIFECYCLE-004 §Stage 3, §Stage 5) is a code-signing key with 312 downstream artifacts: rotated in place with no dual-signing path and no reversal, it invalidates every previously-signed artifact at once. Irreversibility turns a recoverable mistake into an outage; the absence of a hybrid posture turns a transition into a hard cutover that breaks every partner not converted in lockstep.

P6 — Continuity.

Cryptographic estates drift. APQC is an operating model, not a project; it MUST include continuous re-verification.

Rationale. An estate is a live population, not a fixed list (GLOSSARY-000: Estate). Classical primitives reappear after conversion through stale templates, rollbacks, and shadow systems (GLOSSARY-000: Drift). A discipline that treats conversion as terminal is wrong the moment the next deployment lands. Continuity is the closing edge (Stage 11 → 12) that turns a project into an operating model: the loop re-enters itself, and there is no "done."

Failure if absent. Without P6 drift accumulates invisibly between audits. A program declares itself "converted," monitoring stops, and classical primitives return through the channels nobody watched — the provisioning templates and pipelines that spawn new assets. By the next audit the estate has silently regressed. Continuity also handles cryptographic-agility failure (T7): when an algorithm is later deprecated, only a continuous loop can re-convert without a fresh, ad-hoc project.

P7 — Portability of evidence.

Evidence MUST outlive the tool, the vendor, and the system that produced it, and MUST be verifiable offline for the full retention horizon (years to decades).

Rationale. A conversion record's retention horizon is the confidentiality horizon of the data it protects — years to decades. Over that span tools are replaced, vendors fail, formats are deprecated, and teams turn over. Evidence that depends on any of these to be verified is not durable proof; it is a hostage to its producer's survival. Portability requires that an object be self-describing (it names its own parameter set) and that verification depend only on the object plus public parameters, never on a live service (APQC-EVIDENCE-007 §6.3–6.5).

Failure if absent. Without P7 evidence dies with its system. The insurer three years after a breach, handed vendor-locked records verifiable only inside a now-bankrupt platform, can prove nothing (APQC-EVIDENCE-007 §7.3). This is the survivability failure — "delete the producer" and verification collapses — and it retroactively voids every proof the program ever produced. Portability is what makes P1 durable: proof that cannot travel and cannot outlive its producer is proof only until it is needed.

Why these seven. They are the minimum set that closes the three category-failures of §1. P1 and P7 make change provable and durably so (defeating the "unproven migration"); P2 and P3 make autonomy bounded and earned (defeating ungoverned automation); P4 keeps the bounded, provable action from creating a new exposure; P5 and P6 make the discipline operable over time (defeating the "project that ends"). Remove any one and a named failure re-opens; add an eighth and it reduces to a corollary of these. The principles map to the operational invariants of APQC-MODEL-003 §4 (I1 ↔ P1, I2 ↔ P2, I3 ↔ P4) and to the normative requirements of APQC-AUTH-006 §15 and APQC-EVIDENCE-007 §10.

5. Terminology

This section fixes the terms this Constitution uses. The single authoritative dictionary for the whole discipline is APQC-GLOSSARY-000, which every specification (including this one) uses exactly as defined there; the entries below are the Constitution-level subset, consistent with the Glossary and non-substitutable with it.

APQC — Agentic Post-Quantum Conversion, as defined in Section 2. (Distinct from unrelated organizations sharing the acronym; within this discipline the term always expands to Agentic Post-Quantum Conversion.)
Cryptographic asset — any use of a cryptographic primitive: a key, certificate, TLS endpoint, signing operation, protocol handshake, library call, HSM slot, or secret.
Classical primitive — a pre-quantum algorithm (RSA, ECC/ECDSA/ECDH, finite-field DH) vulnerable to a cryptographically-relevant quantum computer.
PQ primitive — a NIST-standardized post-quantum algorithm: ML-KEM (FIPS 203), ML-DSA (FIPS 204), SLH-DSA (FIPS 205).
Conversion — replacing a classical primitive's use with a PQ (or hybrid classical+PQ) primitive, in production, verifiably. (In Glossary terms, conversion is the specific transformation of the post-quantum workload.)
Authority — a scoped, delegable, revocable, time-bounded right to perform a specified class of action, rooted in a verifiable trust anchor. Distinct from a mere permission flag (which is neither delegable nor provable) and from policy (which constrains how authority may be used).
Evidence / Proof — a portable artifact that lets a third party independently confirm that a change occurred as claimed, without trusting the issuer. Distinct from a log (editable, issuer-bound, mortal with its system).
Substrate — the canonical, signed commitment that binds a conversion event to its authority, inputs, and outcome; the atomic unit of the Evidence Graph (reference implementation: H33-74).
Drift — the reappearance of classical primitives after conversion (new deployments, rollbacks, shadow systems).
Workload — a class of cryptographic-lifecycle work performed by the platform (APQC is Workload 1; see Section 10).

Where common usage treats verification, validation, proof, and attestation as interchangeable, the discipline makes them distinct and non-substitutable; the canonical definitions and their "distinct from" notes are in APQC-GLOSSARY-000 and are normative wherever these terms appear.

6. Lifecycle

The discipline defines a twelve-stage, decision-based lifecycle — framed around what an autonomous system decides and proves, not around a specific technology, so it holds for every workload (§10). Each stage has an objective, inputs, outputs, a required authority, and evidence it MUST produce; the stages are ordered but iterative — Stage 12 re-enters Stage 1. APQC-LIFECYCLE-004 specifies each stage in full.

Intent Established — what business outcome is being authorized?
Discovery — what exists?
Understanding — what does it mean?
Authority Assignment — what is each agent allowed to do?
Planning — what sequence of changes satisfies the intent?
Simulation — what would happen if executed?
Execution — make governed changes.
Verification — did the changes occur as intended?
Evidence — produce immutable, portable proof binding who, what, when, and under whose authority.
Governance — evaluate policy, authority, and risk.
Continuous Operation — monitor for drift.
Continuous Adaptation — re-enter the lifecycle as the environment changes.

Every stage's evidence MUST be independently verifiable (P1) and portable (P7), and every stage advances the three graphs of §2.2.

The lifecycle is framed around decisions rather than tools deliberately: primitives, libraries, and products change on a months-to-years horizon, but the decisions required to transform critical infrastructure safely — and prove it was done correctly — do not, so a specification anchored to the decisions outlives the technology that satisfies it (P7). The stages are ordered (each consumes the previous stage's output) and never-terminating (Continuous Operation feeds drift into Continuous Adaptation, which re-scopes Intent and re-opens the cycle); there is no terminal state — an estate is operated, not finished (P6). Between each pair of stages is a machine-checkable gate, and two are fail-hard: Simulation→Execution (an unresolved material predicted failure MUST NOT be waved through) and Execution→Verification (a change without valid authority at the moment of action MUST fail closed, no effect, no evidence). APQC-LIFECYCLE-004 §5 specifies every gate.

7. Roles

APQC is a division of labor between agents, humans, and the authority fabric. The division is not administrative; it is a safety boundary. Agents that sense must not be able to act, agents that act must do so only within delegated bounds, humans set the ceiling on autonomy without performing the toil, and verifiers must be able to check the result without trusting any of the above.

Discovery / Analysis agents — perform the sensing, understanding, and planning stages. They read broadly and propose; they hold no standing authority to change. The separation is enforced by authority, not by identity: a discovery agent and an execution agent may run under the same service identity, and only their grants distinguish read-and-classify from convert (APQC-AUTH-006 §2.1). A discovery agent that "fixes" a misconfiguration it finds has violated the boundary and the invariant I2 (APQC-LIFECYCLE-004 §Stage 2).
Execution agents — perform the Execution stage, strictly within the authority assigned in Authority Assignment, presented at the moment of each action. An out-of-scope or expired action fails closed and produces nothing. Execution agents operate under least exposure (P4): they transform sensitive material without reading it.
Human authorizers — grant, scope, and revoke authority; approve conversions until the maturity level permits unattended execution. Humans set the ceiling on autonomy (P3) and enter intent from outside the system (the one authority not derived by delegation; APQC-LIFECYCLE-004 §Stage 1). They do not perform the toil, and they hold no standing execution authority — approval rides down the delegation chain as an inherited constraint (APQC-AUTH-006 §8), not as a human hand on every change.
Verifiers — any third party (auditor, regulator, insurer, customer, or the organization itself) who checks the evidence. A verifier MUST be able to do so offline, without contacting the issuer, for the full retention horizon. This is the role the entire evidence model serves: verification that requires the producer's cooperation is testimony, not proof (P1, P7).
The authority fabric — the trust anchor and delegation chain that makes P2 enforceable: the Authority Root and the graph of scoped, time-bounded, revocable grants descending from it (reference implementation: H33-Root). The fabric makes over-reach inconceivable rather than merely disallowed.

The roles map onto the three graphs — Discovery/Analysis agents build Knowledge, human authorizers and the authority fabric build Authority, execution and verification produce Evidence, and verifiers consume all three. No single role can both act and vouch for its own action, which is what makes the discipline auditable.

8. Evidence Model

The output of the Evidence stage (Lifecycle Stage 9) is a substrate: a compact, canonical, post-quantum-signed commitment that binds a conversion event to its context. A conforming substrate MUST:

Commit, not expose — carry a cryptographic commitment (e.g., SHA3-256) to the change without revealing sensitive inputs. (P4) This is why one artifact can serve both the regulator who must verify existence and the confidentiality regime that must not leak: the commitment is always safe to publish; disclosure of the underlying bytes is a separate, later act to an entitled party (APQC-EVIDENCE-007 §13.1).
Bind who/what/when/authority — the acting identity, the action, the timestamp, and the delegated authority under which it occurred. Binding authority, not merely identity, is what makes the record governable: a signature proves a key signed; only the authority binding proves the signer was permitted (§9; APQC-AUTH-006 §2.5).
Be post-quantum signed — the reference implementation uses multiple independent signature families (e.g., ML-DSA, FALCON, SLH-DSA), so the evidence survives the failure of any one family and the arrival of quantum adversaries. A verifier requires a quorum of families to pass, so no single family's break silently validates a forgery (APQC-EVIDENCE-007 §13.2).
Be portable and offline-verifiable — verifiable for the full retention horizon with no dependency on the issuing vendor. (P7)
Be replayable — sufficient to deterministically reconstruct the event, so an incident can be examined like a recording rather than inferred from logs (APQC-EVIDENCE-007 §9).
Be complete over scope — the set of substrates for a declared population MUST be provably whole, so that "we converted everything" is verified against a pre-committed set rather than asserted; a missing conversion MUST surface as a named, detectable gap, not silence (APQC-EVIDENCE-007 §6.2).
Be anchorable — its commitment MAY be anchored to one or more public ledgers to provide an independent, tamper-evident timestamp no party (including the issuer) can alter.

Reference implementation: H33-74, a 74-byte post-quantum attestation substrate. A decade of per-change evidence at this size is measured in gigabytes, not terabytes — small enough to retain forever and hand to anyone.

Distinction from logs. A log is an editable, issuer-bound assertion that dies with its system; its trust model is "trust the operator." A substrate is portable, independently verifiable proof whose trust model is "trust mathematics and public parameters." They are not points on a spectrum but different kinds of object; APQC requires the latter (P1), and substituting the former is the most common way a program fails to be provable (APQC-EVIDENCE-007 §2). The operative test is delete the producer: hand a third party only the artifacts and public parameters, remove the vendor, database, and team, and see whether verification still succeeds. If it does, it was evidence; if not, it was a log.

9. Governance and Authority

APQC's safety rests on the authority model, not on the agents' good behavior. Full treatment is APQC-AUTH-006; the Constitution-level requirements are:

Authority MUST be scoped (to a class of action and asset, as a bounded whitelist — never a wildcard or a role label), delegable (down a verifiable chain, monotonically decreasing so no delegate exceeds its delegator), time-bounded (standing, unexpiring authority MUST NOT exist), and revocable (immediately, propagating to the whole descendant subtree, and itself evidenced).
Every agent action MUST present valid authority at execution time; an action outside scope MUST fail closed and produce no effect and no evidence. (P2) Within the discipline this is stronger than "denied": an action for which no valid path exists is inconceivable — it leaves nothing an attacker can build on and nothing an auditor must sift (APQC-AUTH-006 §4.2).
Authority MUST be rooted in a verifiable trust anchor, and the chain from root to action MUST be independently reconstructable offline, as of the moment the action occurred (Authority Replay; reference implementation: H33-Root). Un-rooted authority is treated as no authority — there is no partial credit.
Governance evidence (Stage 10) MUST make it possible to prove, after the fact and over the whole population, that no action exceeded its authority — expressed as a join of the Evidence Graph against the Authority Graph, held constant and judged, never mutated to make an action retroactively legitimate.

Consequence. An adversary cannot forge a governed conversion by generating their own keys. Two attestations may both be valid signatures over "certificate C was converted at time T" — one by an agent holding a grant traceable to the organization's Root, one by a party who minted a keypair last night. Both signatures verify. Only the first is authority-backed. A verifier who checks signature validity accepts both; a verifier who checks authority — does a rooted path permit this action at that time? — accepts only the first. The discipline is the machinery that makes that second check possible offline, years later. A signature proves a key signed; APQC evidence proves the signer was authorized to make that specific change.

10. Workload Catalog (the platform relationship)

APQC is the first workload of a broader operating model for governed cryptographic infrastructure. The same lifecycle, authority model, and evidence model generalize to:

Agentic Post-Quantum Conversion — this document.
Agentic PKI Modernization
Agentic Secrets Modernization
Agentic Certificate Lifecycle
Agentic Identity Modernization
Agentic Compliance Automation
Agentic Cryptographic Governance

Because all workloads inherit Sections 6–9, the orchestration layer that runs them is, by definition, an operating system for governed cryptographic work. Workload generality means the decisions and their governance are invariant; it does not mean the mechanisms are shared — converting a TLS endpoint has nothing in common with federating an identity, and this Constitution says nothing about either mechanism (§15). What is shared is that both must establish bounded intent, discover with stated coverage, understand blast radius, derive authority from intent, plan reversibly, simulate before production, execute under authority and least exposure, verify independently, seal portable proof, govern population-wide, monitor for drift, and adapt. The mechanism is the workload's business; the decision sequence is the discipline's — which is why the system that runs it is a platform, not a tool. APQC-LIFECYCLE-004 §6 demonstrates the claim by driving identity modernization through the identical twelve stages.

Reference implementation: Agent-008 as the orchestrator, with H33-Key (credential-bound execution without exposure), Agent-Zero (analysis without data exposure), H33-74 (proof), H33-Root (authority), and HATS (continuous compliance evidence) as the supporting layers.

11. Threat Model

APQC MUST defend at least the following seven threats. Each is stated with a concrete scenario and the principle or mechanism that mitigates it; a program that cannot answer each threat with a specific mechanism is not conformant.

T1 — Forged conversion. Scenario: an actor records a "converted" entry for an endpoint that still presents RSA-2048, or presents a self-signed attestation of a change that never happened. Mitigation: the Evidence-stage substrate binds the change to a rooted authority path and is independently verifiable offline (§8–9, P1). A forged claim either has no valid authority path — so no conforming evidence can exist for it — or fails signature/anchor verification. The claim is checked against mathematics, not accepted on the actor's word.
T2 — Unauthorized action. Scenario: a buggy or compromised agent acts beyond its scope — converting a database when its grant covers only TLS endpoints, or reusing an expired grant after its window closed. Mitigation: fail-closed authority (P2, §9). The action finds no valid path in the Authority Graph, so it is inconceivable: no effect, no evidence. Over-reach is made structurally impossible, the only defense that holds at machine speed across an estate.
T3 — Silent regression / drift. Scenario: six weeks after a conversion, a load balancer built from an old template serves RSA-2048 on eight endpoints inside converted scope; nobody notices because monitoring stopped when the project was "done." Mitigation: Stages 11–12 under P6. Monitoring is continuous and covers the provisioning channels that spawn new assets, not only assets already converted; drift is characterized, emitted as evidence, and re-opens the lifecycle under fresh authority. A project that ends cannot defend this threat.
T4 — Evidence tampering / backdating. Scenario: an operator deletes a non-compliant conversion's evidence object from a chain, or rewrites a timestamp to move a freeze-window violation earlier. Mitigation: intrinsic integrity plus tamper-evident chaining plus public-ledger anchoring (§8, P7; APQC-EVIDENCE-007 §5, §7). Deleting an object breaks the hash-link at that position and all after it, so the deletion is proven; a rewritten timestamp is contradicted by the anchor's independent existence-at-a-time. Integrity rests on signatures over canonical bytes, not on access control — because possession of a store must not suffice to alter history.
T5 — Exposure during conversion. Scenario: to "make signing easier," a signing private key is read into an execution agent's context, where it lives in logs, prompts, and retained evidence and leaks on the agent's compromise. Mitigation: least-exposure execution (P4; invariant I3). The new key is generated and used inside the HSM; the agent orchestrates without reading it. Evidence commits to the change rather than copying it, so the proof carries no secret into long retention.
T6 — Harvest-now-decrypt-later. Scenario: an adversary records today's classically-encrypted long-lived confidential traffic to decrypt once a cryptographically-relevant quantum computer exists; data with a ten-year confidentiality horizon is exposed the day that capability arrives. Mitigation: the reason for urgency, addressed by prioritization: Understanding and Planning MUST weight long-lived confidential data highest (§6; APQC-LIFECYCLE-004 §Stage 1, §Stage 5), converting first the assets whose confidentiality must outlive the transition. The threat is defeated by ordering the program around confidentiality horizon, not by any single conversion.
T7 — Cryptographic-agility failure. Scenario: two years on, a deployed ML-DSA parameter set is deprecated; a program that treated conversion as one-time has no path to re-convert without a fresh, ad-hoc migration. Mitigation: the lifecycle is continuous by design (P6). A deprecated standard arrives at Stage 12 as a changed standard, opening a new cycle that re-converts under fresh authority exactly as a first cycle did — no special case. Agility is a property of the loop, not a bolt-on.

An eighth candidate — silent authority creep, roles accreting permission over time — is not listed separately because it is defeated by construction: authority is a bounded whitelist, never a role, so scope cannot widen by accretion (APQC-AUTH-006 §6.1). Threats APQC does not defend (physical HSM compromise, a break in a NIST primitive itself) belong to the underlying standards (§12).

12. Standards Mapping

APQC is a governance-and-evidence discipline layered on top of the cryptographic standards; it governs how cryptographic change is performed and proven, while the standards below settle which cryptography is correct.

NIST FIPS 203 (ML-KEM), 204 (ML-DSA), 205 (SLH-DSA) — the target primitives for Stage 7. APQC converts to these; it does not define them.
NIST SP 1800-38 (Migration to PQC) — the discovery/inventory practice APQC automates and evidences (Stages 1–4).
U.S. CNSA 2.0 / NSM-10 / OMB M-23-02 — the mandate and timelines that make Stage 4 prioritization non-optional and give the intent (Stage 1) its regulatory driver.
CISA PQC guidance — inventory and prioritization expectations APQC satisfies with evidence, not a spreadsheet.
NIST SP 800-207 (Zero Trust) — the authority posture APQC extends to cryptographic change, making the "verify" leave behind a rooted, replayable authority record (APQC-AUTH-006 §14).
Common Criteria / FIPS 140-3 — the validation context for Stage 8.

The relationship is strictly layered: NIST defines the algorithms; APQC governs and proves their deployment. A break in a primitive is a standards problem (handled by re-standardization and, in APQC, by the continuous loop, T7), not an APQC conformance failure.

13. Success Criteria and Maturity Model

An organization's APQC maturity is defined on six levels. Maturity measures how much autonomy has been earned (P3) and how continuous the operation is (P6); it does not relax proof or authority, invariant from Level 3 up.

Level 0 — Unknown. No cryptographic inventory exists.
Level 1 — Inventory. Assets are discovered and catalogued (Knowledge Graph has population).
Level 2 — Visibility. Assets are classified and prioritized by risk and mandate, with blast radius understood (Knowledge Graph has structure).
Level 3 — Governed Conversion. Conversions execute under delegated authority and produce verifiable proof, human-gated. From here up, proof (P1) and authority (P2) are invariant; only autonomy increases.
Level 4 — Continuous Conversion. Drift is detected and re-converted continuously; proof is emitted throughout, including clean-interval receipts that distinguish "checked-and-conformant" from "not checked."
Level 5 — Autonomous Cryptographic Infrastructure. Conversion runs unattended within authority, proof and governance invariant; humans set the ceiling and intervene by exception.

Autonomy increases with level; proof and authority are invariant at every level from 3 up (P1, P2, P3). A program MAY describe partial adoption by level but MUST NOT call itself "APQC" below the bar Section 14 sets. The full model is APQC-MATURITY-008.

14. Conformance

A process is APQC-conformant if and only if it satisfies all three of the following, each independently checkable:

(a) Lifecycle. It implements the Section 6 twelve-stage lifecycle, including its ordering and gates. Checkable by: every stage output traces to a signed intent (CT-1.1, APQC-LIFECYCLE-004); the two fail-hard gates are enforced — a material predicted failure never proceeds to Execution, and a change without authority at the moment of action fails closed.
(b) Authority. It enforces the Section 9 authority model such that unauthorized actions fail closed — producing no effect and no evidence. Checkable by: an out-of-scope or expired action changes nothing and emits no substrate (CT-A5, APQC-AUTH-006); every action resolves to exactly one grant traceable to a Root; a self-minted attestation is rejected for lack of a rooted path (CT-A8b).
(c) Evidence. It emits, for every material change, Section 8 evidence that a third party can verify offline, without contacting the issuer, and it can prove completeness over a pre-committed scope. Checkable by: the "delete the producer" test succeeds (CT-E5, APQC-EVIDENCE-007); a removed object surfaces as a named missing asset, not silence (CT-E1a); a tampered field breaks a signature (CT-E3); no object exists for an unauthorized action (CT-E2a).

All three are necessary and jointly sufficient; a process missing any one is not APQC however well it does the others (a perfectly-governed, well-evidenced program that never converts is not APQC; a fully-autonomous converter with no authority binding is not APQC). Partial adoption MAY be described by maturity level (§13) but MUST NOT be called "APQC" without all three of Section 2's mandatory properties. A conformance statement SHOULD name, for each of (a)/(b)/(c), the downstream conformance tests it satisfies, and MUST justify any SHOULD-level test it does not.

Conformance is a floor (all three properties present); maturity (§13) is a gradient above it (how much autonomy is earned, how continuous the operation). An organization can be conformant at Level 3 and grow to Level 5 without re-crossing the conformance boundary, because proof and authority — the load-bearing halves of conformance — are invariant across those levels.

15. Design Rationale — why these, and not others

This section records the design choices and the rejected alternatives, so a future reader — or a competing implementer — can see the design is deliberate. Each rejected alternative is a real, common design a reasonable team might reach for.

Decision-based stages, not technology-based phases. Rejected: a Discover → Convert → Verify lifecycle organized around the technology of the day — it anchors the spec to primitives and tools that change on a months-to-years horizon (violating P7) and is PQC-specific by construction. Accepted: twelve stages framed around decisions, invariant across workloads and decades (§2.1).
Three graphs, not one store of facts. Rejected: a single "estate database." Accepted: Knowledge / Authority / Evidence separated (§2.2), because a unified store cannot answer "did execution stay inside authority?" without begging the question — only the separation makes a well-evidenced but never-authorized action detectable.
Authority, not permissions/RBAC/IAM. Rejected: the right to act as a role or a permission-table lookup — roles accrete permission (scope creep), tables drift across replicas, instant authorization discards the reasoning. Accepted: authority as a rooted, bounded, delegable, revocable, replayable object (§9; APQC-AUTH-006) that keeps the reasoning as a first-class, portable object.
Evidence, not logs. Rejected: "log everything to a hardened SIEM and call it auditable" — a log's trust model is "trust the operator," it cannot prove completeness, and it dies with its system. Accepted: portable, independently-verifiable, complete-over-scope proof (§8; APQC-EVIDENCE-007).
Commit rather than copy. Rejected: retaining copies of the changed material (leaks secrets, grows without bound). Accepted: a hiding, binding commitment (§8, P4) that proves what changed to a party holding the original bytes while revealing nothing to others — serving both the regulator who must verify and the confidentiality regime that must not leak.
Multiple signature families, not one. Rejected: a single post-quantum signature — one point of cryptographic failure. Accepted: a quorum of independent families (§8; APQC-EVIDENCE-007 §13.2), so tamper-evidence survives a single cryptanalytic break and old evidence stays verifiable while new production adopts stronger parameters (P7).
Continuous, not a project. Rejected: conversion as a milestone with an end date. Accepted: an operating model with no terminal state (P6); the closing edge (Stage 11 → 12) turns a program that silently regresses into one that stays converted, absorbing algorithm deprecation (T7) without a special case.
Earned autonomy, not full autonomy by default. Rejected: unattended agents from day one (first novel failure at maximum blast radius) or full human gating (destroying the scale that motivated agentic conversion). Accepted: autonomy as a gradient tied to demonstrated reliability (P3, §13).

The discipline's contribution is not any single choice but their composition into a system where autonomy is bounded before it acts and provable after — which no adjacent framework delivers whole.

16. Relationship to the corpus — how the downstream specs inherit from this root

This Constitution is the normative root; every other specification in the corpus (Appendix B) elaborates one part of it and depends on it. Each downstream spec names CORE-001 in its Conformance Dependencies, and each tightens the root — adding operational detail — but never loosens it. The inheritance map:

GLOSSARY-000 — terminological root beneath all (including this Constitution); the single authoritative dictionary of which §5 is the Constitution-level subset.
PROBLEM-002 — elaborates §1, why the discipline must exist (conversion must be agentic, governed, proven).
MODEL-003 — elaborates §2.2, the what: the three graphs and three invariants (I1 ↔ P1, I2 ↔ P2, I3 ↔ P4) as a framework an analyst can redraw.
LIFECYCLE-004 — elaborates §6, the motion: each of the twelve decision stages in full (objective, inputs, outputs, authority, evidence, gates, worked examples, conformance tests), with a second, non-cryptographic workload proving generality.
ARCH-005 — elaborates Appendix A, how the model is realized in components, without becoming implementation-specific.
AUTH-006 — elaborates §9, what is permitted: the Authority Graph, the authority object, rooting, delegation/inheritance math, revocation, continuity, Authority Replay (requirements A1–A8).
EVIDENCE-007 — elaborates §8, what is proven: the Evidence Object, Evidence Graph, Chain of Evidence, evidence properties, offline verification, continuity, Evidence Replay (requirements E1–E8). It binds each proof to AUTH-006's authority, so authority and evidence are two views of one fact.
MATURITY-008 — elaborates §13; references CORE-001 through EVIDENCE-007.
STANDARDS-009 — elaborates §12.
REFERENCE-010 — instantiates the corpus in named technology (H33); conforms to CORE-001 through STANDARDS-009; hosts the Proof Lab. Its product names are illustrative and MUST NOT appear in a conformance claim against the neutral specifications.

None of these may weaken a principle (P1–P7), a mandatory property (§2), the lifecycle (§6), the authority requirements (§9), the evidence requirements (§8), or the conformance bar (§14).

17. Not In Scope

This Constitution does not specify: cryptographic algorithms (NIST's role); vendor implementations, product names, or APIs (APQC-REFERENCE-010); programming languages, data formats, or wire protocols; cloud or infrastructure providers; the mechanics of any single workload's transformation; or the internal data model, storage, and query of the three graphs (conceptual treatment is APQC-MODEL-003; realization is APQC-ARCH-005 and APQC-REFERENCE-010). It defines the discipline — properties, lifecycle, graphs, authority, evidence, threats, maturity, and conformance — not any implementation of it. The formal decision object and its state machine are reserved for APQC-DECISION-011 (Appendix B).

Appendix A — Reference Architecture (summary)

Traditional PQ migration: Discovery → spreadsheet → consultants → manual change → hope (unverifiable).

Agentic Post-Quantum Conversion: Discovery agents → knowledge graph → authority graph → planning agents → simulation → execution agents (least-exposure) → verification (independent, with negative tests) → proof substrate → population-wide governance → continuous verification → adaptation.

The difference is not speed alone; it is that the second path is governed and proven at every step — bounded by authority before each action and provable offline after it, for the life of the evidence. (Expanded in APQC-ARCH-005, Reference Architecture.)

Appendix B — The APQC Corpus (specification taxonomy)

This Constitution (APQC-CORE-001) is the root of an eleven-document corpus (APQC-GLOSSARY-000 is the terminological root beneath all). The corpus is sequenced why → what → how → who, so each document is understood before the next depends on it:

APQC-GLOSSARY-000 — Canonical Glossary (terminological root; referenced by all)
APQC-CORE-001 — Constitution (this document — root)
APQC-PROBLEM-002 — Problem Definition (why the discipline must exist)
APQC-MODEL-003 — Conceptual Model (the vendor-neutral conceptual framework)
APQC-LIFECYCLE-004 — Lifecycle Specification (each stage in operational detail)
APQC-ARCH-005 — Reference Architecture
APQC-AUTH-006 — Authority Model
APQC-EVIDENCE-007 — Evidence Model
APQC-MATURITY-008 — Maturity Model (references CORE-001 through EVIDENCE-007)
APQC-STANDARDS-009 — Standards Mapping
APQC-REFERENCE-010 — Reference Implementation (H33; conforms to CORE-001 through STANDARDS-009; hosts the Proof Lab demonstrations)

Reserved: APQC-DECISION-011 — Decision Model (anticipated after APQC-EVIDENCE-007). Everything in the discipline revolves around decisions — Intent, Authority, Planning, Execution, Verification, Evidence — yet "decision" is not yet formally defined. DECISION-011 will specify the decision object, decision lifecycle/state machine, decision replay, inheritance, revocation, and continuity.

The Threat Model (§11) and Workload Catalog (§10) are retained inline in this Constitution as canonical short forms, and MAY be promoted to standalone specifications if the corpus requires. Live demonstrations (Proof Lab) are delivered under APQC-REFERENCE-010.

Editor's note: this is a working draft (0.2). Normative claims about the reference implementation (H33-74, H33-Root, H33-Key, Agent-Zero, HATS, Agent-008) describe demonstrable capabilities; any capability not yet demonstrable belongs in the Maturity Model as a trajectory, not in the normative body — per Principle P1.