Conforming Reference Implementation

A demonstration that the H33 platform conforms to APQC-CORE-001 through APQC-STANDARDS-009. Not a product description — a conformance statement.

• Document: APQC-REFERENCE-010 — Conforming Reference Implementation
• Status: Draft 0.1
• Version: 0.1
• Date: 2026-07-02
• Editor / Authoring body: H33.ai, Inc.
• Implementation under test: H33 platform — Agent-008, H33-Root, H33-Key, H33-74, HATS, Agent-Zero.

This is the only document in the corpus in which a specific implementation is central, and it is written to the standard of a conformance demonstration: every claim traces to a normative requirement in APQC-CORE-001 … APQC-STANDARDS-009, and each is marked Implemented, Partial, or Trajectory. Where a requirement is not yet fully met, this document says so. A reference implementation earns credibility by being falsifiable, not by being flattering.

RFC 2119 keywords apply where used.

0. Front Matter

0.1 Normative References

• APQC-CORE-001 … APQC-STANDARDS-009 (the full normative corpus); APQC-GLOSSARY-000.

0.2 Informative References

• H33 Proof Lab demonstrations, benchmarks, and open verifier (see §7).

0.3 Related Specifications

• Conforms to: all normative specifications, APQC-CORE-001 through APQC-STANDARDS-009.

0.4 Conformance Dependencies

• Depends on: APQC-CORE-001 through APQC-STANDARDS-009, APQC-GLOSSARY-000.
• Referenced by: none (this is a leaf document).

1. Purpose

To demonstrate that a real system implements the discipline, and to the degree it does. This document maps the H33 platform to the engines (APQC-ARCH-005), the three graphs (APQC-MODEL-003), and the normative requirements (APQC-AUTH-006, APQC-EVIDENCE-007, APQC-CORE-001, APQC-ARCH-005), and points to the demonstrations that substantiate each claim. It does not argue that H33 defines APQC — the preceding nine specifications do that, independently of any vendor. H33 is a conforming implementation.

1.1 How to read this document

This is a conformance record, not a narrative. Three conventions govern it and are non-negotiable:

1. Status is one of three words. Every claim is marked Implemented, Partial, or Trajectory, defined in §1.2. There is no fourth category and no soft language ("robust," "world-class," "seamless") anywhere in this document. Where a capability is not demonstrable today, the status says so and §8 names the path to close it.

2. A claim without a proof reference is worth nothing. Every Implemented claim MUST cite, in §7, a working demonstration a third party can run or inspect. An Implemented status unsupported by a proof reference is a defect in this document, not a feature of the platform.

3. The specification, not the vendor, is the authority. Where this document and any of APQC-CORE-001 … STANDARDS-009 disagree, the specification wins and this document is wrong. H33 conforms to the corpus; it does not amend it.

1.2 Status vocabulary (normative for this document)

• Implemented — the requirement is met by a demonstrable mechanism that a third party can verify today, offline where the requirement demands it, with a proof reference in §7. The claim is falsifiable: running the cited demonstration would expose a false claim.
• Partial — the mechanism exists and is demonstrable for a bounded scope (a segment, a workload, a controlled deployment), but full-estate, fully-autonomous, or fully-continuous operation is not yet demonstrable. Partial is honest about what works now and what does not yet, and §8 states the boundary.
• Trajectory — the requirement is a design target for which no complete demonstration yet exists. Trajectory is never asserted as done. Per APQC-CORE-001 P3, autonomy is earned by demonstrated reliability; capabilities not yet demonstrated belong here, in the Maturity Model's forward direction, never in the normative body of a conformance claim.

The distinction between Partial and Trajectory is exactly the distinction APQC-CORE-001 §13 draws between an operating maturity level and the levels above it: Partial means "demonstrable within scope, advancing"; Trajectory means "targeted, not yet demonstrable at all."

2. Conformance statement

The H33 platform implements the normative requirements of APQC-CORE-001 through APQC-STANDARDS-009. This section states status by area at a summary level; §6 substantiates every individual requirement, and §8 lists every Partial and Trajectory item with its path to closure.

2.1 Summary of status by area

