The review problem
A governance gate is only useful if reviewers can inspect what happened later. If an answer or agent action is challenged, legal, security, compliance, and model-risk teams need more than the final response. They need the governed path.
FieldHash Ledger is the evidence layer for that path. It records what happened: which memory entered model context, which action moved forward, what stayed out, and why.
Retrieval explains what looked relevant. Tool registries explain what exists. FieldHash Ledger helps reviewers verify what was allowed to influence the answer or action.
What the Ledger records
Approved context passed to the model
Blocked stale, rejected, superseded, or out-of-scope records
Governance reasons, scope metadata, and policy references
Rollback and supersession links where available
Packet hashes, checkpoint references, and signed evidence records where configured
Exports for reviewer, SIEM, GRC, or internal audit workflows where configured
Standard evidence posture
The default story is deliberately boring: capture the governed-inference decision, hash the relevant evidence, and export a packet reviewers can inspect without rerunning the model. Stronger tamper evidence depends on the deployment profile: checkpoint signing, customer-owned logs, key custody, or external anchoring where configured.
Evidence packet
A compact record of allowed context, blocked records, governance reasons, source references, and answer-path metadata.
Customer-owned logs
Deployments can export events to customer review systems, SIEM/GRC workflows, or internal audit stores where configured.
Configured checkpoints
Governance events can be hash-chained, checkpointed, signed, or externally anchored where configured. Operator resistance is strongest when anchors or keys sit outside the operator boundary.
Local review
Evidence packets are designed for reviewer inspection without requiring raw protected content to be sent to a third-party validator.
Assurance is configured, not assumed.
A local packet can make the answer path reviewable. It does not, by itself, make the operator unable to rewrite history. Buyers who need stronger operator resistance should configure customer-owned exports, signing custody, checkpoint retention, or transparency anchoring in the deployment agreement.
Tier 1
Reviewable packet
Records allowed and blocked items, reason codes, authority-source references, a packet hash, and the prior hash for reviewer inspection.
Tier 2
Signed packet
Binds the exact packet payload to an expected signer so a reviewer can verify both the content and signing identity.
Tier 3
Externally anchored evidence
Uses customer-owned logs, external anchoring, or customer key custody where stronger resistance to operator-side rewriting is required.
Boundaries
Base packets are reviewer-verifiable records, not an out-of-the-box guarantee against operator-side rewriting.
Not a legal-compliance guarantee.
Not proof that every private memory, transient model output, or internal trace is public or permanently signed.
Tamper evidence is conditional: operator resistance depends on deployment configuration, key custody, anchor retention outside the operator boundary, infrastructure controls, and customer procedures.
Advanced assurance profiles
Deeper evidence options are available where the use case requires them.
For long-retention or disputed-evidence workflows, qualified deployments can add hash-chained checkpoints, stronger signing profiles including post-quantum signature options where configured, customer key custody, or transparency anchoring retained outside the operator boundary. Those options are an advanced assurance layer, not the starting point for governed memory.
Open advanced assurance briefStart with one answer path.
Bring one agent workflow. FieldHash will show which memories would have reached the model, which would have been blocked, and what evidence your reviewers can inspect.
Request pilot review