Verification Result Schema — v1.0.0

1. Overview

This schema defines the JSON output of hats verify or any conformant verifier implementation. The verification result is the final structured record produced after verifying a HATS attestation payload, governance proof bundle, or H33-74 receipt.

The result contains the verification status, counts of nodes and signatures verified, chain integrity assessment, replay outcome, a list of any failures encountered, and performance metrics. This is the machine-readable equivalent of the terminal output.

2. Definitions

Verification Result

A JSON object produced by a verifier after processing an attestation payload or governance proof bundle.

Failure Object

A structured record describing a specific verification failure. Contains the affected node, error code, expected value, actual value, and severity.

Chain Integrity

An assessment of whether the governance chain (sequence of attestations) is structurally intact. INTACT means no gaps or breaks. BROKEN means one or more chain links are missing or corrupted.

Replay Result

The outcome of attempting to replay governance decision logic. DETERMINISTIC means all replay frames produced identical outputs. DIVERGENT means at least one frame diverged. NOT_ATTEMPTED means replay was not performed.

3. Result Structure

Field	Type	Required	Description
status	string (enum)	Yes	VERIFIED, FAILED, PARTIAL, or ERROR.
bundle_hash	string (hex64)	Yes	SHA3-256 of the input that was verified.
timestamp	string (ISO 8601)	Yes	When verification completed.
nodes_verified	integer	Yes	Number of governance nodes that passed verification.
nodes_total	integer	Yes	Total number of governance nodes in the input.
signatures_valid	integer	Yes	Number of signatures that passed verification.
signatures_total	integer	Yes	Total number of signatures checked.
chain_integrity	string (enum)	Yes	INTACT or BROKEN.
replay_result	string (enum)	Yes	DETERMINISTIC, DIVERGENT, or NOT_ATTEMPTED.
failures	array	Yes	Array of failure objects. Empty if status is VERIFIED.
duration_us	integer	Yes	Verification duration in microseconds.
verifier_version	string	Yes	Version string of the verifier implementation.
proof_profile	string	Yes	The proof profile used during verification.

4. Failure Object Sub-Schema

Field	Type	Required	Description
node_id	string (UUID or null)	Yes	The node where the failure occurred. Null for bundle-level failures.
error_code	string	Yes	Machine-readable error code (e.g., NODE_HASH_MISMATCH, SIGNATURE_INVALID).
expected	string	No	The expected value (e.g., expected hash).
actual	string	No	The actual value found.
severity	string (enum)	Yes	FATAL, WARNING, or INFO.

5. JSON Schema Definition

6. Canonical Valid Result (VERIFIED)

7. Canonical Failed Result

8. CLI Output Mapping

The hats verify CLI maps the JSON result to terminal output as follows:

The mapping rules:

• status maps to the first line, colorized (green for VERIFIED, red for FAILED).
• bundle_hash is truncated to first 8 and last 6 hex chars with ellipsis.
• Each failure object maps to one block in the FAILURES section.
• severity maps to the prefix tag: [FATAL], [WARN], or [INFO].
• duration_us is converted to milliseconds for display.

9. Failure Modes

Error Code	Description	Severity
NODE_HASH_MISMATCH	A node's recomputed hash does not match the stored hash.	FATAL
ROOT_HASH_MISMATCH	The recomputed root hash does not match the bundle's root hash.	FATAL
SIGNATURE_INVALID	A PQ signature fails verification.	FATAL
SIGNATURE_MISSING	Fewer than three PQ signature families present.	FATAL
GRAPH_CYCLE	Governance graph contains a cycle.	FATAL
DANGLING_EDGE	Edge references a non-existent node.	FATAL
CHAIN_BREAK	Governance chain has a gap (missing intermediate attestation).	FATAL
REPLAY_DIVERGENT	Replay frame output does not match expected output.	WARNING
TIMESTAMP_FUTURE	Attestation timestamp is in the future beyond allowed skew.	WARNING
VERIFIER_ERROR	Internal verifier error (OOM, timeout, malformed input).	FATAL

10. Conformance Requirements

A conformant verifier implementation MUST:

1. Produce output conforming to this schema for every verification attempt.
2. Set status to VERIFIED only if all nodes pass, all signatures pass, chain integrity is INTACT, and no FATAL failures exist.
3. Set status to FAILED if any FATAL failure exists.
4. Set status to PARTIAL if graph and signatures pass but replay diverges.
5. Set status to ERROR if the verifier itself encounters an internal error.
6. Include all detected failures in the failures array, not just the first one.
7. Record duration_us accurately (wall-clock time, not CPU time).
8. Populate verifier_version with the implementation name and semantic version.

Conformant verifiers MUST NOT set status to VERIFIED if signatures_valid < signatures_total or if nodes_verified < nodes_total.

11. Cryptographic Assumptions

• SHA3-256 (FIPS 202) — bundle_hash is the SHA3-256 of the input being verified.
• Verifier independence — The verification result schema assumes nothing about the internal implementation of the verifier. Any implementation that follows the verification flow defined in the corresponding input schema (HATS Attestation, Governance Proof Bundle, H33-74 Receipt) and produces this output is conformant.