Governance Isn’t a Step in Your AI Pipeline
The Governed Context Pipeline — three phases, one wrapper, and the verification economics that decide what’s worth automating at all.
The most dangerous box on an AI workflow checklist is the one labeled “governance.” Not because it’s wrong — because of where it sits.
Nate B Jones recently published a nine-step framework for agent workflows, running from context pack through human approval (gate). It’s good. The individual practices are the right ones: normalize your data, ground the model in retrieval, cite every claim, keep a human in the loop. If you’re building agents, watch it.
But the framework is linear — nine sequential steps. And somewhere in any linear list, governance becomes a step. Something the pipeline passes through once, checks off, and moves past.
That shape is the problem. Not for a startup shipping a demo. For anyone operating where the output has consequences — a law firm, a bank, a hospital, anywhere regulated — the shape is exactly backwards.
This piece lays out the restructure in full: three phases wrapped in a governance layer, the failure mode each phase exists to prevent, and the operational finding that changed how we decide what to automate in the first place.
A checklist implies an order of operations
Consider what actually has to be true for an agent workflow to survive review in a regulated environment.
Every action needs to be attributable to a human principal. Access control needs to hold when data is ingested, when it’s stored, when it’s retrieved, and when the output ships. The audit log needs to capture all of it. Data residency constraints don’t pause while the pipeline does its work.
None of those are steps. They’re properties — conditions that must hold at every step. A checklist that positions governance as step nine implies the other eight ran without it. The first serious review will ask what was happening during steps one through eight, and “governance came later” is not an answer that ends well.
Running AI inside a national law firm forces this distinction quickly. Matter-level confidentiality, client data residency, professional accountability for anything that enters the record — these constraints don’t arrive at the end of a pipeline. They’re the environment the pipeline runs in. A workflow that treats them as a checkpoint has already failed; it just hasn’t been asked the right question yet.
So the restructure: three phases, wrapped in a governance layer. The Governed Context Pipeline. Each phase answers one question, and each exists to prevent one specific failure.
Scope: what is the agent allowed to know?
The first phase happens before any data moves, which is why almost nobody does it first.
Teams start at ingestion. Connect the mailbox, pull the PDFs, chunk, embed. The energy goes into the plumbing, because plumbing feels like progress — there’s something to demo at the end of the sprint. But the expensive mistakes in agent projects happen before the first document is ingested, in the decisions nobody wrote down about what the agent may read and toward what goal.
Nate's skeleton, to its credit, starts exactly here — his first step is a context pack that defines what the agent is allowed to read. Scope is that instinct given an enforcement mechanism.
Scope is the permission boundary, defined explicitly. What sources can this agent touch? For what purpose? On whose authority? In a law firm, the answers are concrete: role-based access against the firm’s identity provider, matter-level permissions that mirror ethical walls, residency rules about which jurisdictions data can occupy. The critical design decision is where those answers live. Not in a policy memo — in the architecture. A memo describes intent. An access control list enforces it.
One rule does most of the work: the agent’s access is a strict subset of the authenticated human’s access. Never more. An agent acting for a lawyer who cannot see a matter cannot see that matter either — not because it was told not to look, but because the credential it operates under makes looking impossible.
The failure this phase prevents is the one that ends AI programs in regulated industries: the “helpful” agent that read the wrong client’s file. Once that happens, no downstream safeguard matters. You can verify the output perfectly and the breach has still occurred, because the document was never supposed to be in context at all. Scope failures are unrecoverable by design — which is why scope is phase one and not a hardening task for later.
Structure: turn the mess into addressable context
The second phase is the unglamorous middle, and it’s where most of the actual engineering lives.
Source material arrives through controlled connections — not ad-hoc exports, not someone’s downloads folder. Large documents get chunked into tagged, addressable pieces, so a five-hundred-page record becomes something a retrieval system can point into with precision. Normalization turns unstructured mess into a clean schema: dates become dates, amounts become amounts — Nate's phrase, and exactly the right one — parties become parties. Storage stays secure and localized, holding whatever residency promise was made in scope. And retrieval works by similarity against that normalized store, pulling exact language with file references attached.
That last property deserves a sentence of its own, because it’s the entire epistemology of the pipeline: the agent works from retrieved fact, not remembered vibes. A model answering from its training data is recalling an impression of the world. A model answering from retrieval is reading a specific paragraph of a specific document it can name. Everything defensible about the output rests on that difference.
Two operational realities about this phase, both learned the slow way.
First, normalization quality is gated by input quality. The hardest inputs aren’t exotic — they’re handwritten documents, OCR’d scans, and sources whose formatting drifts from one custodian to the next. No amount of clever prompting upstream fixes a date field that arrived as a smudge. That makes normalization permanent iteration work, not a solved step, and any plan that treats it as a one-time migration is a plan for disappointment.
Second, normalization is deliberately isolated as its own step so it can be improved without touching anything else. Ingestion doesn’t change. Retrieval doesn’t change. The normalizer gets better every month on its own schedule. That’s not pipeline trivia — it’s the design decision that lets the boring part compound.
The failure this phase prevents: plausible-sounding output grounded in nothing. Skip the structure work and the agent still answers — that’s the trap. It answers fluently, confidently, and from nowhere.
Sign-off: defensible, not just plausible
The third phase is where the output earns the right to be relied on. Four operations: cite, verify, export, gate.
Cite means every generated claim maps to a specific paragraph in a specific source document. Not “according to the file” — this claim, that paragraph. The receipt. Citation is what converts an assertion into something checkable, and its real function is economic, which matters enormously later in this piece.
Export means the output ships as a structured review packet — a timeline, a list of identified gaps, a draft summary — rather than a wall of chat text. The reviewer gets an artifact organized for review, not a transcript to spelunk.
Gate means the hard stop. The AI cannot send, submit, file, or finalize. Ever. An authenticated professional reviews the citations and approves, and the approval is what moves the work forward. The gate is architecture, not policy — the capability to act simply doesn’t exist in the agent’s permission set.
The failure this phase prevents: an AI output entering the record with no human fingerprints on it. In a profession where a person is accountable for everything that goes out the door, that failure isn’t an embarrassment. It’s a structural breach of how the profession works.
But there’s a subtlety inside sign-off that most pipelines miss, and it’s the difference between having receipts and having proof.
Four ways a citation fails
A citation is an assertion, not proof. Audit the receipts in a real pipeline and they fail in four distinct ways:
Hallucinated — the source doesn’t exist. Rare in a grounded pipeline, but it’s the failure everyone knows about, because it’s the one that makes headlines and sanctions orders.
Semantically wrong — the source is real, but it doesn’t mean what the model thinks it means. The claim and the paragraph are both genuine; the relationship between them is not.
Missing — a claim that should carry a citation doesn’t, and slides through as connective tissue.
Duplicated — one source quietly does double duty across several claims it only partially supports.
The second failure is the dangerous one, because it survives a spot-check. The document exists. The link resolves. The reviewer clicks through, sees a real paragraph in a real filing, nods, and moves on. Every superficial signal of groundedness is present, and the meaning is wrong. Hallucination checks — “does this source exist?” — catch the first failure and are completely blind to the second.
Which is why verification is its own operation with its own tooling, not a byproduct of citation. Checking that a receipt exists is string matching. Checking that the receipt supports the claim it’s attached to is an entailment judgment — and it has to be performed against every claim, not a sample you hope generalizes. Hand that judgment to humans and you’ve rebuilt the verification labor the pipeline was supposed to reduce. Hand it to a second model and you’ve created a new set of judgments that themselves need calibrating. That recursion is why this is the live edge of the work right now. Nothing about it is finished, and it’s harder than any layer of the stack that gets talked about more.
The wrapper is the argument
Around all three phases sits the governance layer — and here is where the restructure stops being a diagram preference and starts being the point.
Four properties, held everywhere: identity, so every action is attributable to a human principal; access control, enforced at every phase rather than checked once at the door; audit logging, immutable, capturing prompts, actions, and approvals — which means compliance reporting comes free instead of being a quarterly archaeology project; and residency, holding through every phase including retrieval, because a vector store in the wrong jurisdiction is a residency violation no matter how well-scoped the ingestion was.
The difference between a step and a property sounds like semantics until you watch it decide an architecture. Treat governance as a step and you get a pipeline with a compliance checkpoint — one gate, at one position, inspecting whatever reaches it, trusting that nothing leaked before inspection. Treat governance as a wrapper and the questions change shape entirely. Not “did the output pass review?” but “was there any moment when this agent could act outside its principal’s identity?” Not “is there an audit trail?” but “is there any action that could have escaped it?”
And every one of these properties maps to something you can point at in a real enterprise environment. Residency is the cloud tenancy itself — region-pinned storage and compute that physically cannot host data elsewhere. Identity and access control bind to the same enterprise identity provider the humans authenticate against, so the agent inherits the org’s permission model instead of maintaining a parallel one. The connectors that bridge into document management systems carry those permissions through rather than flattening them. If a team presenting an agent architecture can’t point to where each property is enforced, the property isn’t held — it’s hoped for.
The wrapper turns governance from an inspection into an invariant. None of it is a policy document. All of it is architecture. That’s the part linear framings underplay, and it’s the part that determines whether the system survives contact with a regulator, an opposing counsel, or your own risk committee.
Governance isn’t step ten. It’s the box the other nine steps live inside.
The economics of the gate
Everything so far describes how to build the pipeline correctly. This section is about when not to build it at all — and it comes from the finding that reshaped our automation decisions more than any technical result.
The gate is not free. Put an AI workflow in production with a human verification gate at the end, and in some workflows the verification consumes as much time as the manual process it replaced. The automation produced its output in seconds; the checking of that output ate the savings. Net time recovered: approximately nothing.
The accounting is actually worse than break-even, because of who does the verifying and what they know. A person doing the work manually verifies as they go. Checking is amortized across authorship — every choice is checked at the moment it’s made, by the person holding the reasoning behind it. The verifier at a gate reads cold. They weren’t present during creation, they don’t hold the reasoning, and they’re reconstructing intent from the artifact alone. The pipeline didn’t eliminate the verification labor. It relocated it — and handed it to someone in a structurally worse position to perform it.
Peter Naur described the underlying mechanism in 1985, in “Programming as Theory Building”: the real substance of built work is the theory in the builder’s head, and the artifact doesn’t carry the theory. Programmers are rediscovering this at scale right now, reviewing AI-generated code they didn’t write and can’t cheaply validate. It generalizes to all knowledge work. The gate asks a human to recover a theory from an artifact, which is the expensive direction.
Out of that comes the selection criterion — the most useful sentence this pipeline has produced:
Automate where verification is asymmetric. Where checking is structurally cheaper than producing: confirming a citation points where it claims, validating an extracted date against the source, checking a sum. In those tasks the gate is fast, the machine does the production, and the economics genuinely work.
Where verification is symmetric — where “is this right?” can only be answered by re-deriving the judgment — the pipeline saves nothing. “Does this summary capture what matters across these files?” has no shortcut; answering it honestly means reading the files, which is the work the summary was meant to replace. The honest architecture in those cases moves the human upstream, into the creation loop, steering while the work is made, rather than stationing them at the gate to reconstruct it afterward.
Notice what this does to the phases you’ve already read about. Cite and Export aren’t decoration — they exist precisely to convert symmetric verification into asymmetric verification. A claim with a paragraph-level receipt can be checked without re-deriving it. A structured packet with a stated timeline and gap list can be reviewed without reconstructing it. When that conversion succeeds, automation pays. When it fails — when the receipts still can’t make checking cheap — the task was a bad automation candidate, and no amount of pipeline sophistication rescues it.
Where it breaks
A framework that claims no limits is marketing, so here are this one’s, stated plainly.
Normalization never finishes. Input quality gates everything downstream, the worst inputs are the ones humans produce most casually, and the phase is permanent iteration work dressed as a pipeline step. Budget for it accordingly — in attention, not just money.
Semantic verification is unsolved. The four-failure taxonomy tells you what to look for; it doesn’t hand you a tool that finds failure mode two at scale. The honest status is: active work, real tooling, no finish line in sight.
And the framework governs context pipelines — agents that read, ground, and draft. It says nothing about model selection, nothing about fine-tuning, nothing about the dozen other decisions an AI program has to make. It’s a load-bearing wall, not a whole house.
What it does do is give a leadership team a shape to reason with. When the next agent proposal lands, the questions write themselves. What’s the scope, and where is it enforced? What does the structure work cost, and who maintains it? Is verification asymmetric, or are we about to relocate labor and call it savings? Can any action escape the wrapper?
The checklist wants you to ask “what’s the next step?” The better question is “what has to be true at every step?”
Draw the box first. Then build what runs inside it.
On LinkedIn this week I’m walking through one phase of this framework each day — compressed versions of the arguments above. This article is the destination they point back to; there’s nothing else to keep up with. If someone forwarded you this, you can subscribe at andrewlewis.ca.