Put governance in the AI handoff.

Where the gate sits

Your store retrieves. FieldHash governs. Your model answers.

Your retrieval layer can search broadly. FieldHash narrows the handoff to what your policy allows, separating approved inputs from blocked alternatives before model output, tool execution, or a computer-use action. Canonical and semantic binding rules handle the cases where source wording differs.

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"])

The package split is deliberate: fieldhash-govern decides what may influence the answer or action, fieldhash-mcp applies that decision at the MCP protocol boundary, and fieldhash-ledger seals and preserves the resulting packet for verification. Pilot installs can run the gate alone, add the MCP sidecar where relevant, or attach a ledger seal for offline verification and signer-pinned review. Controlled inline deployments use the production handoff wrapper and a durable ledger store so a clean allow is returned only after the sealed event is recorded.

Deployment 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.

Re-fetching fresher data keeps the inputs current, but it leaves the model free to select the wrong candidate. FieldHash enforces policy structurally by removing unauthorized candidates from the payload entirely before it reaches the model and, where packet sealing is configured, recording the exclusion in a tamper-evident evidence packet.

MCP integration

Govern what MCP lets the agent discover, receive, and do.

The fieldhash-mcp gateway runs between an MCP host and upstream server. The preserved 2025 profile uses stdio. FieldHash supports the MCP 2026-07-28 core over modern-only stdio and stateless Streamable HTTP, beginning with server discovery rather than a session handshake.

The new protocol makes this boundary more important, not less. Stateless HTTP, standardized Apps and Tasks, and hardened OAuth make MCP easier to deploy; they still do not determine whether a particular tool, prompt, resource, or exact call is authorized for this workflow. Anthropic describes support as rolling out across Claude products.

The same boundary governs tool discovery and exact calls, resource and prompt influence, completion references, subscriptions, and multi-round input. The Tasks profile is bounded and opt-in; MCP Apps support covers descriptor, resource, and gateway-routed call governance rather than app-runtime containment. Arguments, client input, prompt and resource contents, and tool results are hashed for decision evidence, not copied into the Ledger.

A conformance harness places the official MCP SDK client and server packages on opposite sides of FieldHash over both supported modern transports. It verifies the MCP 2026-07-28 profile across discovery, governed tool listing and dispatch, instruction withholding, and authority-safe cache hints. This is protocol interoperability evidence, not customer validation, Anthropic certification, or proof that every Claude surface has enabled the revision.

Computer-use reference

Govern the intended browser step before it runs.

The Playwright-compatible reference governs structured navigation, clicks, form input, key presses, selection, checkbox changes, and file upload. The host proposes the step; FieldHash checks authority, exact approval, runtime network containment, and the evidence boundary before dispatch.

FieldHash does not inspect pixels or infer permission from a screenshot. The browser or desktop runtime must expose the intended action as a structured packet. Where the Ledger is required, FieldHash records the pre-dispatch decision, whether dispatch returned, whether an external effect may be partial, and any containment violation observed afterward.

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: a read-only SQL projection for backfill and polling, and a signed webhook contract for approval, exception, revocation, ownership, and policy events. These connectors feed a minimized, versioned authority-state projection with source freshness, workflow bindings, and precedent dependencies.

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.

Authority State

Keep connected authority current between handoffs.

Authority State is a minimized, versioned projection maintained by FieldHash. Customer systems remain the systems of record. The projection contains only the state needed at the AI boundary: source identities, status, scope, effective time, freshness, workflow bindings, and precedent dependencies.

When a connected policy, approval, revocation, expiry, owner, or required source-health signal changes, FieldHash recomputes the affected authority object, finds the workflows and precedents bound to it, suspends unsafe reuse, and records the review path.

Configured dependency bindings limit revalidation to recorded workflows and precedents directly bound to the changed authority object.

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.

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, that work can compound into governed precedent: which source won, why it applied, where it applies, and what change should suspend reuse. FieldHash records that precedent as governance state outside the model; it does not train the model on review history.

FieldHash calls those limits the validity envelope. If the connector, schema, owner, policy hierarchy, approval workflow, expiry window, or verification state changes, the precedent can be suspended and the next case sent back to review.

Integration modes

Embed the gate or wrap it as a service.

The enforcement contract stays the same: candidates in, governed context or actions out, and a separate evidence packet for review.

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.