Refusal Ledger · Policy Change, Externally Witnessed · Patent Pending
Status

Cryptographic core built and proven. 37 of 37 smoke tests pass across the seven-primitive filing, including the Refusal Ledger mutation chain and the zero-knowledge envelope-bond proof. Filed July 26, 2026. USPTO application 64/119,279. Real production integrations are pilot-ready, not yet deployed.

A refusal threshold moved. Nobody outside the building knew.

Refusal policies, the thresholds that decide when a model declines a request, get changed by operators all the time: tuning, incident response, product decisions. Today those changes are internal. There is no external record that a change happened, when, by whom, or whether the new value still falls inside any bound the operator publicly committed to. Refusal Ledger™ closes that gap. It chains every policy mutation into a public, inclusion-proof ledger, and separately proves, with a zero-knowledge SNARK, that the runtime value in force at inference time falls inside a pre-declared envelope, without revealing the value itself.

Prove the policy changed honestly, and stayed in bounds, without publishing the number.

What it is: a two-tier system. A chained, CT-log-style Merkle ledger records every policy mutation with an inclusion root anyone can check. A separate Pedersen-commitment plus zero-knowledge envelope-bond proof lets the operator prove the live policy value sits inside public bounds [lo, hi] without disclosing the exact threshold. What it is not: Refusal Ledger does not force an operator to publish their actual refusal threshold, and it does not judge whether a given threshold is the right one. It proves the change was recorded and the value stayed inside the operator's own declared envelope.
Honest status: read this first

The cryptographic core is built and proven: 37 of 37 smoke tests pass across the full seven-primitive filing, including the mutation ledger and the envelope-bond zero-knowledge circuit. Signing is ML-DSA-65 (FIPS 204), constant 3,309-byte signature. Filed as provisional patent July 26, 2026, USPTO application 64/119,279. Real production integrations, wiring Refusal Ledger into a live policy-management system, are pilot-ready. They are not deployed today.

What's real today, and what's pilot-ready

These numbers come from the reference implementation's benchmark suite, run against the actual signer, verifier, and zk-circuit.

37/37
smoke tests pass · full seven-primitive filing
~6ms
sign p50 · ML-DSA-65
~2.4ms
verify p50
3,309B
signature size, constant · FIPS 204

Docket HC-2026-017. Envelope common across the seven-primitive filing: USAP_VERSION='usap.v1'. Real policy-system integration: pilot-ready, not yet deployed. We don't claim a live ledger running against a production policy store until a design partner runs it.

OpenAI lowered a cyber-refusal threshold. There was no external witness.

In the runup to the OpenAI and Hugging Face incident, a refusal-policy configuration change happened internally. Nobody outside the operator's own systems could confirm it happened, confirm when, or confirm the new value stayed inside any bound the operator had committed to. Attribution, again, depended entirely on the operator choosing to disclose it.

Policy changes are silent by default

Refusal thresholds live in internal config. A change is a database write or a config-service update. There is no independent, external record that anything changed at all.

Public commitments have no proof mechanism

Even when an operator publicly states "we will not lower thresholds below X," there is no way for an outsider to verify the live runtime value actually respects that commitment, without the operator disclosing the exact number.

Refusal Ledger makes both externally checkable

Every mutation lands in a chained, inclusion-proof ledger. Separately, a zero-knowledge proof shows the live value sits inside [lo, hi], with the exact value never revealed.

Motivating incident: Hive: the OpenAI / Hugging Face incident · NIST FIPS 204 (ML-DSA).

The demo: a mutation lands, and the ledger and the bond both hold

Two independent checks run against every policy state. One confirms the mutation history is complete and untampered. The other confirms the current value, whatever it is, stays inside the declared envelope.

