← BUILD LOGBUILD RELIABILITY
BUILD LOG · THE GOVERNANCE FILE

My AI brief pipeline failed three ways in one week. So I wrote the file that made sure it never did again.

Most of the briefs shipped as broken stubs, a report index silently collapsed, and almost every link was dead. The fix was not a patch. It was a governance file that turned every past failure into an enforced gate.

Steal this build ↓See the stackThe people part →
7 gates
no score writes to the CRM until all seven pass
6 accounts
the last run mis-scored, caught and corrected before the next one
468 fields
the write guard re-checks every run, so a bad field never fails
0 errors
the plays check must pass on all three jobs before publish
THE STORY, FROM THE SEAT

Here is one I actually shipped. What happened, what I did, and the stack if you want to run it yourself.

When you automate a pipeline, the failures do not announce themselves. Briefs shipped that looked fine but were empty stubs.

A report index quietly collapsed. Links broke and nobody noticed until a human clicked one. Automation without governance does not remove errors, it just makes them silent and fast.

The Sales Operator
Keep Building,
Heath
FOUNDER, THE SALES OPERATOR
THE BUILD IN FIVE MOVES · THE GIANT METHOD
  1. GThe failures did not announce themselves: briefs shipped as empty stubs, a report index collapsed, links broke and nobody noticed.
  2. IIt took Claude Code reading a governance file before every ship, Deepline plays gated on checks, and a Salesforce write-block.
  3. AThe operator writes each failure into a rule; the pipeline enforces every gate before it ships or writes.
  4. NA clear line between draft and send, with human review as a named step in the workflow, became the team standard.
  5. TMis-scored accounts reaching the CRM went from 6 to 0, and the worst week's failures got made impossible.
RUN THE PLAY YOURSELFThis exact build is a playbook. Run it on your own data.
→
01 / HOW WE APPROACHED THE PROBLEM

Ran the loop.

The pipeline failed three ways in one week: broken stubs, a collapsed index, dead links. The fix was not a patch. Every way it broke became a written rule the pipeline reads before it ships anything, enforced gates instead of documentation. The failures did not just get fixed. They got made impossible.

  1. 1
    Turn each failure into a rule

    Every way the pipeline broke became a written rule: a minimum brief size, a link-integrity check, an index-count guard. Not documentation, enforced gates.

  2. 2
    Lock the design

    I put the rules in a governance file the pipeline reads before it ships anything. If a run would violate a past-failure rule, it stops instead of shipping broken output confidently.

  3. 3
    Make the QA part of the run, not a person

    The checks run every time, automatically. The system polices itself against its own history, so a fixed bug stays fixed.

02 / WHAT IT TOOK CROSS-FUNCTIONALLY

Nobody ships this alone. Here is who had to move.

AI governance is a promise the whole company makes, not a sales doc. The file held because the rules were agreed where they get enforced.

LEGAL AND SECURITY
The rules of AI use: what data can touch a model, what needs review, where the line sits.

The governance file wrote down the agreement so every build started inside it, instead of asking forgiveness after.

REVOPS
Where the gates ran.

A rule that lives in a doc is a suggestion. The gates ran in the pipeline and the tooling, so compliance was the default path, not a memory test.

03 / HOW WE TURNED IT INTO A SALES MOTION · THE PEOPLE PART

The file governed the pipeline. A leader still has to govern how the team uses AI.

Guardrails on a system are only half of governance. The other half is the team: what they are allowed to automate, what a human must check, and where the judgment stays. The leadership half was setting that standard and training to it.

THE FRAMEWORK BEHIND IT
The Split as a team standard

Write down what AI may do unattended, what it may draft for a human to approve, and what only a human decides. Then enable the team on the line, so AI is leverage with a seatbelt, not a black box nobody trusts or everybody over-trusts.

  1. 01
    Set the standard for what AI can touch

    A clear line between draft and send, so reps used AI confidently without shipping something wrong to a customer.

  2. 02
    Made human review a named step, not a vibe

    The guardrail lived in the workflow, not in someone's memory of the meeting where we agreed to it.

  3. 03
    Coached the team to read the AI, not obey it

    Reps learned to catch the machine's misses, which is the whole reason to keep them in the seat.

Set the team standard →
04 / WHAT I LEARNED

Not proof. Just what the build taught me.

  1. 01
    Automation makes errors silent and fast

    A pipeline without governance does not remove errors, it just ships them confidently. Briefs that looked fine were empty stubs, and nobody noticed until a human clicked a link.

  2. 02
    Write failures as gates, not documentation

    A minimum brief size, a link-integrity check, an index-count guard: rules the run enforces, not notes in a doc.

  3. 03
    Make the QA part of the run, not a person

    The checks run every time, automatically. The system polices itself against its own history, so a fixed bug stays fixed.

  4. 04
    Guardrails on the system are half of governance

    The other half is the team: what they are allowed to automate, what a human must check, and where the judgment stays.

05 / THE WORKFLOW

The runnable version. Copy it into your stack.

Claude CodeDeeplineSalesforce
[ SALES OPERATOR ]

The Governance File

Heath Barnett · Sales Operator
G / Groundthe problem that started all of it, with the receipt and the cost
Reliability

The failures did not announce themselves.

