Tribal knowledge becomes governed Procedures

Every sales and finance organization runs on two sets of rules. The first set is written down — the discount matrix, the credit policy PDF. The second set is the one that actually decides things, and it lives in the heads of the people who have been there longest: the senior rep who knows you never quote that customer above net-30, the controller who knows which counterparties always need a second signature, the ops lead who knows a "new customer" means something different when the order is large.

The second set is the problem. It is unwritten, so it is applied unevenly. It walks out the door on retirement. It takes two years to transfer to a new hire, and until then the new hire's quotes are slower and worse. And when an auditor asks why a decision was made, the honest answer is "ask Marta" — which is not an answer.

A Procedure is how one of those rules stops being tribal. It is the same sentence the senior person would say out loud, turned into a control that runs the same way at 2 a.m. as at 2 p.m. — uploaded in plain English, compiled into deterministic gates and tests, tested against history, approved by an authorized owner, and versioned.

One rule's path from a sentence to a running control — every version signed by a named owner.

uploaded → compiled → tested → approved → versioned

Uploaded: the rule stays a sentence

The owner uploads the rule in plain English, because the owner is the person accountable for it and English is what they think in:

Any quote above $50k to a customer less than a year old needs a D&B credit pull, sign-off from the sales director, and never goes below a 22% margin.

That sentence is the Procedure. Not a flowchart of it, not a Jira ticket describing it — the sentence itself is the source, versioned like code, with a named owner.

Compiled: English becomes deterministic gates

The compile step turns the sentence into explicit, typed controls — not a prompt hoping for the best. The sentence above compiles to three gates on the quote path:

Trigger. Quote value > $50,000 AND customer tenure < 12 months. Both are typed fields from the ERP, so the trigger is a comparison, not an interpretation.
Evidence. Pull the D&B credit data — score, delinquency flags, recommended limit — and attach it to the decision card. If the pull fails, the gate pauses; it does not silently skip the check.
Control. Route to the sales director for approval, and enforce the 22% margin floor as a hard constraint — a quote below it cannot be released, only escalated.

Notice what this is not: it is not asking a model to remember the rule each time. The model extracts and drafts; the gates are deterministic. Same inputs, same outcome, every time.

Tested: its own exam — and then against history

The same compile step produces tests, because a control you cannot test is a hope. The tests are concrete cases with expected outcomes:

A $51,000 quote to an 8-month-old customer at 19% margin must be blocked, and the block must name the margin floor as the reason.
A $49,000 quote to the same customer at 19% margin must not hit the credit or approval gates at all — boundaries matter.
A $60,000 quote where the D&B pull times out must pause, never auto-approve and never auto-release.

These run on every change, the way unit tests run on code. A proposed edit that would have let the $51k quote through does not ship.

Tests cover the cases someone imagined. The second half of testing covers the ones that actually happened: the compiled Procedure is tested against the last months of real traffic — every historical quote re-evaluated against the new gates.

The output is a record of would-have-beens: these 37 historical quotes would have been gated, these three would have been blocked on margin, this customer accounts for a third of the triggers. That is where the tuning happens. Maybe $50k is right; maybe the history shows the real risk line is $40k, or that tenure matters more than size. The owner adjusts the sentence, recompiles, and tests again — all before the Procedure touches a live decision.

Approved: a named owner signs

Approval is an act, not a deploy. The authorized owner — the sales director in this example — reviews the historical test results and signs. From that moment the rule runs at machine tempo, and every firing lands in the ledger — a record of every decision: what changed, who approved it, when — with the trigger and the evidence attached. "Ask Marta" becomes a lookup.

Versioned: the sentence is source

Every approval produces a version — the sentence, its compiled gates, its test results, and the owner's signature, kept the way code is kept. When the rule changes, the old version does not vanish: any past decision can be traced to the exact version that made it, and a bad change rolls back in one step.

What changes on Tuesday

The new rep quotes a $50k deal on their third day and gets the senior rep's judgment applied automatically — the credit pull appears, the director approves from their phone, the margin floor holds. The senior rep reviews exceptions instead of every quote. And when the risk appetite changes, the owner edits one English sentence, tests it against history, and signs a new version — the change takes effect with evidence, not with a meeting and a memory.

Tribal knowledge is not worthless; it is usually the best operational thinking the company has. It is just stored in the least reliable medium available. The job of a Procedure is not to replace that judgment — it is to give it a form that is testable, replayable, and still running when its author is on vacation.