Proof Lab
StartEcosystem
Explore (579)Live Systems (52)Pricing
Log InGet API Key✓ Verify It Yourself
Capability · Independent Verification · Architecture layer: TRUST BOUNDARY

Verification

See it live: the Evidence Replay player is independent verification in action — it re-derives the SHA3-384 over each run's RFC-8785 canonical trace in your browser (the same check a third party runs offline) and refuses to replay a trace it cannot re-verify.

How something becomes independently trusted: an independent verifier checks an immutable artifact it did not produce, and yields a deterministic, reproducible verdict — with no vendor in the path.

Definition. Verification is the platform’s trust boundary. It is the capability by which a verdict is reached on an artifact, by an actor independent of whoever produced it. Verification does not produce the artifact, does not anchor it, does not govern the thing it checks, and does not monitor it — those belong to H33-74, Agent-008, and HATS. And a passing verdict means the artifact reproduces and its signatures validate — it does not mean a system is secure, correct, or compliant.

What verification is

from graph: concept:VERIFICATION

Verification is how something becomes independently trusted: an actor checks an immutable artifact and yields a result, with trust flowing only toward greater certainty. The artifact is fixed before it is checked; the verifier adds nothing to it and takes nothing on faith.

The two kinds of verification

from graph: VERIFICATION HAS_KIND INDEPENDENT_VERIFICATION + DETERMINISTIC_VERIFICATION

Verification has two real kinds — independent verification (the trust property: no vendor in the path, download–run–reproduce) resting on deterministic verification (the mechanism: the same proof yields the same verdict). Independence rests on determinism: a verdict can only be vendor-free if anyone re-running it reaches the same answer.

What a verdict means — and what it does not

from graph: VERIFICATION_RESULT semantics · claim boundary (lifted from verifier Q0.5)

A passing verdict attests exactly three things, and stops there:

PASS attestsPASS does not attest
the artifact reproduces byte-for-bytethat the system is secure
its post-quantum signatures validate (all families)that the decision was correct, wise, or fair
its replay reconstructs what happenedthat the environment is compliant or lawful

Verification checks an artifact against itself and against fixed cryptographic and schema rules. It never judges whether a decision was wise, correct, fair, lawful, or compliant — that is not a defect, it is the boundary that makes an independent verdict meaningful.

How reproducibility is possible

from graph: VERIFICATION USES PROTOCOL_STABILITY

Protocol stability freezes the schemas, error namespaces, and replay-integrity classification, so a verdict is reproducible across implementations and over time. It guarantees the ability to reproduce — not the correctness of any single replay.

How replay is consumed

from graph: VERIFICATION USES GOVERNANCE_REPLAY

Verification consumes governance replay: the frozen evidence is re-executed to reconstruct exactly what happened, so a third party can confirm the decision without trusting the vendor.

Independent of the vendor — verification survives H33

from graph: INDEPENDENT_VERIFICATION (no vendor in path) · VERIFIER conformance-attested

The strongest property of verification is that it works with the vendor absent. You download the artifact and the verifier, run it, and reproduce the verdict; H33 is not contacted. If H33 is offline, sanctioned, acquired, or sunset, verification still succeeds — certainty rests in the artifact’s bytes and a conformance-attested verifier, never an H33 service.

The verifier is not trusted because H33 says so: it is conformance-attested against public vectors, so it is not verifying its own output. A post-quantum attestation is checked across three signature families, and all three must validate (an AND-gate — the attestation is only as strong as every family combined):

FamilyParameterStandard status
ML-DSAML-DSA-65NIST FIPS 204 (finalized)
SLH-DSASLH-DSA-SHA2-128fNIST FIPS 205 (finalized)
FALCONFALCON-512not yet a finalized FIPS signature (FN-DSA / FIPS 206 draft)
Stated honestly: two of the three families (ML-DSA, SLH-DSA) are finalized NIST FIPS signature standards; FALCON-512 is not yet finalized. The AND-gate depends on all three, so the trust claim rests on FALCON as well — and that is disclosed here rather than implied to rest on the FIPS families alone. Proof surfaces: the Portability Verifier and what happens if H33 disappears.

How artifacts are verified

from graph: artifact = H33_74 / PQ_VERIFIED (evidence-first) · H33_74 ANCHORS the artifact (read, not done here)

Verification does not create a parallel artifact class. Proofs resolve into the existing H33-74 / PQ-Verified attestation objects; a ZK proof is a witness feeding into them. Those objects are anchored by H33-74 — anchoring is a producer property Verification reads, not one it performs. The direction is acyclic:

verifier VERIFIES artifact  →  artifact PROVES claim

Because the arrow only points one way, a verifier never verifies its own output, and a claim is never trusted except through an artifact an independent verifier has checked.

Who relies on verification

from graph: inbound VERIFIED_BY (consumers USE the reference verifier) · NOT implemented-by

Verification is a thin, product-independent capability. Consumers do not implement it — they use the same reference verifier to have their artifacts independently checked:

ConsumerRelationshipWhat is verified
Agent-008VERIFIED_BYthe Provable Authority Package — that an action was authorized
HATSVERIFIED_BYthe evidence record — that controls operated as declared
APQC (Verify phase)VERIFIED_BYa converted estate — independent of whoever executed the change
Authority CenterVERIFIED_BYpreserved authority state — that it still holds

In each case the performer of verification is external and the same: none of these products verifies itself.

The verifier — the actor, distinct from the capability

from graph: VERIFIER VERIFIES artifact -> VERIFICATION_RESULT (actor != capability)

Verification is the capability; the verifier is the actor that performs it. The reference actor is h33-verifier — a small, conformance-attested tool you run yourself. It VERIFIES an artifact and yields a verification result; it is not the artifact, and it is not the claim.

Portability Verifier · Verifier CLI · Survivability proof

Next step

from graph: VERIFICATION CONVERTS_TO EVALUATION_PATH

See how verification proves your environment — download an artifact and reproduce the verdict yourself, or start an evaluation.

See verification prove an environment

Limitations & boundaries

from graph: explicit claim boundary (does-not / does)

Produce the artifact

Verification does not create what it checks. The artifact is produced and anchored by H33-74; verification reads it.

Govern the action

Verification does not decide whether an action was authorized. Agent-008 governs; verification checks the resulting proof.

Monitor the estate

Verification does not watch a running system. HATS monitors and emits the evidence record.

Make the claim true

Verification does not make a claim true — the artifact does. A verdict only confirms the artifact holds up.

Guarantee security

A passing verdict is not a security, correctness, or compliance guarantee — only that the artifact reproduces and its signatures validate.

What it does

Verification does render an independent, deterministic, reproducible verdict on an immutable artifact — with no vendor in the path.

Generated from the H33 knowledge graph (VERIFICATION node, v0.5), promoted into the production shell. Every section above is a projection of a ratified graph relationship — no prose relationship is invented. PROJECTION_NOT_DEFINITION. The durable form of this enrichment belongs in the VERIFICATION node so regeneration reproduces it.
Related products

Products built on Verification

ZK-Verify