Briefs shipped that looked fine but were empty stubs. An index collapsed. Links broke and nobody noticed.

Risk

Automation made errors silent and fast.

A pipeline without governance does not remove errors; it just ships them confidently.

A / Assignthe build, block by block, and who owns each one. Open a step to see it run.
HUMAN + AI, IN THE LOOP
The operator writes each failure into a rule; the pipeline enforces every gate before it ships or writes.
Learn from the break
Claude Code01
Turn each failure into a written rule
Details
A minimum brief size, a link-integrity check, an index-count guard. Enforced gates, not documentation.
Human
Lock the design
Claude Code02
Read the governance file before shipping
Details
If a run would violate a past-failure rule, it stops instead of shipping broken output.
AI
Deepline03
Gate every play
Details
The check must pass on all three jobs before anything publishes.
AI
Enforce it every run
Salesforce04
Block the CRM write until gates pass
Details
No score writes to the CRM until all seven gates pass.
AI
The operator05
Sign off when a new failure appears
Details
Each new break becomes the next written rule, so a fixed bug stays fixed.
Human
N / Normalizethe motion that made it stick
A workflow without a motion is dead. This is how it became the way the team works.
1

A standard for what AI can touch

A clear line between draft and send, so reps used AI confidently without shipping something wrong to a customer.

2

Human review as a named step

The guardrail lived in the workflow, not in someone's memory of the meeting where we agreed to it.

3

Read the AI, do not obey it

Reps learned to catch the machine's misses, which is the whole reason to keep them in the seat.

T / Tie backthe result it drove, and how they know
RESULT · 01

6 to 0

mis-scored accounts reaching the CRM.

RESULT · 02

3 failure types encoded

DQ miss, tier mismatch, ghost-active.

RESULT · 03

Out-of-band runs never write

a run outside the accepted band stops.

OUTPUT · 01

The governance file

Past failures as enforced gates.

OUTPUT · 02

Pre-ship checks

A run stops before shipping broken.

OUTPUT · 03

A CRM write-block

No score lands until gates pass.

The Sales Operator
06 / HOW YOU DO IT TOO

Here is what I built. Here is how you build it.

The whole thing installs as one plugin. Or grab the skills a la carte. Everything on this page, runnable, on what you paste today.

✓ EVAL PASS · 4/4
THE PLAYBOOK · ONE INSTALL
Learn GitHub and run your GTM on a repo

5 skills chained into one runnable play. Installs as a single plugin, no copy-pasting each skill. It runs on what you paste; connect your stack to go live.

SEE THE FULL PLAYBOOK →
SEE IT RUN IN CLAUDE
EXAMPLE CHATDana, a RevOps lead, running the loop in one sitting
D
Everyone keeps telling me to put my GTM in a GitHub repo, but I have never used GitHub and honestly it scares me. Where do I even start?
S
Step 1· Github For Gtm
No terminal, no CS degree. A repo is a project folder that keeps its history; GitHub is the cloud that stores it. You commit (save with a note), push (upload), and pull (get the latest). Install GitHub Desktop, sign in, and you never touch a command line. One rule up front: never commit CRM data, API keys, transcripts, or pricing.
Receipt
You get the mental model and a private repo created in GitHub Desktop, with a .gitignore keeping your keys out.
D
Okay, way less scary. How do I set it up so it is not a mess?
S
Step 2· Workspace Organizer
Laid out clear folders (context, skills, outputs), a README that says what lives where, and plain lowercase file names, so a teammate or an agent can follow it without asking you. Nothing moved until you approved the plan.
Receipt
A clean folder structure and a README front door, shown as a plan first.
D
Good. Now how do I make it actually useful for my GTM?
S
Step 3· Context Pack
Wrote a CLAUDE.md at the root with your ICP, positioning, and priorities, so Claude reads it every session and you stop re-explaining your GTM.
Receipt
A CLAUDE.md brain committed to the repo, read automatically every session.
D
How do I keep track of the decisions we make so we stop going in circles?
S
Step 4· Decision Log
Started a decision log in the repo: each entry captures the decision, the options, the why, and when to revisit. The reasoning now lives next to the work.
Receipt
A running decision log in the repo, so nobody re-litigates a call from three months ago.
D
We are done for today. How do I make sure I do not lose any of this?
S
Step 5· Session Closeout
Committed every change with clear messages, pushed to GitHub, and confirmed the repo is green and backed up. Left a note so your next session picks up instantly.
Receipt, repo secured
Everything committed, pushed, and safe. Your GTM now lives in one repo you control. No more 11pm YouTube.
THE SKILLS IT USES
Keep reps making the calls that matter.
keep-the-judgment
Stack the right tools and signals for the workflow.
stack-the-tech
Build the standing brief for an assistant you reuse.
system-prompt-builder
THE OTHER HALF · LEAD THE TEAM
Set the team standard→
I write up one of these a week. Free, receipts only.
RELATED BUILDS
The 7th Analyst
AI-native GTM isn't six analysts. It's the 7th.
Scoring the TAM
The whole TAM, ranked: a tier and a next move per account
THE MARKET ON THIS
AI agent regression testing from production failures (Arthur)AI agent guardrails: pre-LLM and post-LLM best practices (Arthur)