#ScenarioInternal recordRefusal Ledger: what it catches
1Undisclosed threshold lowering: operator quietly loosens policy✓ looks routine internally mutation lands in ledger regardless, ledger_seq advances, inclusion root changes publicly
2Ledger tampering: attempt to delete or reorder a mutation record✓ internal log "looks clean" inclusion root fails to reconcile against prior signed root
3Envelope breach: runtime value drifts outside declared [lo, hi]✓ no internal alert configured zk-proof fails to verify against public bounds
4Unauthorized change: mutation with no valid authorization reference✓ change applied anyway authorization_ref fails independent check
The money shot side-by-side, one screen
What an outside verifier actually sees
Operator's internal claim
✓ "we didn't change the policy"
✓ "the threshold is still conservative"
✓ internal audit log unremarkable

TRUST REQUIRED

Refusal Ledger, checked independently
✗ mutation at ledger_seq 812, undisclosed
✗ zk-proof: value outside declared [lo, hi]
✗ inclusion root diverges from last public root

TRUST NOT REQUIRED: proof, not the operator's word

The exact threshold never has to be published for this to work. The ledger and the envelope bond turn "trust us" into something a third party can check with math.

The receipt schema: mutation and binding

Refusal Ledger emits two receipt types under the common usap.v1 envelope. refusal.mutation fires on every policy change. refusal.binding is the zero-knowledge proof that the live value stays in bounds. Both are ML-DSA-65 signed.

// refusal.mutation: fires on every policy configuration change
{
  "type": "refusal.mutation",
  "usap_version": "usap.v1",
  "docket": "HC-2026-017",
  "ledger_seq": 812,
  "prior_policy_digest": "sha256:...",
  "new_policy_digest": "sha256:...",
  "operator_identity": "hive-op-kid-04",
  "authorization_ref": "change-request:CR-4471",
  "inclusion_root": "sha256:...  // CT-log style, chained",
  "mutated_at": "2026-07-25T09:14:02Z",
  "signature": "ML-DSA-65, 3309 bytes"
}

// refusal.binding: proves runtime value stays inside public bounds
{
  "type": "refusal.binding",
  "usap_version": "usap.v1",
  "docket": "HC-2026-017",
  "envelope_id": "env-cyber-2026-h2",
  "envelope_bounds_digest": "sha256:...  // hash of public [lo, hi]",
  "policy_value_commitment": "Pedersen(value, blinding_factor)",
  "zk_proof_digest": "sha256:...",
  "zk_circuit_id": "refusal-envelope-bond-v1",
  "ledger_seq_at_read": 812,
  "checked_at": "2026-07-25T09:14:05Z",
  "signature": "ML-DSA-65, 3309 bytes"
}
Two tiers, two questions

The mutation ledger answers "did anything change, and was it authorized." The envelope bond answers "does the current value stay inside the declared range." Neither depends on the other holding.

Pedersen commitments hide the value

The policy value is committed, never disclosed in plaintext. The zk-SNARK proves the committed value satisfies lo ≤ value ≤ hi without opening the commitment.

The ledger is CT-log style

Every mutation's inclusion root chains from the prior root, the same construction used in Certificate Transparency logs. Deletion or reorder breaks the chain deterministically.

Signature: ML-DSA-65 (FIPS 204), constant 3,309 bytes. Bench: sign p50 ~6ms, verify p50 ~2.4ms. Aggregate throughput ~132 signs/sec/type, ~418 verifies/sec/type, single-threaded JS.

How the flow works, mutation to verified bond

Refusal Ledger runs alongside the operator's policy-management system, observing changes rather than gating them, and separately proving the live value at read time.

On every policy mutation
  • Capture prior and new policy digests, operator identity, authorization reference.
  • Advance the monotonic ledger_seq and chain the inclusion root.
  • Sign and emit refusal.mutation, publicly checkable by anyone with the ledger.
On every inference-time policy read
  • Commit the live policy value with a Pedersen commitment and a fresh blinding factor.
  • Generate a zk-SNARK proving the committed value sits inside public bounds [lo, hi].
  • Sign and emit refusal.binding. A verifier needs only the proof and the public bounds, never the value.
Fail-closed on tampering