• Implemented (demonstrable today, offline where required). The Evidence Model (APQC-EVIDENCE-007) in its core properties — object-per-change, authority binding, multi-family post-quantum signing, portability, survivability, offline independent verification — and the fail-closed authority boundary of the Authority Model (APQC-AUTH-006 A5): an out-of-scope request yields no result and no attestation. These are the properties H33's core primitives (H33-74, H33-Root, H33-Key, Agent-Zero) were built to satisfy, and each is backed by a Proof Lab demonstration in §7.

• Partial (demonstrable within scope; not yet full-estate or fully continuous). End-to-end autonomous execution of the Transformation Engine across a full enterprise estate; enterprise-scale continuous drift re-conversion; and the full authority lifecycle tooling (graph-scale replay, mass revocation, cross-org federation) beyond the fail-closed core. These operate under human-in-the-loop gating today, consistent with APQC-CORE-001 P3 and APQC-MATURITY-008 Levels 3–4. Partial here means the mechanism is real and demonstrated on bounded scopes, not that it is aspirational.

• Trajectory (targeted, not yet demonstrable). Unattended Level-5 autonomy (APQC-MATURITY-008 §3): conversion running unattended across the whole estate, with governance closing the loop without human prompting. Per P3 this is the ceiling, earned by demonstrated reliability, and this document does not assert what is not yet demonstrable. Full unattended autonomy is not claimed.

2.2 The honesty invariant

The credibility of the entire APQC corpus depends on this document remaining falsifiable. Accordingly: nothing marked Implemented may require trusting H33's word — every such claim resolves to a demonstration that runs without contacting H33 (the "delete the producer" test, APQC-EVIDENCE-007 §6.5). Anything that does require trusting the platform, or that only works in a controlled setting, is marked Partial or Trajectory. If a reader can find an Implemented claim that fails its cited demonstration, the claim is wrong and MUST be downgraded. That is the test this document invites.

2.3 Assessed maturity (APQC-MATURITY-008), per workload

Maturity is assessed per workload (APQC-CORE-001 §10; APQC-MATURITY-008 §4), and a missing lower engine caps the level regardless of higher engines present.

Only Post-Quantum Conversion is assessed at Level 4. The others are stated honestly at 1–3 per APQC-CORE-001 §10 and APQC-MATURITY-008 §4; claiming otherwise would violate §2.2.

3. Engine mapping (APQC-ARCH-005)

APQC-ARCH-005 defines exactly five engines (Knowledge, Authority, Transformation, Evidence, Governance) plus the Least-Exposure cross-cut (P4), each an architectural role, not a product. One H33 product MAY realize several roles; one role MAY be realized by several H33 components. The table below maps each engine to the H33 component that realizes its role, the normative requirement(s) it satisfies, the status, and the §7 proof.

Three notes on the mapping, required by ARCH-005 §5 to avoid the fusions that void conformance:

• Sole-writer per graph holds (ARCH H7, C2). H33-Root is the sole writer of the Authority Graph; Agent-008's Transformation function cannot write it — it can only be gated by it. This is enforced by construction (H33-74 issuance is denied when the requesting authority is invalid), not by policy, which is what ARCH C2 requires as a test ("MUST be impossible by construction, not merely disallowed"). Status: Implemented for the gating boundary; see §7.2.
• Oversight reads all, writes none (ARCH H6). HATS consumes graph state and estate sensing and emits findings and a re-entry signal; it performs no estate change. This preserves the state/action/oversight separation ARCH §4 makes load-bearing. Status: Implemented for the read-only property; the full closed loop across a whole estate is Partial (§8).
• Least exposure is a cross-cut, not a sixth engine. H33-Key and Agent-Zero do not add a graph; they constrain how the Transformation Engine touches sensitive material (P4), satisfying ARCH H5 and C8. This is correctly modeled as a cross-cutting property of the Transformation role, per ARCH-005.

4. Graph mapping (APQC-MODEL-003)

The three graphs — Knowledge (what is known), Authority (what is permitted), Evidence (what is proven) — are the intellectual core (CORE-001 §2.2). H33 realizes them as follows. Each subsection states which graph, which component is its sole writer, and honest status.

