Governance Fidelity Theory

A language migration. Not a new product.

I asked an agent to convert an existing front end from JavaScript to TypeScript. I did not ask it to decide what the product should become.

In December 2024, I was the sole developer, using Claude 3.5 Sonnet through Cline with an Anthropic API key. The assignment covered roughly 200 JavaScript files. I set auto-approve to 200, expecting roughly 200 independent per-file conversions; Cline instead ran one accumulating session. The intended mandate was per-file, while context and actions accumulated across files. All of this work belonged to the same front-end migration effort, not to a shared team’s unrelated projects.[1][4]

The agent migrated some code. It also improved adjacent code, added helpers and built subsystems outside the assignment. I described it as wandering into the garden to look at butterflies. More concretely, I still have an entire additional system I never requested—what I referred to at the time as a “PMS” system. It appeared to infer what it should build from what the existing pages resembled. That is my interpretation of the behavior, not direct evidence of its internal reasoning.[4]

I also wrote repeated Markdown rules to stop another recurring deviation: a separate types.ts for each page, without a common type model. The problem was not the filename. It was the invention of competing definitions for shared concepts.[3][4]

January’s input-token volume was 2.02× December’s. The author identifies December with migration and drift, and January with fix-forward recovery. These are monthly workload totals, not a per-action allocation of waste or a dollar-cost comparison.[2][4]

Legitimate work and unsolicited additions had become entangled. The response was to fix forward. The lesson is not that every agent will fail this way, but that a bounded instruction did not remain a dependable boundary on action.

Same message. Different mission.

A chain of individually reasonable edits can produce a conclusion that the original evidence does not support.

The telephone metaphor makes the risk visible. A blunt engineering warning becomes a challenge, then an opportunity, then a confident growth story. No single handoff needs to announce that it is reversing the message. The reversal emerges across the chain.

Read Figure 1 as text

Ungoverned handoffs: ENGINEER — Warns; TEAM LEAD — Softens; MANAGER — Reframes; VP — Encourages; EXECUTIVE — Promotes; BOARD — Endorses. Governed handoffs retain the source warning, label interpretation and leave feasibility unresolved with no launch authorization.

UNGOVERNED HANDOFFS ENGINEER “This is bullshit and will never work.” Warns TEAM LEAD “There are significant challenges.” Softens MANAGER “There are some opportunities to improve.” Reframes VP “We’re seeing encouraging opportunities.” Encourages EXECUTIVE “This initiative shows strong potential.” Promotes BOARD “Promotes growth and helps things flourish.” Endorses GOVERNED HANDOFFS SOURCE RETAINED Engineer warns the approach will not work. An assessment, not established fact. INTERPRETATION LABELED Feasibility concern; independent check required. No conversion of warning into promise. DECISION MADE EXPLICIT Feasibility unresolved. No launch authorization. New evidence can change the decision.

Inspect the wide figure at full size

Preservation is not proof that the source is right

The engineer’s warning is an assessment, not automatically the truth. A faithful system retains it, identifies its author and supporting artifacts, and makes disagreement visible. New evidence may justify changing the conclusion. Repeated paraphrasing does not.

A summary may add context; a planner may propose a remedy. Each must preserve the material constraints, uncertainty and unresolved findings needed for the next decision.

Six stages. Different responsibilities.

Governance fidelity is the degree to which actual behavior preserves the applicable governing intent across its transformations, with evidence sufficient to reconstruct what occurred.[1]

The original chain is H → D → P → S → A → R: human intent, documents, policy, delivered signal, action and reconstruction. Policy remains distinct from the documents that explain it; delivered context remains distinct from everything stored in the corpus.

Read Figure 2 as text

H — INTENT — Tacit limits omitted; D — DOCUMENTS — Exception lost; P — POLICY — Rule mistranslated; S — SIGNAL — Relevant rule absent; A — ACTION — Extra scope executed; R — RECONSTRUCTION — Evidence incomplete.

H INTENT What the authority means Tacit limits omitted D DOCUMENTS What is written and why Exception lost P POLICY What the rules permit or require Rule mistranslated S SIGNAL What reaches the model for this task Relevant rule absent A ACTION What actually happens Extra scope executed R RECONSTRUCTION What the record can establish Evidence incomplete

Inspect the wide figure at full size

Keep four questions separate

Inspect selection too: the right policy can exist but be omitted from context. An agent can also follow a stale policy faithfully and still diverge from current intent.

A correct final action does not prove preservation through every stage. A missing log does not make a correct action wrong; it limits what can be established about it.

A rule in a file is not a boundary.

Externalizing a rule and externally enforcing it are different architectural moves. Both matter.

My July 2025 framework account named the type problem explicitly. It declared “The database is the final authority on types,” flagged unnecessary type files, and required the model to quote relevant standards and justify minimal changes before editing. It also admitted that the practical trigger detector was the human overseer asking why those patterns kept appearing.[3]

