Qualified diligence

Long-retention assurance brief.

Optional evidence profiles for workflows that must preserve governed-decision records beyond the standard pilot path: offline verification, stronger signing, customer key custody, and external anchoring where configured. This is qualified-diligence material, not a core product surface.

The trust gap

A governed-inference packet shows what an AI was allowed into context, what action was allowed forward, what stayed out, and why. For decisions challenged later, including a disputed agent action, an audited model output, or an AI decision under regulatory review, that packet has to stay credible long after the model, the vendor, or the cryptography protecting it has moved on. The same need applies to other long-retention regulated records, compliance packets and public-sector artifacts, where configured. Governed AI is the case this tier is built for.

The retention horizon makes it worse. Records kept for ten to one hundred years can outlive the cryptography protecting them: archives captured today become readable when quantum computers mature, a pattern usually shortened to harvest now, decrypt later. And verification systems that depend on a vendor or a network tend to be unavailable at exactly the moments trust checks matter most.

Post-quantum cryptography answers the first problem and offline verification answers the second. Both are conventional, testable, and the substance of this brief.

PQC is the signing layer. An optional hardware-conditioned provenance tier is an additive evidence layer above it, documented on its own page, for long-retention or disputed-evidence workflows. It does not replace PQC, and most deployments never need it.

Where post-quantum fits

The base layer is deliberately conventional. Evidence packages are signed with NIST-standardized post-quantum signatures (ML-DSA/Dilithium), events are hash-chained, signing keys can stay in Vault, KMS, or HSM custody where configured, and verification runs locally through versioned standard, hardened, strict, or offline profiles. None of that requires quantum hardware, and none of it requires FieldHash to be reachable.

Everything in this brief lives at that layer. The point is durability without dependency: a certificate that stays meaningful when the issuing vendor, the original model, or the network it was created on is no longer around.

Operational guarantees

These are the properties a security review can test directly, independent of any quantum claim.

Verifies offline, without us

Verification runs locally against the signed evidence package. It does not require FieldHash services, network access, or the original backend provider to be reachable.

Policy-labeled trust tiers

Versioned standard, hardened, strict, and offline profiles set explicit acceptance policy. Hardware-backed and simulation-backed evidence are labeled distinctly.

Keys stay in custody

Signing can run against Vault, KMS, or HSM custody where configured, so private keys do not pass through application memory.

Hashes, not content

Evidence packages carry content digests and measurement statistics, not raw document content.

A certificate issued today should verify in ten years, on a disconnected machine, whether or not the issuing vendor still exists. Evidence that needs its vendor alive is assertion, not evidence.

Where it applies

The first workflows are ones where an AI decision, or the record behind it, must stay credible across time, jurisdictional boundaries, and disconnected verification.

AI under regulatory review

Bind model outputs and agent actions to evidence of what governed them, so a decision questioned later can be reconstructed rather than re-argued.

Compliance evidence

Maintain offline-verifiable integrity for audit packets, regulated artifacts, and long-retention submissions.

Long-retention records

Preserve tamper evidence for institutional records that must outlive the application stack, the vendor, and the cryptography protecting them today.

Public-sector artifacts

Keep public records verifiable by any party, on a disconnected machine, years after the record was created.

European enterprise posture

For European regulated teams, this layer earns its place as evidence, not as a compliance claim. Read against the obligations those teams are preparing for, the mapping is concrete:

Logging and traceability (AI Act Art. 12)A hash-chained record of which governed records shaped each answer, and what was held back.
Human oversight (Art. 14)Manual-review routing, with the blocked and rejected context preserved for a reviewer to inspect.
Transparency (Art. 13)An inspectable packet of what entered context, what was refused, and why.
Technical documentation (Annex IV)Published, reproducible methods and standard-library verifiers behind every evidence claim.
Data minimization (GDPR)Packets carry content digests and measurement statistics, not raw document content.

FieldHash supplies evidence, not a compliance verdict. The mapping shows where the evidence meets the obligation; your counsel decides whether the obligation is met.

How that evidence is deployed in Europe, from regional hosting to transfer terms and customer-owned audit logs, is the deployment review's job, not this brief's. The operating boundary lives on the security and deployment page.

The optional hardware-conditioned tier

For the rare record where an algorithmic signature alone will not settle a future dispute, FieldHash Ledger offers an optional tier that binds the artifact to measured hardware behavior. It sits above everything in this brief, and most deployments never reach for it. It is documented separately so it does not crowd the layer most teams actually deploy.

Hardware-conditioned provenance

Take it further

The published governed-context evidence, with methods, limits, and a falsification run, is the proof behind the layer this brief describes.