4.1 Knowledge Graph — realized by Agent-008 discovery/inventory

Agent-008's discovery and inventory functions sense the estate and produce a classified, deduplicated asset population with dependency edges and, per ARCH-005 §5.1, a blast-radius annotation for each asset. The Transformation Engine reads exactly this before it plans (ARCH H4). Coverage is a stated output, never an assumption — the engine reports what fraction of the estate is observed rather than presuming completeness, which is the mitigation ARCH-005 §5.1 names for "knowledge without coverage accounting."

Status: Partial. Discovery, deduplication, dependency resolution, and blast-radius annotation are demonstrable on integrated estate segments; coverage grows per integration, and full-estate completeness of the Knowledge Graph is not yet claimed. The honest boundary: what is seen is modeled well; total estate visibility is incremental. (§7.8, §8.)

4.2 Authority Graph — realized by H33-Root

H33-Root is the Authority Root (AUTH-006 §3): the durable, independently-verifiable trust anchor at which every delegation chain terminates. Its load-bearing behavior is fail-closed issuance: H33-74 evidence issuance is denied when the requesting authority is invalid — an out-of-scope, expired, revoked, or un-rooted request yields no result and no attestation. This realizes the AUTH-006 §4.2 distinction between denied and inconceivable: the unauthorized action leaves nothing an attacker can build on and nothing an auditor must sift, and produces no substrate (AUTH A5; CORE P2).

Because H33-Root's anchor is post-quantum, it satisfies the AUTH-006 §3(b) durability across the retention horizon requirement: a Root whose signatures became forgeable within the horizon would retroactively unverify every authority beneath it, and post-quantum families are what prevent that.

Status: core Implemented; full graph tooling Partial. The fail-closed root-to-action gate is Implemented and demonstrable (§7.2). The complete Authority-Graph lifecycle of AUTH-006 — deterministic offline Authority Replay at graph scale (A8), immediate propagating mass revocation across arbitrary subtrees (A6), and cross-organizational federation (ARCH §9) — is Partial: demonstrable on bounded chains, not yet at full estate/federation scale. (§7.9, §8.)

4.3 Evidence Graph — realized by H33-74

H33-74 is the 74-byte post-quantum attestation substrate: for each material change it produces a compact cryptographic commitment (SHA3-256) to the change without exposing it (EVID §3.2 commit-not-copy; CORE P4), binds the change to its authority and time (EVID §3.1), and signs it under three independent signature families — ML-DSA · FALCON · SLH-DSA — so the object survives the cryptanalytic break of any one family (EVID §13.2; CT-E3b). It is verifiable offline, without contacting H33 (EVID E6). Because the object is ~74 bytes plus signatures, a decade of per-change evidence is measured in gigabytes, not terabytes (EVID §13.4) — small enough to retain forever and hand to anyone.

The three graphs meet at the H33-74 object (EVID §4.2): each object carries a Knowledge edge (the asset it changed), an Authority edge (the grant it cites, which MUST resolve to a valid H33-Root path or the object is not produced), and a chain edge to its predecessor.

Status: Implemented for the object, its integrity, authority binding, portability, survivability, and offline verification (§7.1, §7.3, §7.4, §7.5). Partial for estate-scale provable completeness (EVID E4) — completeness is demonstrable over a committed segment (§6, E4), but a single completeness proof over an entire enterprise estate is scope-dependent and still growing.

5. Transformation flow (one workload: Post-Quantum Conversion)

This section traces a single Post-Quantum Conversion workload through the twelve-stage lifecycle (CORE-001 §6) as run by the five engines (ARCH-005 §6), naming which H33 component acts at each stage, what it produces, and the honest status of that stage. The scenario: convert the externally-facing RSA-2048 TLS signing key on svc-billing.example (port 8443) to an ML-KEM/ML-DSA hybrid, under a grant that forbids production change during the December freeze. This is the worked example threaded through ARCH-005 §5, run end to end here.

Reading the flow honestly. Stages 1, 9 (and the least-exposure property of 7) are Implemented — they are H33's built-for-purpose core and each has a §7 demonstration. Stages 2–6, 8, 10–11 are Partial: the mechanisms are real and demonstrated on bounded scopes, but full-estate, unattended operation is not yet demonstrable. Stage 12's continuous, unattended, whole-estate re-conversion is where Partial shades into Trajectory — and that boundary is precisely what places this workload at Maturity Level 4 advancing toward 5, not at Level 5 (§2.3).