That account called for standards to be “enforced at the prompt level.” Read alongside the repeated corrections, it exposes the distinction GFT now makes: the instructions were persistent, but dependable enforcement still required intervention. More Markdown could clarify intent without closing the action boundary.

Presence is not salience

GFT uses governance salience for the practical difference between a rule being present and its bearing on the decision being recognized. The design aim is not to fill the largest possible context window. It is to deliver the applicable rules, their authority and the dependencies needed to interpret them.[1]

Verbatim selection protects the selected words, not the completeness of the selection. Delivering a permission while omitting its exception can mislead without altering a single word. A summary can be auditable when its sources survive, yet still be wrong or insufficient for authorization.

Where applicability is unresolved, surface the conflict or request clarification rather than silently substituting the model’s preferred interpretation. Better delivery helps the model propose a compliant action, but does not grant permission to execute it.

Authority outside the model.

A mandatory constraint cannot depend exclusively on the discretionary compliance of the actor it constrains.

This authority boundary does not require a proof about attention capacity. Even a perfectly understood instruction leaves the question of who may override it. The answer must come from the applicable mandate, not from the model’s confidence.

Read Figure 3 as text

Authoritative sources and mandate feed context selection and the external gate through separate delivery and authorization paths. Context goes to the model proposal inside the model trust domain; the proposal goes to the external gate; only a permitted operation reaches scoped execution. A stop or escalation does not execute. An independently controlled record captures source versions, delivered context, proposal, authorization, execution receipt and observed result. There is no model-to-execution bypass.

MODEL TRUST DOMAIN AUTHORITATIVE SOURCES & MANDATE Owner • principal • scope • policy version Approvals and delegation limits deliver authorize CONTEXT SELECTION Applicable rules, exceptions and sources MODEL PROPOSAL A patch, plan or requested action EXTERNAL GATE Permit • block or require approval SCOPED EXECUTION Allowed operation on a bounded target STOP / ESCALATE INDEPENDENTLY CONTROLLED RECORD Source versions →delivered context →proposal →authorization →execution receipt →observed result

Inspect the wide figure at full size

“Outside” means a real trust boundary

The proposing actor must not be able to rewrite the operative policy, mint broader permissions, bypass the gate or replace the decisive evidence. Those limits must apply to its tools and delegates as well. A second agent, role name or prompt is not automatically an independent authority.

A policy agent may interpret rules; a witness may review. Neither acquires approval power from its label. Authorization follows an authenticated principal and a bounded mandate, evaluated against the requested action and target.

The control plane—the system that holds these rules and permissions—also needs governed changes, reviewable decisions and protected records. Moving a flawed rule outside the model does not make the rule correct.

Model and peer-model reports may inform detection, triage and review. They do not, by themselves, establish independent authorization or verification.[1]

Reduce what can happen.

The less unnecessary discretion a task exposes, the less discretion the model must reliably restrain.

Reduce the degrees of freedom: bound targets, operations and consequences. A migration agent does not need deployment credentials; a reporting agent does not need write access to its sources.

A mandate is more specific than a role

Intent spans industry, organization, division, product, repository and session scopes. Resolve authority and conflicts explicitly; the scopes need not form a perfectly nested tree. A local request cannot override a higher-authority constraint.[1]

Check the invariant, not just its nickname

A filename ban misses the invariant. Page-local presentation types may be legitimate. Shared domain concepts should use the approved common model, not independently invented, competing definitions.

Check allowed paths, operation types, dependency changes and required test results mechanically. Other boundaries need architectural judgment. A successful type check does not establish preservation of a common domain model. When that question remains unresolved, require review rather than inventing certainty.

Put the gate where the consequence occurs

Evaluate the action and target before the controlled effect. Bind approval to the reviewed operation or artifact. Delegating to another executor must not broaden that authorization.

Keep evidence connected.

A trustworthy record distinguishes what was known, inferred, authorized, attempted, completed and observed.

The final report should not depend on the actor’s retrospective story. It should link to the source findings, policy state, authorization decisions, action receipts and observed results. This preserves both the message and the ability to challenge it.

Read Figure 4 as text

SOURCE: Warning and supporting artifacts; Original retained. ASSESSMENT: Feasibility is not established; Inference labeled. DECISION: Hold release; approve a test; Authority recorded. ACTION: Start the approved test; Execution recorded. REPORT: Warning remains open pending result; No invented success. The governed evidence rail connects versioned sources, attribution, policy decisions, receipts and observed results. Every claim links back. Missing or disputed evidence stays visible.

SOURCE Warning and supporting artifacts Original retained ASSESSMENT Feasibility is not established Inference labeled DECISION Hold release; approve a test Authority recorded ACTION Start the approved test Execution recorded REPORT Warning remains open pending result No invented success GOVERNED EVIDENCE RAIL Versioned sources • attribution • policy decisions • receipts • observed results Every claim links back. Missing or disputed evidence stays visible.

Inspect the wide figure at full size

Record enough to reconstruct the decision

