Agent Governance Conformance Test Vectors — v1.0

1. Introduction

This document defines the authoritative set of 20 conformance test vectors for the H33 Agent Governance Attestation Model v1.0. Each vector specifies a deterministic input-output contract that any independent verifier implementation MUST satisfy to claim conformance with the agent governance specification.

Conformance vectors are the mechanism by which H33 enforces verifier equivalence: if two independent implementations consume the same vector and produce the same output, they are functionally equivalent for that operation. This property is the foundation of replay-grade attestation — the ability to reconstruct agent governance state from the chain alone, without contacting the originating infrastructure.

The vectors are generated deterministically by src/bin/generate_agent_vectors.rs in the scif-backend repository. They are machine-readable JSON files that serve as the immutable conformance corpus for the agent governance layer.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

2. How to Use These Vectors

2.1 Generating Vectors

To generate the canonical vector set from source:

# From the scif-backend repository root
cargo run --bin generate_agent_vectors --release

This produces 20 JSON files (AGT-TV-001.json through AGT-TV-020.json) in the output directory. Each file is a self-contained test vector.

2.2 Verification Process

An independent verifier implementation MUST follow this process for each vector:

1. Parse the JSON vector file.
2. Extract the input object and feed it to the corresponding operation in your implementation.
3. Compare your output against the expected_output object.
4. Every field in expected_output MUST match exactly. Partial matches constitute a conformance failure.

2.3 Pass Criteria

An implementation SHALL be considered conformant if and only if all 20 vectors produce byte-identical expected outputs. An implementation that passes 19 of 20 vectors is non-conformant.

3. Vector Summary

Of the 20 vectors: 13 are PASS vectors (valid inputs that MUST be accepted) and 7 are FAIL vectors (invalid inputs that MUST be rejected with the specified failure reason).

4. Identity Vectors

Identity vectors verify that agent registration and session initialization produce deterministic, verifiable artifacts. An implementation MUST generate identical canonical names and bind cryptographic key material correctly.

5. Session Vectors

Session vectors verify correct DAG construction across multi-node sessions. An implementation MUST produce identical Merkle roots for identical inputs, maintain correct predecessor linkage, and close sessions with H33-74 commitments.

6. DAG Operations Vectors

DAG operations vectors verify that an implementation correctly detects tampered data, broken chains, and forged hashes. These are negative vectors: the implementation MUST reject the input and report the specific failure mode.

7. Tool & Memory Vectors

Tool and memory vectors verify correct handling of orphan nodes, tool envelope attestation, memory checkpoint chaining, and replay determinism. These vectors exercise the data provenance layer of the agent governance model.

8. Policy Vectors

Policy vectors verify deterministic time-slice replay across DAG states. An implementation MUST produce monotonically increasing node counts as replay timestamps advance, and each frame hash MUST be unique.

9. Replay Vectors

Replay vectors verify scope enforcement, session expiration, and delegation chain integrity. These vectors exercise the governance boundary layer that constrains agent actions.

10. Integrity Vectors

Integrity vectors verify exposure attestation and tool envelope correctness. These vectors exercise the data classification and provenance scoring subsystems.

11. Key Management Vectors

Key management vectors verify memory checkpoint chaining and state capture. An implementation MUST maintain predecessor-linked checkpoint chains and produce correct SHA3-256 digests of memory, context window, and retrieved document state.

12. Governance Vectors

Governance vectors verify approval flows, Merkle root computation, subgraph extraction, and cross-session isolation. These vectors exercise the highest-level governance operations that bind agent actions to organizational policy.

13. Vector JSON Schema

Every vector file conforms to the following JSON schema. Implementations SHOULD validate vector files against this schema before processing.

{
  "vector_id":       "AGT-TV-NNN",          // Unique identifier
  "name":            "Human-readable name", // Short description
  "description":     "...",                  // Full description
  "category":        "valid" | "invalid",    // Expected outcome class
  "input":           { ... },                // Operation-specific input
  "expected_output": {
    "verification_status": "VERIFIED" | "FAILED",
    "dag_integrity":       "INTACT" | "CORRUPTED" | "BROKEN_CHAIN" | ...,
    "hash_valid":          true | false,
    "chain_valid":         true | false,
    "replay_deterministic": true | false,
    "expected_root_hash":  "0x..." | null
  },
  "failure_reason":  "..." | null,            // null for valid vectors
  "version":         "1.0.0",                // Spec version
  "generated_at":    "2026-05-18T00:00:00Z"  // Generation timestamp
}

14. DAG Integrity Status Values

15. Conformance Levels

An implementation MAY claim partial conformance by specifying which categories it supports. The categories and their required vectors are:

Implementations claiming any conformance level MUST pass all vectors in the specified set without exception.

16. References