Abstract
FieldHash is an independent authority and evidence layer for enterprise AI. It materializes the authority state supplied by customer systems and authorized reviewers, governs which retrieved records, agent actions, and reviewed decisions may influence the next answer or action, and records the path in an evidence packet. It works with the customer's existing model, memory store, database, review system, and tool registry.
Governed Memory controls memory influence: approved/current records can shape the model input; stale, rejected, superseded, out-of-scope, or rolled-back records remain reviewable but blocked from steering future answers without review.
Governed Actions applies the same authority pattern to agent actions and execution paths: unauthorized tools are blocked from selection, and unapproved execution payloads are halted before they run. At the MCP boundary, the versioned adapter governs discovery, resource and prompt influence, interactive lineage, and exact calls over stdio or stateless HTTP.
Governed Precedent lets review compound into bounded authority state outside the model: reusable only inside the policy, scope, expiry, evidence, and dependency envelope that made the decision valid.
The Governed Learning Loop is the controlled process around those surfaces: uncertainty returns to authorized review, approved outcomes update external Authority State, and reviewed judgments may become Governed Precedent when the workflow's authority policy permits reuse. Future use remains linked to the original evidence and stops when its authority changes.
FieldHash does not decide truth by itself. Customer systems of record, review signals, supersession events, and rollback operations define real-world authority for a workflow; FieldHash enforces configured authority evidence inside governed workflows before context reaches the model.
FieldHash Ledger records the decision surface: evidence packets, packet hashes, checkpoint references, customer-owned exports, and stronger signing or transparency anchoring where configured. Base packets make the governed path reviewable; operator resistance depends on where anchors, logs, and keys are held.
In plain English
Retrieval answers “what looks relevant?” FieldHash asks, “is this record, tool, or reviewed decision allowed to shape the answer or action, and can we prove what happened later?”
Product
Independent authority gate between retrieval, agent action, review, and generation.
Buyer
AI platform, security, legal, compliance, and model-risk teams.
Failure mode
Stale or rejected records can still look relevant enough to shape an answer.
Proof boundary
Self-administered diagnostics support governed answer-path control; they are not third-party validation.
The enterprise problem
Enterprise AI agents increasingly retrieve memory from databases, vector stores, knowledge graphs, tickets, chats, and documents. The hard question is no longer only whether a fact can be retrieved. It is whether that fact is still authorized to shape the answer.
Stale memory still looks relevant
A superseded decision can remain semantically close to the query and keep winning retrieval.
Rejected context stays in the corpus
Rejected proposals and noisy notes are often kept for audit, but should not become future priors without review.
Rollback is state, not prose
A rollback may be encoded in an operation log rather than in the visible text of the later memory record.
Reviewers need the answer path
Security, legal, compliance, and model-risk teams need to know what entered the model input and what was blocked.
The core failure mode: memory systems store context, but storage alone does not decide or prove authority. FieldHash is the answer-path governance layer.
Product architecture
The stack separates storage, governance, ledgering, and generation. That separation is the commercial point: you keep your memory substrate and model route while adding governed influence control.
Simple workflows can use simple flags. FieldHash is designed for the workflows where authority spans stores, reviewers, supersession chains, rollback operations, scope boundaries, and evidence requirements.
Authority State can maintain a customer-scoped, versioned projection of connected authority between handoffs. It tracks which workflows and precedents depend on that state and revalidates those direct dependencies when source state changes.
FieldHash can also govern memory cleanup and consolidation decisions. When teams reduce redundant context, approved/current records remain protected on the answer path, and the evidence packet records what was retained, blocked, or excluded where configured.
| Layer | Technology | Function |
|---|---|---|
| Candidate sources | Oracle, Zep, Mem0, vector search, graph memory, Postgres, internal KBs | FieldHash does not need to be the memory database, tool registry, review system, or model route. It receives candidates from customer-approved substrates. |
| Authority State | Tenant-scoped source events, source bindings, versioned projections, freshness, workflow bindings, and precedent dependencies | Maintains the derived authority state required at the handoff and identifies what must be revalidated when connected source state changes. |
| Governed Learning Loop | Review tasks, verified reviewer outcomes, Authority State updates, validity envelopes, dependency revalidation, and lineage | Lets authorized review improve future handoffs while preventing stale, expired, revoked, or unsupported learning from carrying forward. |
| Governed Memory | Authority status, scope, supersession, rollback, rejection, and compaction metadata | Resolves authority state, enforces which records may influence this answer, and keeps blocked records visible for audit. |
| Governed Actions | Authorization status, revocation records, tool scope, registry metadata, MCP action hashes, and policy state | Enforces which action candidates remain available to the agent, checks exact-payload approval or bounded precedent where configured, and records blocked alternatives for review. |
| MCP adapter | Versioned 2025 and 2026 protocol profiles; stdio and stateless HTTP; discovery, tools, resources, prompts, completion, governed subscriptions, multi-round input, bounded opt-in Tasks, and privacy-bounded evidence | Governs what MCP lets an agent discover, receive, and dispatch; binds transport and identity context to exact actions; and denies unknown inline requests or notifications unless explicitly allowlisted. |
| Computer-use reference | Structured Playwright-compatible actions, exact action hashes, pinned approvals, routed-origin containment, popup closure, download cancellation, and pre/post-dispatch Ledger receipts | Governs the structured action around an instrumented browser step and records dispatch completion separately from later containment outcome, without treating pixels, screenshots, or model narration as authority. |
| Governed Precedent | Reviewer decisions, policy hierarchy, scope, expiry, dependency hashes, and suspension state | Reuses reviewed authority decisions only while their validity envelope still holds; drift, expiry, conflict, or missing evidence routes back to review. |
| Semantic binding gate | Canonicalization, profiled semantic support checks, caveat state, abstention thresholds, and verifier-backed packet eligibility | Checks whether configured authority safely supports the answerable fact inside a validated resolver path before a clean packet is allowed. |
| Governance engine | Policy gates, state transitions, bounded commit, rollback, and negative controls | Applies governed-state rules that allow, block, caveat, supersede, retract, or route candidate influence back to review. |
| FieldHash Ledger | Packet hashes, customer-owned exports, checkpoint signing, and transparency anchoring where configured | Records what was approved, rejected, rolled back, blocked, and sent to the model so reviewers can verify the answer path. |
| Model route | Customer-approved hosted, EU-cloud, VPC, or local/on-prem model | Receives only the context FieldHash allows. The base model is not retrained without explicit configuration during normal operation. |
| Deployment substrate | Versioned Govern, Ledger, and MCP Python packages, CI-built reference images, deployment preflight, and offline verification | Supports a single-tenant reference deployment without requiring you to replace your model or memory store first. Customer identity, network, custody, retention, and recovery controls remain deployment-specific. |
Current implementation boundary
Governed Learning does not mean online model training. FieldHash records authorized changes outside the model. Model output, confidence, or observed success may propose a candidate update, but cannot grant that update authority by itself.
The current Authority State pilot path accepts customer sources exposed through a read-only SQL projection or signed event contract. Managed SaaS connectors remain design-partner scoped. The first vendor-specific pair will be selected against a real workflow and its source and change-event contract.
The supporting connector reliability diagnostic publishes the bounded restart, signed-event, complete-projection replay, and exact-impact results with its verification manifest. The scale path scans and normalizes the full connector workload; a configured subset enters Authority State projection.
FieldHash preserves the legacy MCP 2025 stdio path and supports the MCP 2026-07-28 core over modern-only stdio or stateless Streamable HTTP. The current profile governs server discovery, tools, resources, prompts, completion, subscriptions, and multi-round input. Its bounded Tasks profile is opt-in, requires client/server negotiation and finite lifetime metadata, and receives durable lineage. Polled and subscribed completed Task results are rechecked against current tool authority at delivery before returning. Outstanding interaction keys are hash-bound and accepted once, and reused Task identities must match their original creation snapshot. FieldHash says routed to review only after it creates a review task; without a configured queue, the request or result is marked withheld. Subscription registrations are identity- and scope-bound in the lifecycle store, but a disconnected client must re-establish the listen request before notifications continue. Unknown inline requests or notifications are denied unless explicitly allowlisted. Upstream OAuth, server permissions, and UI-host containment remain outside FieldHash; authentication identifies the caller but does not grant workflow authority.
The current computer-use path is a structured Playwright-compatible reference. The default path launches a fresh context with downloads disabled and service workers blocked. Reusing an existing CDP context is an explicit, weaker containment profile. The host must supply the intended action packet. High-consequence dispatch requires pinned approval trust and runtime origin containment; configured Ledger mode records dispatch completion, possible external effect, and any later containment violation separately. FieldHash does not infer authority from pixels or operate as a managed browser service.
Keep your store
FieldHash can sit behind existing retrieval infrastructure rather than replacing it.
Govern influence
Memory status, scope, supersession, and rollback decide whether a record reaches the model.
Verify the path
Evidence packets and ledger artifacts let reviewers inspect what happened after the fact.
Governed inference loop
A governed inference event is not a generic memory write, tool call, or model prompt. It is a bounded authority-state transition: retrieve candidate context or actions, classify authority, apply scope and supersession, reuse valid precedents only when their envelope still holds, build the handoff sent forward, and record what happened. It does not mean training the model on customer data.
Retrieve candidate records, memories, tools, or reviewed precedent candidates from approved systems.
Apply governed-state metadata: current, superseded, rejected, revoked, rolled back, expired, or out of scope.
Check whether configured authority safely binds to the answerable fact or action inside the configured resolver path before a clean packet is allowed.
Construct the handoff from only approved, supported, and caveated inputs.
Keep blocked records, actions, and precedents visible in evidence without letting them steer the answer.
Record governance reasons, selected inputs, blocked alternatives, packet hashes, and ledger references.
Evidence: Governed inference proof paths
Public diagnostics with explicit boundaries
The proof path is staged: the loop synthesis maps the operating model; Governed Actions, Governed Memory, and Governed Precedent carry the flagship claims; the research archive publishes semantic limits, ties, losses, and supporting diagnostics separately.
The Governed Learning Loop
LOOPStart here
See how uncertainty returns to authorized review, approved outcomes become bounded external authority, and drift suspends reuse.
Read proof path
Governed Actions
ACTIONSTool use and execution
Part I tests revoked tool versions on real PyPI yank data. Part II tests consequential execution and exact-payload approvals. Together they show the same control before selection and dispatch.
Read proof path
Governed Memory (MemConflict)
MEMORYGoverning record only
FieldHash forwards the governing record, withholds the superseded alternative, and records the governed context supplied for the answer.
Read proof path
Governed Precedent
PRECEDENTReview compounds within bounds
A reviewed decision can guide a later case only while its scope and evidence still hold. In adversarial traps, expired, drifted, conflicted, or unsupported precedents never received a clean allow.
Read proof path
Boundary Research
BOUNDARIESTies, losses, and limits
Semantic support, authority inference, public-corpus ablations, and answer attribution show where the mechanism holds, where simpler controls are enough, and where the claim stops.
Read proof path
Methods report
The governed-context evidence package includes the consolidated FieldHash methods report, aggregate figures, source-artifact hashes, and public claim boundaries. Download the FieldHash methods report.
Latency diagnostic
FieldHash runs after retrieval and before generation. A local pre-generation diagnostic measured the deterministic governance path, not the full application path.
100 candidate memories
3.87-3.89 ms p50
FieldHash enforcement across three 500-iteration local runs.
Ledger evidence add-on
+0.09-0.10 ms p50
Hash-chained evidence serialization plus a local JSONL write over enforcement.
Boundary
local only
No retrieval, network, external provider, or model-generation calls were included.
Claim boundary
This supports a narrow deployment claim: the local governance step was millisecond-scale under this diagnostic. It is not a production SLO, not a network benchmark, and not an end-to-end latency guarantee.
FieldHash Ledger evidence
Current diligence starts with the executable govern and ledger packages, their package tests, the reference single-tenant deployment path, and offline packet verification. Historical enterprise prototype artifacts are retained in the repository but are explicitly excluded from current release substantiation.
Package contract
Python 3.11-3.13
The Govern, Ledger, and MCP packages build as wheels and run standalone package tests across the supported Python matrix.
Published integration
Executable in CI
The public govern-and-verify snippet runs before the site deploys, including blocked-record handling and signer-pinned packet verification.
Reference images
Built in CI
The single-tenant control-plane image and static operator-console image are built from the current checkout. The console image is checked for a static-only runtime.
Verification boundary
Manifest + CLI
Current diligence covers package source, tests, deployment guidance, packet verification, and the offline ledger CLI. Customer-specific infrastructure is validated inside the pilot SOW.
Qualified diligence
Standard governed-inference deployments do not require specialized assurance infrastructure. For long-retention or disputed-evidence workflows, deeper technical review can cover stronger signing profiles, customer key custody, transparency anchoring retained outside the operator boundary, or advanced provenance profiles where configured.
Enterprise deployment posture
Model/store agnostic
FieldHash can govern candidate context, action candidates, and reviewed precedents from existing systems while routing to customer-approved hosted, EU-cloud, VPC, or local models.
Reviewer-facing evidence
The product is designed to show what influenced an answer, what was blocked, and which governance reason applied.
Controlled inline boundary
After pilot acceptance, the embedded production handoff requires clean-only context, signer-pinned verification, and durable append before a clean allow returns.
Not a compliance guarantee
FieldHash can generate review artifacts for legal, model-risk, security, and governance teams; it does not replace counsel or certify statutory compliance by itself.
Private deployment path
The architecture supports VPC/on-prem patterns and customer-controlled infrastructure where you require it.
Related work and positioning
Stateful and memory-augmented LLM agents are an active area. Relevant reference points include Letta/MemGPT for agent-managed context, Mem0 for production memory across users and sessions, Zep for temporal knowledge-graph memory, Oracle-style enterprise memory substrates, and retrieval-centric systems such as HippoRAG.
FieldHash's narrow claim is not “we are the database of memory,” and not “we infer truth from arbitrary prose.” The claim is answer-path and action-path governance: given candidate memory, tools, reviewed precedents, and authority evidence from trusted workflows, enforce what may influence this answer or action, keep blocked alternatives reviewable, and produce evidence of the decision path.
Incorrect upstream authority can still be enforced. The value is that the decision path remains inspectable and correctable: reviewers can see which signal governed, which records were withheld, and where the authority decision must be changed if the source system is wrong.
Limitations
FieldHash does not update base-LLM weights during normal use.
The governed-inference studies are self-administered diagnostics with explicit caveats, not third-party validation.
Authority inference from arbitrary prose is separate from enforcement of explicit governed state; semantic binding results are profile-scoped unless customer-corpus or cross-generator validation is run.
Base ledger packets are reviewer-verifiable records. Stronger tamper evidence and operator resistance require configured anchors, logs, key custody, and retention procedures.
Advanced assurance profiles depend on configured dependencies and verified deployment settings.
Status
- Governed Memory is implemented as an answer-path control layer for candidate context.
- Governed Actions is implemented as an action-path control layer where configured.
- Governed Precedent is implemented as bounded reuse of reviewed authority decisions where configured.
- Semantic binding and abstention gates are tested as configured packet-eligibility controls, not as autonomous truth inference or open-world semantic generalization.
- Current govern, ledger, deployment, and verification artifacts are classified in a reviewed diligence manifest.
- Governed proof paths are linked with explicit caveats, sample sizes, and methodology notes.
For technical diligence
Public materials summarize FieldHash at a product and evidence level. The FieldHash governed-context methods report is available as a direct PDF; deeper architecture notes, benchmark methodology, ablation summaries, trace examples, evidence-export examples, and governance controls are available selectively for qualified technical reviewers.