The Governance File: How a Pipeline Stops Repeating Its Worst Week

Forwarded to you? I am Heath. I build go-to-market systems and put AI to work in sales, the right way, then I write down exactly what I built, what broke, and what it moved. One story per week, receipts only. This one is about the week my own pipeline shipped broken output confidently, and the file that made sure it never did it again.

The reflex: patch the broken thing, watch the run go green

Every operator who automates a pipeline reaches for the same move when something breaks. You find the one bad output, you patch it, you rerun, and the run goes green. The checkmark feels like proof. You move on.

I did exactly that. I had automated a brief pipeline, and it ran clean every time. Then briefs started shipping that looked fine but were empty stubs. A report index quietly collapsed. Links broke and nobody noticed until I clicked one myself and landed on nothing. Each time, I found the specific break, fixed that one thing, and reran until it was green again. The green was a lie. The pipeline had no memory of how it had broken, so the same class of failure kept coming back wearing a different face.

The block was never effort. It was that automation without governance does not remove errors. It just makes them silent and fast. A person doing this work by hand catches the empty brief because they read it. The machine ships it confidently, at speed, and the failure lives in production until a human trips over it.

The AE feels this as a forecast that silently double-counts a renewal. The CSM feels it as a health score that quietly goes stale and stops moving. The marketer feels it as an attribution model that drops a channel and nobody notices for a month. Same reflex every time: patch the symptom, trust the green, ship the next silent break.

The reframe: a failure is a gate, not a patch

A broken run is not a bug to squash. It is a rule you did not have yet. The move is not to fix the one stub and move on. It is to take the loud, one-time break and turn it into a quiet check that runs on every future run, so the pipeline polices itself against its own history.

Automation does not remove errors. It makes them silent and fast. A governance file makes them loud again, before they ship.

Same move, other seats. An AE whose forecast once double-counted a deal writes that into a check that runs every close: no opportunity lands in two categories. A CSM whose health score went stale writes a freshness gate: a score older than its window never displays. A marketer whose attribution dropped a channel writes a count guard: a model that returns fewer channels than last week stops and asks. The one-time break is never the thing you fix. The rule underneath it is.

How the best teams frame it

I am not the first person to argue that silent failures are the real risk in an automated pipeline. The operators and analysts who have run this at scale mostly agree on where the leverage is, and it is not more vigilance. It is turning failure history into enforced checks.

SOURCE

Ben Rogojan (Seattle Data Guy), "The 5 Silent Failures in Data Pipelines" (Apr 2026)

What it argues. Pipelines fail without throwing a single error. Schema drift, partial loads that look complete, stale data that keeps serving, logic that was fine until the business changed. The scary part is not the failure that pages you at 2 A.M. It is the one that runs green for months until a CFO asks a question.

My take. Agree, and this is the exact trap I fell into. His fix is a data-quality check at each layer, not more eyes on a dashboard. That is the whole point. Vigilance does not scale. A check that runs every time does.

SOURCE

Arthur, "Regression Test Datasets for AI Agents from Production Failures"

What it argues. The best regression tests are not invented. They are harvested from real production failures. Every time an agent breaks in the wild, that break becomes a permanent test case, so the system is measured against its own worst history and a fixed bug cannot quietly return.

My take. Agree hard. This is the governance file described from the QA side. My rules are not a wish list of good behavior. Each one is a scar. A DQ miss, a tier mismatch, a ghost-active account, each earned its gate by breaking first.

SOURCE

Arthur, "Best Practices for Building Agents: Guardrails"

What it argues. Reliable agents need guardrails on both sides of the model: pre checks that validate the input before work starts, and post checks that validate the output before it is allowed to ship or act. The guardrail is not advice to the model. It is a gate the run cannot pass without clearing.

My take. Extend. The word that matters is enforced. A rule the pipeline can skip is documentation. A gate that blocks the write is governance. My CRM write is the post check: no score lands until all seven gates clear.

Even a curator has to concede when the field agrees: nobody who has run an automated pipeline thinks more watching is the answer. The failure history, written down as gates, is the moat.

The method: Solve, Stack, Split

