Document the decisions, not just the steps.

A step is an instruction. "Open the project file. Verify subcontractor coverage. Log the result."

A decision is a judgement. "If the project includes Trade X and the historical subcontractor coverage in this region is under three options, flag to senior estimator before committing to the timeline. The pattern we're trying to catch is single-source dependency, which we've been burned by in three of the last five projects where it occurred."

Steps are easy to document. They're also the part of the work that everyone can already see. A junior operator who watches the process happen twice can usually reconstruct the steps. The decisions are the part they can't see. They happen inside the senior person's head, in the moment, often without the senior person being able to explain afterward exactly what triggered them.

When the Playbook documents only steps, three things follow.

1. Inconsistency.

Two operators with the same job title, same procedures, same training, produce different outcomes on similar work. Not because they're not following the documented steps. Because the documented steps only get them to the decision points, and at each decision point they're using their own judgement, formed differently. The procedure handles the cases everyone agrees on. The decisions handle the cases that vary, which is where the work actually differentiates.

2. Knowledge that walks out.

When the senior estimator who's been with you fourteen years moves on, the procedures stay. The decisions leave. The replacement reads the Playbook, follows the steps, hits the first novel situation, has nothing to draw on, and routes the decision back to whichever member of leadership is nearest. The senior person's contribution wasn't in following the steps, every estimator does that. Their contribution was in the pattern recognition that lived in the gap between steps. When the decisions aren't documented, that gap reopens.

3. Junior staff can't grow.

Procedure-only documentation produces what one of our clients called "advanced novices." People who execute the documented work well but can't reason their way into the work the documentation didn't anticipate. The leap from junior to senior is largely the accumulation of decision patterns. Without an explicit decision layer, the only way to make the leap is years of apprenticeship under someone willing to talk through their reasoning aloud. Most teams don't have that bandwidth, and most senior operators don't naturally explain.

4. Reasoning rots.

Rules without their reasoning don't age well. Two years after the rule is written, somebody asks why we still apply the tier-A markup pattern to certain customer types. Nobody can remember. The rule continues anyway, half from habit and half from caution. Often it's still right. Sometimes it isn't, and nobody can tell. With the reasoning attached, the rule becomes auditable: when the situation that produced the rule no longer applies, the rule is retired explicitly. Without reasoning, it lingers.

Different from an SOP. Sits next to one, embedded into the procedure at the moment the decision shows up. Here's the structure that works:

Six fields. Two pages at most. Lives next to the procedure that contains the decision point, surfaced inline when the procedure is being used.

What this format gives you that a procedural step doesn't: a new estimator who hits a $245K project with a 25-day timeline now reads the reasoning, recognises the pattern from the description, and escalates without needing the literal numbers to match. The decision generalises because the rule is grounded in the pattern, not the threshold.

Decisions are harder to document than steps because the people who make them best often can't articulate why. The pattern recognition is tacit. "I just know" is the most honest answer most senior operators can give you on the spot.

The methodology for extracting it is structured questioning anchored to real recent work, not abstract reflection. We covered this in detail in AI-Structured Interviews, but the short version:

• Walk through real recent jobs, not hypothetical ones. The senior operator's memory is concrete. The patterns are easier to spot when anchored to specific work.
• At each decision point, ask the obvious question: what made you decide that. The first answer is usually a reason. The second answer, after gentle pushback, is usually the actual pattern.
• Ask the counterfactual. "What would have to be different about this job for you to have made the opposite call?" The answer surfaces the boundary conditions of the pattern.
• Compare across operators. Two senior people facing the same kind of decision often have slightly different patterns. The comparison surfaces which version actually holds up under scrutiny.

What used to be a multi-week interview exercise is now an afternoon with AI-assisted structuring. The bottleneck is no longer extraction. It's getting the senior operator's calendar for the session.

Not in a separate "decisions" folder.

Decision documents live inside the procedures they govern, surfaced at the moment the decision point appears in the procedure. Whichever tool you use (Trainual, Whale, an AI-native hub, see our comparison piece), the goal is the same. The procedure says "at this step, check whether you need to escalate." The decision document opens with one click, or is rendered inline, depending on the tool.

This matters more than people expect. A decision document in a separate folder is documentation that requires the operator to go find it. A decision document next to the procedural step is documentation that arrives when needed. Same content. Radically different adoption.

Decisions drift faster than steps. A procedural step ("open the project file") rarely changes. A decision rule ("escalate over $250K with a 30-day timeline") changes when market conditions shift, when the company's risk appetite changes, when a new pattern emerges that the rule didn't anticipate.

The drift-detection rhythm we use for procedures works for decisions too, but with a different cadence and a different sensor.

For procedures, AI-assisted comparison between documented steps and audit trails in the project management tool catches drift continuously. For decisions, the more useful signal is outcome comparison: when a procedure has been followed correctly and the outcome still misses the mark, the decision rule embedded in the procedure is the most likely culprit. Quarterly Playbook reviews specifically look for decisions that have outlived their patterns, and decisions that the team has been quietly overriding because the rule no longer matches reality.

The reviews stay short, under an hour, when the owners are named and the decisions are documented in the format above. When ownership is fuzzy and the reasoning is missing, the same review takes a full day and produces little.

A business with a decision-layered Playbook is structurally different from a business with a procedure-only one, in ways that show up over time.

Onboarding new senior hires takes a fraction of the time, because the patterns they need to learn are written down, not absorbed through years of apprenticeship. Internal promotions become possible from positions where they weren't before. The "irreplaceable" senior operator becomes a contributor whose contribution is in the building, not in their head. Drift becomes visible. Mistakes become teachable. The Playbook becomes the institutional memory of the business, not a polite document.

This is the asset class we call Codified Operational Intelligence™. The procedures are the surface. The decision layer underneath is what makes it intelligence, not just documentation.

Most Playbooks stop at the procedures. The ones that change the business don't.