Source & version → Mandate & principal → Proposal & decision → Receipt & result

Preserve the source references, delivered context, proposed operation, policy version, approval or refusal, target, execution receipt and verification outcome. Connect them through time and attribution. Keep missing records and unresolved findings explicit.

An explanation is not proof of compliance or privileged access to internal reasoning. A tool’s success receipt is not necessarily a verified business outcome.

Protect the record without pretending it is infallible

Use separately controlled, versioned or tamper-evident records appropriate to the consequence. Corrections should preserve their history; access and retention must be governed. A durable log can still contain a false assertion, so record integrity and evidential quality require separate checks.

Learn without authority drift.

A repeated correction is evidence that the system needs improvement. Repetition does not, by itself, make a new rule binding.

The type-model problem should not restart from zero in every session. Capture the observed deviation, intended behavior, context, source, author and scope. A correction can then improve a task instruction, reveal a missing check or become a candidate change to a shared standard.[1][3]

The authority to change binding policy must come from an authorized transition. It can be automated under a defined mandate; it must not arise merely because many agents repeated a workaround or ignored an inconvenient requirement.

Keep four properties distinct

An old but applicable constraint can still bind. A fresh observation can lack authority. Non-use may raise a review flag; it must not silently revoke an emergency rule. Expiry, supersession and revocation need explicit, authorized semantics.

Version time, not just text

Different knowledge changes differently: some constraints persist until amended; a state snapshot expires; an event invalidates an assumption. Keep the governance state that applied when the action occurred. An audit of March needs March’s rule and mandate, not only September’s replacements.[1]

Earn autonomy within an authorized ceiling

Expand independent execution where relevant evidence supports it; contract it when performance or conditions deteriorate. Successful low-risk edits do not justify production deployment. Match evidence to the action class, scope and environment.

Earned autonomy means fewer approvals within a mandate, not freedom from governance. Its owner retains the ceiling and the conditions for expansion or contraction.

Start with one consequential action.

Choose a real workflow. Trace one action from its governing intent to its observed result. Ask where a claim is being substituted for evidence or authority.

Apply it to the migration

Present a patch that invents duplicate shared types, then one that adds a new business subsystem. Can the controls distinguish both from an authorized conversion? Are ambiguous architectural cases routed for review? Can either patch bypass the decision by changing its filename or using another executor?

These are proposed acceptance tests, not claims that a particular deployed system has passed them.

A framework, not a guarantee.

GFT proposes a way to locate governance failures and design against them. It does not claim that every transformation loses meaning, that all gates are correct, or that fidelity already has a universal score.

Design requirements, observations and hypotheses

The authority model supplies design requirements: a subordinate cannot grant itself an exception; a new executor cannot create a broader mandate; an actor’s self-report is not independent verification. Whether an implementation actually enforces those requirements must be tested.

The migration is a first-person case with provider-recorded usage and later documentation of corrective practices. It illustrates scope drift and the burden of repeated correction. It does not isolate a general causal effect, establish a dollar loss, or independently validate the whole framework.

The earlier paper reports internal context-selection and temporal-memory results. This edition does not treat those benchmark gains as proof of governance fidelity. Operational definitions and reproducible methods must establish what they measure.[1]

Measure the chain without hiding its parts

Candidate measures include traceable coverage of requirements, policy-to-action conformance, detection of unauthorized scope, reconstruction completeness and recurrence after correction. Report them separately, with their test conditions. A single average can hide a critical failure at one boundary.

Their relationship to tacit human intent remains a research question. Correction does not guarantee convergence: feedback can be wrong, policies can conflict, updates can erase exceptions, and intent itself can change.

What GFT is not

GFT is not anti-agent or anti-prompt: instructions, model judgment and human review remain useful. It is more than access control, since permitted access can serve the wrong purpose. External checks are not omniscient; unresolved cases still require accountable judgment.

About the author — James C. Ford has spent thirty years setting platform-wide technical direction for multi-tenant systems that hold regulated data. At ADP (1994–2018) he was Chief Strategic Architect in the Office of the CTO, where he led the adoption of container infrastructure across more than a thousand production containers — work he was interviewed about on stage by Bryan Cantrill at Container Summit. He was Chief Security Architect and Head of Information Security at CrossBorder Solutions, and is currently Chief Architect at a UK FCA-regulated consumer-credit fintech. Governance Fidelity Theory is independent work through his research lab, Equilateral AI (Pareidolia LLC), developed outside any employment relationship. He works as a sole-contributor architect: authority through artifacts, working systems and papers rather than headcount. The framework is the subject of pending U.S. patent applications.

Why I wrote this — I didn't set out to write a theory. I set out to convert two hundred files and watched an agent build a product I hadn't asked for while every instruction I'd written was delivered on every call. Thirty years of building systems that regulators audit taught me what that is: not a smart model misbehaving, but a control that was never outside the thing it was supposed to control. GFT is the write-up of what has to sit between an agent and a consequence. The primer is the accessible version; the working paper is available on request.