Put governance in the AI handoff.
FieldHash applies customer-defined authority at context, action, and reviewed-decision handoffs. It connects the governing records and earlier decisions each use depends on.
Customer systems and authorized reviewers establish that authority. FieldHash checks whether it still applies before information influences an answer, an effect proceeds, or a reviewed decision carries forward. Coverage depends on the handoffs and execution paths you connect.
- You supply
- Candidate records, proposed actions, or reviewed decisions, plus the authority signals your systems and reviewers maintain.
- FieldHash returns
- Allowed context, blocked alternatives, review routes, and an evidence packet.
- What proceeds
- Allowed context, authorized actions, or reviewed decisions whose reuse conditions hold. Uncertain cases stay out or return to review.
- What reviewers inspect
- The authority source, reason code, policy result, and packet reference.
Connect the authority check to the use it governs.
These are separate package interfaces for the handoffs a workflow needs. The context example below does not authorize an action or make an earlier decision reusable by itself.
Information that may influence
govern separates clean context, caveated review context, and blocked records. The production context wrapper requires a pinned signer and durable, verified Ledger append before returning an allow.
Effects that may proceed
build_action_gate_packet classifies a proposed action. Where approval is required, verify_action_execution checks the signed decision against the exact action and pinned signer. Supply allowed_approvers to enforce which named approvers are permitted; omitting it skips that check. The host must enforce the result at dispatch.
Reviewed decisions that may carry forward
compile_review_outcome_to_precedent records reviewed authority with scope, expiry, and dependencies. evaluate_precedent_reuse checks those conditions for a later case; invalid reuse returns to review.
Connected Authority State identifies affected workflows and precedents from their recorded dependencies when a source changes. The pilot defines source bindings, freshness, trusted identities, and enforcement coverage. A reusable review decision does not replace exact-action approval or the workflow's other controls.
The shipped kernel enforces per-workflow cumulative budgets. Shared limits across cooperating agents were demonstrated in the organization study's harness; that shared-budget runtime is a qualified research candidate, not part of the current pilot deployment.
Read the authority-continuity evidence synthesisContext path · one governed surface
Your store retrieves. FieldHash governs. Your model answers.
This integration shows Governed Memory after retrieval and before generation. Your store supplies candidate records. FieldHash checks which may influence the answer and keeps withheld alternatives available for review. Configured binding rules check whether a known governing source supports the proposed answer.
If an incoming record cannot be tied to an active authority signal under the configured resolver, it stays out or goes to human review. Uncertainty does not become approval by default.
from fieldhash_govern import govern, verify_evidence_packet_seal
result = govern(candidates, query_text=query, seal_packet=True, require_ledger_package=True)
evidence_packet = result["evidence_packet"]
seal = result["ledger_seal"]
verification = verify_evidence_packet_seal(
evidence_packet,
seal,
expected_key_fingerprint=deployment_policy["ledger_key_fingerprint"],
expected_signature_algorithm=deployment_policy["signature_algorithm"],
)
if not verification["verified"]:
raise RuntimeError("FieldHash evidence verification failed")
if result["summary"]["caveated_count"]:
route_to_review(evidence_packet)
else:
release_to_model(result["clean_context"])fieldhash-govern decides what may proceed, fieldhash-mcp applies the decision at the MCP boundary, and fieldhash-ledger seals and preserves the packet. The example shows the package-level steps. Controlled inline deployments use the production handoff wrapper with a durable ledger: it returns a clean allow only after the seal and recorded chain verify.
Review the FieldHash LedgerDeployment boundary: a local seal is tamper-evident against its embedded signing key. High-stakes operator resistance requires configured key custody, expected-signer pinning, optional PQC signing, and external anchoring where the SOW requires it.
Synthetic example
Illustrative handoff demo
Explore synthetic candidate states to see what would proceed, stop, or require review. This demo uses no live workflow or customer data.
// GOVERNED HANDOFF TRACE
from fieldhash_govern import govern result = govern( candidates, query_text=query ) approved_context = result["clean_context"] caveated_context = result["caveated_context"] # route to review evidence_packet = result["evidence_packet"]
{
"status": "ALLOW",
"surface": "governed_memory",
"allowed_context": ["current_authority_record"],
"blocked_records": [],
"reason_codes": ["active_authority_verified"],
"packet_hash": "fh_pkt_6021eb65"
}1. Candidates in
Approved/current records, stale or superseded records, rejected records, optional action candidates, and instrumented computer-use steps arrive from the systems you already use.
2. FieldHash decision
The governing record is allowed forward, stale or rejected alternatives are withheld or caveated, revoked actions are removed, and reviewed decisions guide later cases only while their approved conditions still hold.
3. Model or action packet
Only allowed context and authorized actions proceed to the selected model or agent runtime. Browser clicks, shell commands, file edits, and form submissions are governed only when wrapped as action packets. Blocked alternatives stay available for review.
4. Evidence packet
Reviewers get the allowed items, blocked items, reason codes, authority source, and ledger or checkpoint reference for the decision.
MCP integration
Govern what MCP lets the agent discover, receive, and do.
The fieldhash-mcp gateway mediates supported interactions between an MCP host and upstream server at an instrumented authority boundary.
Protocol authentication and transport controls do not determine whether a particular instruction, tool, prompt, resource, or proposed action is authorized for the customer's workflow. FieldHash adds that workflow-level authority decision outside the model.
The same boundary can govern supported discovery, influence, interactive work, deferred work, and action dispatch. Runtime containment and upstream permissions remain separate customer responsibilities.
A conformance harness tests the supported host-to-server boundary across discovery, influence, and mediated dispatch. The harness provides protocol interoperability evidence. Customer validation and provider certification remain outside this test.
Discovery and influence
FieldHash governs supported MCP instructions, tools, resources, prompts, and returned content before they can shape the agent.
Action-bound dispatch
Before a call reaches the server, FieldHash binds the proposed action to the trusted caller, workflow, and execution context. Material changes require a new authority decision.
Interactive and deferred work
Interactive and deferred work remains tied to the originating identity and governed workflow. Results pass through the authority gate again before return.
Review and evidence
FieldHash limits stale reuse, stops blocked or uncertain calls before dispatch, and records privacy-safe evidence.
Prepared, connected-shadow, and connected-inline profiles let a pilot compare current behavior before selected authority decisions become decisive. Interactive and deferred work remains tied to the originating governed workflow, and uncertain results are withheld or returned to review.
Boundary: MCP authentication, upstream permissions, host isolation, and server operation remain upstream. FieldHash governs supported, mediated interactions; it is not a managed MCP host or universal runtime containment layer.
Computer-use reference
Govern the intended browser step before it runs.
The reference integration governs structured, proposed browser operations. The host proposes the step; FieldHash checks current authority and the configured dispatch boundary before the operation proceeds.
FieldHash does not infer permission from pixels or model narration. The browser or desktop runtime supplies a structured action, and the Ledger records the authority decision separately from the observed execution outcome.
Structured intent
The host supplies a structured proposed operation and the trusted workflow context before the step runs.
Action-bound approval
Approval is bound to the structured action and trusted execution context. A material change invalidates prior approval.
Configured dispatch boundary
The reference implementation applies configured browser boundaries around high-consequence dispatch.
Decision and execution evidence
The Ledger records the authority decision and the observed execution outcome as separate evidence.
Current boundary: reference integration, not a managed browser service or universal desktop instrument. Customer authentication, browser custody, session policy, target allowlists, permissions, and unrelated runtime behavior remain deployment controls.
Candidate-input adapters and authority-source connectors
What connects today.
The Python package ships normalization adapters for retrieval results, documents, structured records, and tool catalogs.
Authority State adds a pilot reference path for connected authority using customer-approved source and change signals. These interfaces carry the current authority needed at selected governed handoffs while customer systems remain canonical.
They are reference connector contracts for customer-scoped pilots, not a managed SaaS connector catalog.
A bounded, self-administered diagnostic scanned and normalized 100,000 SQL rows through a forced restart and signature-verified and normalized 100,000 signed events through the declared rejection and ordering checks. A bounded subset exercised Authority State projection and complete replay. It is reference-path evidence, not customer validation or a production SLO.
Inspect connector reliabilityVector-search matches
Normalizes Pinecone-style or already normalized vector matches into the FieldHash candidate contract.
LangChain documents
Accepts Document objects or mappings with page content and metadata.
Structured records
Accepts row-like records with configurable text, status, identifier, and status-map fields.
Tool registries
Normalizes tool catalogs and removes revoked tools before the agent receives its available set.
Customer systems remain canonical. Pilot scope still defines credentials, source permissions, freshness deadlines, tenant boundaries, and the change signals available from each source.
Authority State
Keep connected authority current between handoffs.
Authority State carries current customer-scoped authority between governed handoffs. Customer systems remain the systems of record and authority owners.
When governing conditions change, FieldHash identifies affected use, stops unsafe carry-forward, and records the review path.
Customer-defined scope keeps change handling bounded to the governed workflow.
Prepared
Use authority signals already supplied by the workflow and preserve the evidence-packet path.
Connected shadow
Compare connected authority with current behavior without changing production decisions.
Connected inline
Make current connected authority decisive at selected governed handoffs.
Ownership boundary
Keep your stack. Govern at the boundary.
FieldHash does not replace your database, model, or tool registry. It operates on the handoff payload, checking configured status, scope, freshness, and precedent bounds before context release or execution, with signature verification where configured.
| Layer | Customer owns | FieldHash provides |
|---|---|---|
| Memory source | Vector DB, graph store, documents, tickets, knowledge base, or memory framework | Candidate intake after retrieval |
| Authority signals | Approvals, review status, supersession links, rollback events, systems of record | Authority checks at connected context, action, and reviewed-decision handoffs |
| Authority State | Canonical source systems, source semantics, credentials, and authority ownership | Current authority for the governed workflow, source-health awareness, and change impact |
| Model route | Hosted, private, VPC, local, or on-prem model path | Approved context plus blocked-record evidence |
| Computer-use runtime | Browser, desktop, shell, file, or workflow automation environment | Structured action authority and execution evidence for mediated steps |
| MCP runtime | Host and server authentication, upstream permissions, and runtime isolation | Mediated discovery and action dispatch with lifecycle-aware review and evidence |
| Audit workflow | Reviewer process, SIEM, GRC, legal and security review | Evidence packet and Ledger references where configured |
| Reviewed precedent | Reviewer outcome and customer-defined validity conditions | Bounded reuse, suspension, and evidence |
Authority signals
Where authority signals usually live.
FieldHash works best with evidence the business already maintains: approval state, effective dates, revocations, supersession links, and review decisions. It enforces those signals before the model answers or the agent acts.
When reviewers settle a recurring conflict, an approved decision may guide later cases within customer-defined limits. FieldHash records the authorized outcome outside the model; it does not train the model on review history.
Material change, revocation, expiry, conflict, or missing support stops reuse and returns the next case to review.
Inspect common authority and change signals+
Connector signals
Carries connection and source-health state from configured databases, catalogs, and directories into the validity check.
Authority signals
Carries reviewer approvals, system-of-record status, and explicit governance rules into the handoff.
Change signals
Carries schema, ownership, policy, and source-health changes that can suspend prior authority or route the next case to review.
CLM systems
Effective dates, executed-document state, amendments, and supersession links.
Policy systems
Approval state, version history, review owner, and current policy designation.
Document platforms
SharePoint, Drive, or knowledge-base version chains, permissions, and archive state.
Registries and tool catalogs
Revoked, yanked, deprecated, allowlisted, or environment-scoped tool states.
Security and GRC systems
Policy exceptions, risk approvals, control mappings, and audit ownership.
Human review
Authorized review can update the authority available to a workflow. When policy permits reuse, a reviewed decision may guide later cases within customer-defined limits.
FieldHash does not invent authority. It enforces authority signals your workflow can expose and your reviewers can inspect.
Integration modes
Embed the gate or wrap it as a service.
The workflow supplies candidates and trusted authority signals. The selected interface returns a context, action, or reuse decision with evidence for review. The host applies that decision at the connected handoff.
Govern the selected handoff
Govern context after retrieval, proposed effects before dispatch, and reviewed decisions before reuse. Each surface has its own documented interface and evidence record; connect the ones the workflow needs.
Embedded gate, service, or MCP sidecar
Call the Python package inside your workflow, wrap it as an internal service, or place the versioned MCP gateway between a host and server over stdio or stateless HTTP. Browser and desktop actions remain governable when the runtime represents them as action packets.
Audit sink
Export Governed Memory events, Governed Actions events, computer-use action packets, Governed Precedent reuse events, checkpoints, blocked-record reports, and FieldHash Ledger evidence records for reviewer workflows.
Shadow-mode pilot
Compare the current workflow with governed decisions while production enforcement remains off. Use the agreed measurements to decide whether a selected handoff should enter enforcement.
Model route
Use your chosen model. Keep governance portable.
FieldHash governs context before the model call and action candidates before execution. For computer-use agents, it governs the structured action packet around a click, command, file edit, or form submission; it does not read pixels as authority.
The model can be a hosted frontier API, private endpoint, VPC route, or local/open-weight route where configured. If a team changes providers, the governance record does not reset: approved context, blocked alternatives, action decisions, and evidence packets remain outside the model vendor. Any model-assisted extraction or selection step is recorded by FieldHash Ledger.
Portability is measured, not aspirational: in a published MemConflict extension run, gate decisions were identical across a frontier API and two 4-bit local models (the same 856 records blocked, the same conflicts routed to review), and the governed local arms scored within judge variance of a strong labeled prompt. See the model-invariance addendum.
Hosted pilot
Fastest path for technical review, sample workflows, and benchmark-style trace inspection.
Customer VPC
Deploy the governance layer near customer data, with approved model routing and customer-owned logs where configured.
Private or on-prem
Run against private infrastructure and local model endpoints when data boundaries require it.
Existing memory stores
Use current retrieval systems as candidate sources. Governed Memory controls influence and can govern memory cleanup decisions; it does not require a rip-and-replace memory migration.
Local overhead
The context gate runs before generation.
The context gate runs after retrieval and before the model call. In an internal local diagnostic, this enforcement step remained millisecond-scale at 100 candidate memories. Action and precedent paths were outside that measurement.
Boundary: this measures deterministic local governance overhead only. It is not an end-to-end user latency benchmark and excludes retrieval, network, and model generation time.
Local diagnostic range
500 iterations each
Three repeat runs, one bounded path.
100 candidate memories
3.87-3.89 msp50
FieldHash enforcement across three 500-iteration local runs.
Ledger evidence add-on
+0.09-0.10 msp50
Hash-chained evidence serialization plus a local JSONL write over enforcement.
Measured boundary
0 network calls
No retrieval, no LLM generation, and no external provider calls were included.
Reviewer packet
An evidence packet your reviewers can inspect.
Approved context passed to the model
Authorized tool, execution, or computer-use action candidates allowed forward where configured
Pre-dispatch and post-execution computer-use receipts where a durable Ledger is required
Stale, rejected, superseded, or out-of-scope records blocked from influence
Supporting authority evidence for allowed context
Governance reasons and scope metadata
Reviewer-approved authority precedents where the SOW permits reuse
Whether a reviewed decision was used or returned to review
Rollback and supersession links where available
Memory cleanup or consolidation decisions where configured
Audit events, checkpoints, and FieldHash Ledger evidence where configured
Exports for review, SIEM, GRC, or internal evidence workflows where configured
Claim boundary
What this does not claim.
Not a compliance guarantee.
Not a replacement for your retrieval database or document store.
FieldHash does not decide truth or authorization by itself: systems of record, registries, and review signals define real-world authority. FieldHash enforces configured authority evidence and records what reaches the model or agent.
Not changing your chosen model during normal use.
Not a claim that every private memory, transient output, or internal trace is public or permanently signed.
Not a model-superiority claim or a promise to outperform every one-shot selector.
Failure behavior is explicit, not implied.
No generative model in the gate
The enforcement decision is deterministic rule evaluation over configured record state: status, scope, supersession links, and rollback events. No generative LLM call is required to decide whether configured authority allows the handoff.
Shadow mode does not alter production answers
Pilots run observe-only: FieldHash records what it would have allowed and blocked without touching a single answer. Enforcement is a post-pilot decision, made with latency measured on your corpus rather than quoted from ours.
Failure policy is explicit
Infrastructure failure is distinct from authority failure. Custom or shadow integrations may define a separately recorded failure policy. The controlled production handoff fails closed: if governance, signing, durable append, or ledger verification cannot complete, it does not return a clean allow. Missing or unbindable authority remains caveated or routes to review under the configured policy.
Proposed authority changes are reviewed, signed, and reversible.
In the propose-then-approve path, governed state does not edit itself. Candidate supersession links, status changes, and corrections move through the same motion whether they are drafted by rules, a model pass, or a person: proposed, reviewed, signed, reversible.
Proposed, not assumed
Candidate changes enter a review queue as proposals. A proposal has no influence on answers until it is approved; nothing drafts itself into governed state.
Reviewed in scope
Every proposal declares which records and scopes it touches. Reviewers see the change, the evidence behind it, and which answers it would have altered.
Signed and recorded
Approval creates a signed decision record in the evidence packet. A rejected proposal is retained as evidence with its reason, not dropped without evidence.
Reversible by design
Every promotion carries a rollback path, and rollback is a state change, not a text edit. A reverted decision is no longer eligible for subsequent governed handoffs, and the reversal itself is recorded.
The recovery diagnostic measures the same propose-then-approve motion. Review decides the outcome. See the numbers in the corpus authority series.
Security and deployment
Authentication, private ingress, persistence, key custody, retention, regional hosting, monitoring, and incident response are deployment decisions. They are reviewed separately from the integration call.
Bring one workflow where authority can change.
Tell us what consequential action or decision the workflow makes, which policy, approval, or reviewed decision authorizes it, and what can change before that authority is used. The six-week shadow evaluation measures the difference with production enforcement off.
Request a six-week shadow evaluationInspect the illustrative approval lifecycle