Here's the idea. The permission limit you set when you hire an agent gets turned into a hash. Then, as the agent runs, that limit gets checked against real-time policy, and that check turns into a hash too. Both hashes go into the receipt. An auditor can verify the receipt just by recomputing the hashes byte for byte. They don't have to trust anyone's word for it.
Right now, every agent framework writes its own audit format. So when a regulator or a business partner asks "did the agent stay inside the limits you gave it when you hired it?", every team hands back a different kind of paperwork. HAHS gives everyone one shared receipt format: the hire-time limit, the real-time check against it, and one Ed25519 signature covering both. Any auditor can check any agent, using the same format.
| Field | Value |
|---|---|
| $id | https://hivetrust.onrender.com/.well-known/schemas/hahs-v1.json |
| Title | HAHS: Hashes-as-Histories v1 |
| Canonicalization | RFC 8785 JCS (JSON Canonicalization Scheme) |
| Signature | Ed25519 over canonicalized payload |
| Required fields | policy_id, policy_version, scope, composed_scope, receipt_hash, signature |
| CTEF byte-match | 4/4 vectors against AgentGraph CTEF v0.3.1 (substrate maintained by agentgraph.co) |
| Issuer DID | did:hive:hivetrust-issuer-001 |
| Pubkey (base64url) | i6-Wo01AwSD1eAhSSC3e3VCTEYFXehGNOVdC5iobuBc |
| Pubkey endpoint | hivetrust.onrender.com/v1/audit/pubkey |
The hire-time scope limit is on the left. The composed scope, checked live against the chain, is on the right. Both get hashed the same way every time, and both are signed by the HiveTrust issuer.
{ "policy_id": "pol_agent_designer_v2", "policy_version": "2.4.1", "scope": { "actions": ["read:directory", "post:thread", "spend:usdc"], "resources": ["dir:a2amev/*", "thread:catnip/*"], "spend_cap_usdc": 250, "ttl_seconds": 86400 }, "composed_scope": { "actions": ["read:directory", "post:thread"], "resources": ["dir:a2amev/*"], "spend_remaining_usdc": 187.42 }, "receipt_hash": "sha256:f9c2a1...4b", "signature": "ed25519:8z3k...nLq" }
HAHS-Δ adds three fields to HAHS v1 that carry the signed difference between a primary inference run and a counterfactual run against a different corpus, rule version, or identity context. That difference is itself a signed artifact. You can check it offline, it's byte-identical every time, and it's backed by either a SpectralZK proof (still a research frontier) or an ML-DSA-65 signature (live today). Patent Pending.
| Field | Type | Description |
|---|---|---|
| counterfactual_ref | string (SHA-256 URI) | A content-addressed pointer to the counterfactual corpus, rule set, or identity context used to produce Branch B. Format: sha256:<hex>. This lets any verifier confirm exactly what "would have been used," without ever seeing the corpus itself. |
| delta_proof | string (base64url) | A signed proof of how much Branch A (the primary run) and Branch B (the counterfactual run) differ in meaning. It's signed by ML-DSA-65 (NIST FIPS-204, the government's post-quantum signature standard) in production. A SpectralZK zero-knowledge proof of the difference is a research option, still amber status until it's formally checked. |
| semantic_divergence | number (float, 0 to 1) | A normalized score for how different Branch A and Branch B outputs are in meaning. 0.0 means the outputs are identical under the counterfactual corpus. 1.0 means they're as different as possible. It's computed over the SMSH embedding space, and the delta_proof signature backs it up. |
Read the full D5 spec and six real-world application examples: XCALIBUR DELTA: D5 Signed Counterfactual Inference.
HAHS receipts are created and checked by Hive's ML-DSA-65 plus Ed25519 pipeline. HiveTrust serves the schema endpoint. The code that produces HAHS receipts lives in two Hive repos.
| Repo | Path | Purpose |
|---|---|---|
| srotzin/hivelaw | src/routes/hahs.js | POST /v1/law/hahs/create · GET /v1/law/hahs/schema |
| srotzin/hive-passport | src/lib/hahs.js | HAHS issuance + verification helpers for the passport substrate |