Start the audit
Menu

The playbook

Five rules and one gate. Your team keeps both.

This is the whole method, in the open. AI writes the change. Two reviewers who did not write it read the exact bytes. A script refuses the release unless both verdicts landed on the frozen code. A person says go. Everything below is what we set up with a team and hand back.

Get the Release Pack, free Read the gate checklist

The five rules

Short enough to remember. Strict enough to hold.

  1. The tool that builds a change never approves it

    Whatever writes the code does not get a vote on whether it ships.

  2. Two independent reviews on the exact commit

    Two separate reviewers read the same bytes that will deploy, not a summary of them.

  3. AI agents touch sandboxes only

    Nothing automated reaches production. Ever.

  4. A release checklist with a human go

    Deploy order, named tests, and one named person who presses go.

  5. Review findings go back to the team

    Every review lesson is written down and fed into the next sprint, so the same mistake is not made twice.

The release gate

Seven refusals. A script reads the verdicts, not a person.

The rule: Nothing ships unless two reviewers who did not build it pass the exact code, and a person says go.

The release gate's seven refusalsA table with seven rows. For each case the gate script refuses to release. 1. Fewer than two landed verdicts: Refuses. One review is not a review. 2. Both verdicts from the same reviewer: Refuses. Two different reviewers, or nothing. 3. Either verdict is NO-GO: Refuses. Fix, freeze again, review again. 4. A verdict has no tree hash: Refuses. A review that names no bytes reviewed nothing. 5. The hash moved during a review: Refuses. That review is void. 6. The frozen hash is not the tree about to deploy: Refuses. Edit one line after review and this fires. 7. A name, path or secret that must not ship: Refuses. The scrub runs on every changed file.WHENTHE GATE01Fewer than two landed verdictsRefuses. One review is not a review.02Both verdicts from the same reviewerRefuses. Two different reviewers, or nothing.03Either verdict is NO-GORefuses. Fix, freeze again, review again.04A verdict has no tree hashRefuses. A review that names no bytes reviewed nothing.05The hash moved during a reviewRefuses. That review is void.06The frozen hash is not the tree about to deployRefuses. Edit one line after review and this fires.07A name, path or secret that must not shipRefuses. The scrub runs on every changed file.

The one-page checklist

Every release, in this order.

Before review

  1. The build is complete and committed. No further edits are planned.
  2. Freeze the code: hash every file under the deployable folders (sorted by path, one hash per file, then one hash of that list). Record the hash.
  3. Give each reviewer a copy of the frozen tree, not the live working folder.
  4. Pick two reviewers who did not write the code, from different sources. The builder never reviews its own build.

During review

  1. Each reviewer returns one line: name, REVIEW_DONE, a verdict (GO, GO-WITH-CHANGES or NO-GO), and a findings count.
  2. Each reviewer records the hash before and after its review. If the two differ, the review is void.
  3. Check every reviewer finding against the live system before writing a fix. A review checks code against itself; only a person can check it against the real settings, permissions, data shapes and active automations.
  4. A NO-GO from either reviewer means a fix round and a fresh freeze. Never patch and reuse an old verdict.

Before release

  1. A script, not a person, reads the verdicts and refuses unless all of the following hold: exactly two landed reviews from two different reviewers; neither verdict is NO-GO; the freeze line exists and the hash did not move during review; the frozen hash equals the hash of the tree about to deploy, right now.
  2. Run a check-only validation against production, with the test level chosen on purpose, never the default. Nothing deploys.
  3. A person reads the validation result and says go, for this exact release, in writing.
  4. Deploy the validated job. Do not build a fresh package.

After release

  1. Check that the feature is actually live: automations active, switches where you set them. A green deploy is not a live feature.
  2. Record the deploy id, the frozen hash, the two verdicts and who said go, in one tracker row.
  3. Write the lesson the day it is learned, in one file.

What the script does not do

  1. It does not press go. The human go is a rule the team follows, not code the script enforces. Say so when you describe your process.

Release Pack · free

Take the files. They are the same ones we install.

The gate script, the two review skills and the brief and verdict templates, as files your team drops into its own repo and AI tools.

Request the Release Pack by email

Want it installed and run on real changes with your team? The harness setup

  • The release gate script: seven refusals, no exceptions
  • Two reviewer skill files: what to read, what to return, the verdict format
  • The brief template that names files and tests, and the verdict template with the tree hash

In practice

Used on real releases, not written for the website.

A Salesforce team at an enterprise software company went from a 31-slide concept deck to production code in 38 days this way, through the same gate that is on the playbook page.

The checklist above is the generic version of the one that run used, with names removed. The rules did not change between the two.

  • Who wrote it. Tommy Gomolski, Senior Salesforce architect, 15+ years in enterprise platforms.
  • Set up with your team. The audit tells you which rules you are missing; the harness setup installs all of them.

Want it set up with your team?

The audit tells you which of the five rules you are missing, in writing, within 48 hours. The setup installs all of them in ten business days.

Start the auditAsk a question

Prefer to talk first? 20 minutes, free.