SOLVE THE CRUX

What is the real problem, framed as work and not a headcount?

The problem is not "we need a QA person on every run." It is "the pipeline has no memory of how it broke." So the first work is translation: take each real failure and write it as an enforced rule. A minimum brief size so a stub cannot pass as a brief. A link-integrity check so a dead link stops the run. An index-count guard so a collapsed index is caught before it ships. For the AE that rule is a forecast that cannot double-count, for the CSM a score that cannot go stale, for the marketer a model that cannot drop a channel in silence.

STACK THE CONTEXT

What tech turns a written rule into a gate the run cannot skip?

Not a shopping trip. Claude Code holds the pipeline and the governance file it reads before it ships anything, so a run that would violate a past-failure rule stops instead of shipping broken output. Deepline runs the plays whose check must pass on all three jobs before anything publishes. Salesforce is the last gate: no score writes to the CRM until all seven gates pass. The file is the memory. The tools enforce it.

SPLIT · CUT THE DRAG

What low-judgment work goes to the system?

Running the gates. Every rule, every run, every time. Minimum brief size, link integrity, index count, the distribution band, the ten accounts hand-recomputed to match the scorer within a point. This is the part that never scaled when a person did it by hand, and the part the system does perfectly because it is mechanical. It does not get tired and it does not trust a green checkmark.

SPLIT · KEEP THE JUDGMENT

What stays human?

Writing the rule. When a new failure appears, a person has to decide what the break actually means and encode it as the next gate. The system enforces history. It cannot author it. One owner reads each new break, writes it into the file, and signs off, so the pipeline gets stricter every time it fails instead of forgetting.

The workflow: the board that runs it

Solve, Stack, Split is the shape. Here is the actual board, lane by lane: what the agents enforce, what stays human, and the tool at each step. Once the file is written, the checks run on every publish without anyone kicking them off.

What it moved

At a company I was at, a growth-stage SaaS running an automated account-scoring pipeline, this is the exact build I ran. Take every way the pipeline had broken, write each one into a governance file, and make the pipeline read that file before it ships or writes anything.

The pipeline did not get smarter. It got a memory. Ten accounts are hand-recomputed every run and have to match the scorer within a point, and a run whose distribution falls outside the band stops before it can write. The six accounts that used to slip through with a wrong tier went to zero, not because anyone watched harder, but because the checks that would have caught them now run every single time.

My receipts here are on a scoring pipeline. Drop your own workflow in. A CSM points the same build at a health model: the failure that once let a stale score display becomes a freshness gate on every run. A marketer points it at attribution: the run that once dropped a channel becomes a count guard that stops before the report ships.

WHAT I LEARNED

1. A green run is not a working run. The pipeline that throws no error is the one most likely to be shipping something broken.

2. A patch fixes one output. A gate fixes the whole class, and keeps it fixed on every run after.

3. Rules only work if they are enforced, not documented. A check the run can skip is a wish. A gate that blocks the write is governance.

4. The system enforces failure history. It cannot author it. A human still has to read each new break and write the next rule.

Run this one this week

Do not build the whole file. Pick the single worst way your automated pipeline broke, the one that shipped something wrong and nobody caught for a while. Write it as one check with a clear pass or fail: minimum size, a link that resolves, a count that matches last week. Wire it so a failing check stops the run instead of logging a warning nobody reads. Then break it on purpose once to prove it actually blocks. That one gate is the governance file in miniature, and it tells you whether the full build is worth it before you spend a week on it.

Two builds that sit next to this one:

• The 7th Analyst · "AI-native is not how many agents you have. It is whether one of them watches the others and turns their mistakes into improvements. Build the analyst that reads the audit trail. That is the one that compounds." The governance file is that audit trail, turned into gates.
• The Win/Loss Backtest · "Before you trust a scoring model, backtest it against the deals you actually won and lost. Measure lift per signal." Same instinct, aimed at the model before it ships instead of the pipeline that ships it.

This is one build from the Build Log. Every week I take one sales or revenue problem, run it through the loop, and show the receipts. If someone forwarded this, the subscribe button is right below. Keep building. Heath.