An inclusion root that doesn't chain from the prior signed root is treated as a break, not a silent gap. Downstream consumers, including Carnac™, can stop on a broken ledger.

Offline verification

Both receipt types verify with just the ledger, the proof, and Hive's public key. No live access to the operator's policy store, no trust in their self-reporting.

Root of trust for the key

Refusal Ledger's signing key is rooted the same way as the rest of the Hive stack: in HiveSeal™. The ledger proves the policy history; HiveSeal proves the signer.

What we don't claim

Honesty is the product. Here is exactly where the edges are.

Not a judgment on the threshold

Refusal Ledger does not decide whether a given refusal threshold is safe, appropriate, or too loose. It proves the change was recorded and, separately, that the live value stayed inside the operator's own declared bounds.

The envelope is self-declared

The operator sets [lo, hi]. Refusal Ledger cannot force an operator to declare a meaningful envelope in the first place. It can only prove the value stays inside whatever envelope was declared.

Policy-system integration is pilot-ready, not deployed

The cryptographic core, the ledger, and the zk-circuit are proven against reference workloads. Wiring Refusal Ledger into a live production policy-management system is a pilot-stage integration today.

Where Refusal Ledger sits in the Hive canon

Refusal Ledger is one of seven upstream primitives filed together on July 26, 2026, all built on the same signer and the same usap.v1 envelope. Each closes a different gap the OpenAI / Hugging Face incident exposed.

PrimitiveWhat it provesAxisWhen
Refusal LedgerEvery refusal-policy change is on record, and the runtime value falls inside a declared envelope.Policy / upstreamnow (crypto core) policy-system pilot pending
PBS: Provenance-Bonded SandboxEnvironment integrity, continuously, from provisioning through every heartbeat.Environment / upstreamnow (crypto core)
HowlerAn alarm about intent formation fired before the effect emitted, replayable by a third party.Intent / upstreamnow (crypto core)
Perimeter BondThe exact enforcement bytecode intercepting syscalls is bound into every attempt receipt.Network / upstreamnow (crypto core)
Diurnal BondConsequential actions during off-hours require k-of-n countersigning from a signed risk manifold.Time / upstreamnow (crypto core)
Egress BondData leaving the perimeter is metered per semantic class against pre-committed caps.Egress / upstreamnow (crypto core)
Forensic RailPost-incident analysis is bonded to a k-of-n consortium credential and deterministically replayable.Forensics / upstreamnow (crypto core)
Carnac™Reads consequence before effect and routes each read to the proof it warrants.Downstream gatenow
HiveSeal™Where the signing key lives in silicon: a key-side root.Key-side rootnow
AFiRAttested Fragmented Inference Routing: signed routing of an inference across fragments.Compute axisnow
SiGRA specific model at a specific config produced a specific output, signed and checkable offline.Compute axisnow

Motivating incident for the whole seven-primitive filing: the OpenAI / Hugging Face incident. A refusal threshold moved with no external witness. Refusal Ledger is the layer that would have made the change, and the operator's compliance with its own stated bounds, independently checkable.

Pilot Refusal Ledger on real policy infrastructure

We're looking for model operators and safety teams with an existing refusal-policy configuration system to take the crypto core to a live pilot. You bring the policy store. We wire the mutation ledger and the envelope-bond proof into your change path, run the four scenario tests against your real configuration flow, and you walk out with the first policy-change record a regulator, auditor, or the public can check without ever seeing your threshold.

Refusal Ledger. Patent Pending. Proves every refusal-policy configuration change is on record, and that the runtime policy value in force falls inside a pre-declared public envelope, without disclosing the value, signed independently with ML-DSA-65 (FIPS 204), checkable offline. Cryptographic core built and proven: 37 of 37 smoke tests pass across the seven-primitive filing. Filed July 26, 2026. USPTO application 64/119,279. Real policy-system integration is pilot-ready, not yet deployed. We never fake a receipt.

Private by design. Hive does not store your prompts. Every request is already receipted by a one-way SHA-256 fingerprint, not the words. Proof, not surveillance.