VerdifaX

What is Verdifax?

Verdifax is a cryptographic record layer for AI. It seals each AI execution submitted to it into a record bound to a SHA-256 manifest hash and anchors it on a public transparency log: the complete record for records sealed from run 238 on, the run's key values for earlier records. Any third party holding that record can check offline, without trusting Verdifax, that it is internally consistent and that what it anchors matches the public log.

In one sentence

Verdifax seals a record of each AI execution submitted to it into a cryptographic artifact, produces a SHA-256 hash that the sealed record is bound to, and anchors it on a public log, so anyone holding that record can confirm that what it anchors (the complete record from run 239 on, the run's key values before then; run 238 also carries a complete-record entry, but deleting it only lowers the verdict to partial coverage) has not been altered since it was anchored.

What problem does it actually solve

AI systems make decisions that affect money, health, and national security. When those decisions are questioned by a regulator, a court, or a counterparty, the operator typically reaches for logs. Logs have three fundamental problems:

  1. Logs can be edited. A log file is a story the operator tells about themselves. There is no cryptographic guarantee it reflects what actually ran.
  2. Models cannot explain themselves. "Show me the SHAP values" is not a compliance answer.
  3. Evidence breaks at the worst possible moment. The day a regulator asks "what AI made this decision?" is the day you discover your audit trail does not actually trace anything.

Verdifax adds a cryptographic seal to the record, and a regulator can check it on their own machine. What the public log binds depends on when the record was sealed:

  • From run 238 (2026-10-16, 17:06 UTC) on: a second public-log entry, the complete-record anchor, binds a digest of every section of the record, so a rewritten section no longer matches that entry. From run 239 on, the first entry also states that the second is required, so deleting the second entry is detectable too. Since verifier 0.12.0, a public-log entry counts only if it is signed with a published Verdifax log-signing key and the timestamp the log signs for it verifies, so a rewritten record that anyone else logs as a new entry fails. Verdifax holds that key. From run 240 on, each record seals a 600-second anchoring window, so a later re-log, even by Verdifax, fails or must carry a new sealed date; earlier records show their authenticated anchoring time but cannot fail on it.
  • Before run 238: the entry binds the run's identity and, on leaf v5 records (runs 236 and 237), its 33 pre-anchor values, which include the attested decision, the AIVP governance result, the payload hash, the actor and the scaffold flags. The descriptive sections (outcome summary, request substance, authorization and approval chain, real-world effects, system provenance) are sealed by hashes inside the bundle but are not bound to the public log, so they show the bundle is internally consistent, not that a party able to rewrite the whole bundle has not changed them.

What you get when you run Verdifax

Every execution produces an ExecutionManifest, a structured record of the run, which is collapsed into a single 64-character SHA-256 hash. That hash is the proof artifact. It can be:

  • Pasted into a compliance report
  • Sent to a regulator as evidence
  • Stored alongside the model output of the run
  • Checked against the run's sealed audit bundle by anyone holding it, at any time, offline: the open-source verifier recomputes every section hash from the bundle's own fields, confirms every section carries this hash, and checks the anchored values against the public log

If any recomputed hash doesn't match, the record has changed since it was sealed. If every hash matches and verifier 0.14.5 or later reports COMPLETE RECORD ANCHORED, every section is the one Verdifax anchored. On a record sealed before run 238 only the anchored values are covered; a party able to rewrite the whole bundle could still have changed the descriptive sections and recomputed their hashes.

What Verdifax is not

Read this section. It matters.

Honesty

Verdifax does not certify that an AI decision is correct, how it was made, or that the system operated truthfully. A sealed record shows that the record is internally consistent and, when the run was anchored to the public transparency log, that what it anchors has not changed since it was logged and when that happened. We say this loudly because the difference is important to regulators and to you.

Specifically, Verdifax does not:

  • Evaluate whether the model's output is accurate, fair, or safe.
  • Verify that training data was lawfully obtained.
  • Make claims about bias or alignment.
  • Replace red-teaming, evaluation, or human review.

What Verdifax provides is a sealed record for those other claims: when you record that "this model produced this output for this input in this environment", Verdifax seals that record so a later change to what it anchors no longer matches its public-log entry: the complete record from run 239 on; on earlier records, the anchored values only (run 238 also carries a complete-record entry, but deleting it only lowers the verdict to partial coverage), with the environment and other descriptive sections sealed inside the bundle but not bound to the public log. It does not prove that what the record says is true.

Where Verdifax fits

Verdifax sits between your AI system and your auditor:

Inputs ──► AI system ──► Output
                │
                └──► Verdifax pipeline ──► Manifest Hash ──► Auditor

To check the sealed record, the auditor does not have to trust your AI vendor. They check its section hashes against the manifest hash and its anchored values against the public log, independently; submitting the same inputs again would create a new run with a different hash, so the check works from the record, not from the inputs.

Continue