6. Conformance matrix

Every normative requirement in the corpus, its H33 mechanism, its honest status, and the §7 proof that substantiates it. The matrix is the falsifiable heart of this document: a reader can take any Implemented row and attempt to break it via the cited proof.

6.1 Constitution principles (APQC-CORE-001 P1–P7, §14)

6.2 Authority Model (APQC-AUTH-006 A1–A8, CT-A*)

6.3 Evidence Model (APQC-EVIDENCE-007 E1–E8, CT-E*)

6.4 Reference Architecture conformance tests (APQC-ARCH-005 C1–C11)

7. Proof references

Conformance claims above are substantiated by working demonstrations, not assertions (CORE-001: "we make evidence, not claims"). Live links belong on the published page; the artifacts referenced here exist in the H33 Proof Lab. Each demonstration is mapped to the exact requirement it substantiates, and anything not demonstrable is marked Partial or Trajectory in §6, never asserted here as complete.

7.1 H33-74 evidence object — substantiates E1, E2, E3, CT-E3, CT-E1a, C5, C6, P1

The 74-byte substrate: SHA3-256 commitment to the change (never a copy — EVID §3.2, P4), authority binding to an H33-Root path (an object is not produced if the path is invalid — E2, CT-E2a), and three signatures (ML-DSA · FALCON · SLH-DSA) over canonical bytes so any single-bit edit to any bound field breaks a signature (E3, CT-E3). Chained per segment for completeness over a committed scope (E4, CT-E1a). Status: Implemented for the object; Partial for whole-estate completeness.

7.2 Fail-closed authority gate — substantiates P2, A5, CT-A1, CT-A5, C2, C3, C6, §14(b)

H33-74 issuance is denied when the requesting authority is invalid (out-of-scope, expired, revoked, un-rooted). The unauthorized action produces no result and no attestation — the AUTH-006 §4.2 "inconceivable, not merely denied" behavior. This is the load-bearing test (ARCH C3) and it is enforced by construction, not policy. Status: Implemented. This is falsifiable: attempt an out-of-scope conversion and observe that no H33-74 object exists for it.

7.3 Trust Card live verifier + open-source H33 Portability Verifier — substantiates E5, E6, E7, CT-E3b, CT-A8b, C7, P7

An open, offline verifier checks any H33-74 bundle against the three PQ signature families with no network and no H33 contact. It resolves the authority path (rejecting a self-minted valid signature that terminates at no Root — CT-A8b, the entire point of AUTH-006 §2.5), and a quorum requirement means a forgery valid under one broken family alone is rejected (CT-E3b). Status: Implemented.

7.4 "What Happens If H33 Disappears?" — substantiates E5 (survivability), CT-E5, C7

The "delete the producer" test (EVID §6.5): the vendor, database, and dashboard are removed; a third party holding only the objects and public parameters still verifies successfully. This is the single most important demonstration in the corpus, because it is what distinguishes evidence from logging. Status: Implemented.

7.5 Avalanche Evidence Anchoring + Bitcoin Mainnet Attestation — substantiates E6 (independent time), E8, CT-E6a, A7

Object commitments are anchored to public, append-only ledgers, establishing existence-at-a-time no party (including H33) can alter — defeating backdating (CT-E6a) and giving a chain an external time reference. Anchoring binds time, not content (the ledger sees only a commitment). Status: Implemented for anchoring; estate-scale replay against anchors is Partial.

7.6 HATS continuous control monitoring — substantiates P6, C9, Stages 10–12, Governance Engine

HATS produces replayable evidence of control state and drift, and emits the re-entry signal that reopens the lifecycle. It reads graph state and writes no estate change (ARCH H6). Status: Implemented for monitoring and replayable control evidence; Partial for the full-estate, unattended, continuous drift→re-conversion loop (that boundary is the Level-4-toward-5 line).

7.7 Encrypted Biometric Verification + Agent-Zero + H33-Key — substantiates P4, C8, H5

