Unverifiable Policy Logs

Teams often say: “We logged it.”

That’s necessary—but it’s not sufficient when the question is proof.

The problem

When a customer asks:

…teams end up reconstructing events from scattered logs, dashboards, and tribal knowledge. They piece together what probably happened, not what provably happened.

What makes logs “unverifiable”

A log is unverifiable when you can’t independently answer at least one of these questions:

QuestionWhy it matters
Was this record altered after it was written?Silent edits destroy trust
Does this record match the exact policy version that executed?Policy drift creates confusion
Can we prove which inputs were used (without exposing sensitive data)?Compliance requires context
Can a third party validate the claim without trusting our database?External audits need independence

In practice, traditional logs are easy to:

None of these changes leave a trace. The log says what it says—and you have to trust it.

The Hexarch approach

Treat every decision like it produces a receipt:

  1. Commit the decision event to a tamper-evident hash chain
  2. Sign the commitment (so you can verify authorship)
  3. Use selective disclosure (Merkle proofs) so you can prove correctness without leaking PII

The result: evidence that can be verified independently. Not “we logged it”—“here’s the proof, check it yourself.”

What this looks like

Without Hexarch:

"The user was denied because... let me check the logs...
it looks like policy X was active at the time...
I think this is the right record..."

With Hexarch:

{
  "decision": "DENY",
  "policy_id": "pol_abc123",
  "policy_version": 7,
  "actor_id": "user_xyz",
  "timestamp": "2026-01-15T14:32:01Z",
  "audit_hash": "sha256:9f86d08...",
  "prev_hash": "sha256:d7a8fbb...",
  "signature": "..."
}

Verify the hash chain. Check the signature. The record speaks for itself.

Try it

Next steps