Computation on data the server never sees (Encrypted Biometric Verification) and credential-bound operations (sign/authenticate/derive/decrypt/http_request) via H33-Key's FHE-based proxy — the credential is never exposed to the acting agent, and Agent-Zero acts on data it cannot read. Status: Implemented for least exposure.

7.8 Transformation & discovery on bounded scopes — substantiates C4, P5, Stages 2–8, §14(a)

Agent-008 discovery/inventory (Knowledge, §4.1), planning/simulation/execution reading blast radius before acting (ARCH C4/H4), and staged, reversible hybrid rollout with a retained rollback window (P5). Status: Partial — demonstrable per segment and under human-in-the-loop gating; full-estate autonomous execution is the boundary (§8).

7.9 Authority lifecycle beyond the gate — substantiates A2, A3, A4, A6, A7, A8, CT-A2/A3b/A4/A6/A7/A8, C11

Signed monotonic-decreasing delegation, subtree revocation that is itself evidenced, and offline Authority Replay of past graph state. Status: Partial — the fail-closed gate (§7.2) is Implemented; the full graph lifecycle (graph-scale replay, mass revocation, cross-org federation) is demonstrable on bounded chains and growing toward estate/federation scale.

7.10 Performance envelope — informative context for estate-scale feasibility

Benchmark v12: 2,293,766 authentications/second sustained over 120 seconds; 38 µs per-auth latency. This does not by itself substantiate a normative requirement (no requirement mandates a throughput number); it is evidence that the authority/evidence primitives operate at the rate an enterprise estate requires, so that "fail-closed on every action" and "an object per change" are feasible at scale rather than only in principle. Status: Implemented as a measured performance fact; it is context, not a conformance claim.

8. Gaps and roadmap

Candor about the Partial and Trajectory items is what keeps this a conformance record and not marketing. Every non-Implemented item above is listed here with the boundary that makes it Partial/Trajectory and the concrete path to close it. Nothing here is a promise of a date; it is a statement of what is not yet demonstrable and what would make it so.

8.1 Partial — mechanism real, scope bounded

8.2 Trajectory — targeted, not yet demonstrable

Note the shape of the roadmap: every Trajectory item decomposes into Partial items, and every Partial item into an already-Implemented core plus a scope expansion. That is the honest structure of a system at Maturity Level 4 advancing toward 5 — the invariants (fail-closed authority, evidence per change) are Implemented and do not relax as autonomy grows (APQC-MATURITY-008 §4; CORE P3); what grows is scope and unattendedness, never the safety floor.

9. Summary of the conformance position

• What is Implemented, offline-verifiable, and falsifiable today: the Evidence Object and its integrity, authority binding, multi-family PQ signing, portability, survivability, and offline verification (E1–E3, E5, E6; H33-74 + open verifier); the fail-closed authority boundary (P2, A5; H33-Root); and least exposure (P4; H33-Key + Agent-Zero). Each resolves to a Proof Lab demonstration that runs with H33 absent.
• What is Partial: full-estate Knowledge coverage, autonomous Transformation at scale, estate-wide Evidence completeness, the full Authority-graph lifecycle beyond the gate, and the continuous whole-estate Governance loop. Real mechanisms, bounded scopes, named paths to close (§8.1).
• What is Trajectory: Level-5 unattended autonomy — targeted per P3, not claimed, decomposing entirely into the §8.1 closures.
• Assessed maturity: Post-Quantum Conversion at Level 4 (Proven), advancing toward 5; Identity/PKI at 2–3; Secrets at 1–2 (§2.3).

H33 is a conforming implementation of APQC — demonstrably so where marked Implemented, honestly bounded where marked Partial, and forthright about what it does not yet claim. This document is to be re-issued as status changes; a claim that later fails its cited proof is a defect to be corrected here, not defended.

10. Not In Scope

This document does not: define the discipline (APQC-CORE-001 … STANDARDS-009 do); certify H33 against external standards (each body's role); specify H33's internal wire formats, APIs, or algorithms beyond what a conformance claim requires; or serve as marketing. It is a falsifiable conformance record for one implementation, to be re-issued as status changes.