One page explains what I deliver. The other explains how I do it. This is the how.
I publish it in full for two reasons.
One: the method has an author. If this becomes common practice, I'd rather be copied by people who know where it came from.
Two: what I sell is not the information. It's the execution. You can read this entire method, understand it, and still be unable to apply it in your company. Why you can't, I explain at the end. The distance between reading and executing is where I live.
If your business has two or three people whose judgment works with them in the room and flattens without them, this text explains exactly how it is made visible, encoded, and verified.
This page has two readers. You, who run the company. And your expert, the person whose judgment is going to be encoded. Forward it to them. Their judgment is not encoded behind their back: they define the correct decision, retain authorship, and approve the engine's boundaries.
Read it whole. Then decide whether you try it yourselves or you write me.
If your key people's judgment still only works when they're in the room, it's not because you haven't tried to solve it.
The manual is written for the normal case. But your expert's value isn't in the normal case. It's in what they decide when the normal case doesn't apply. That doesn't fit in a manual, because to write it down they'd first have to know they do it. And they don't.
Videos and sessions teach the technique, not the judgment. The employee advances while the cases fit what they learned. The day something doesn't fit, they sit there staring at the screen. And the veteran isn't inside the video to tell them what to do.
Shadowing works while they're together, which is exactly the problem you were trying to solve. Osmosis transfers habits and vocabulary, not conditional decisions. And it reproduces the bottleneck: one apprentice at a time, years per head.
When someone asks them "what do you decide when a case goes off script?", their answer is a textbook version. It's what they think they do, not what they do. What they do depends on things they aren't consciously processing, and an interview captures none of them.
It sounds like your company but doesn't decide like your expert. It's an imitation of the corporate voice, not a replica of the judgment. Nothing else could have come out: the documents it was trained on already had the problem of the four points above.
Imagine rush orders come into your company, and there's one person who always gets it right when deciding which ones to take.
When you document, you write like this "When evaluating a rush order, it's important to analyze available capacity, margin, and the impact on existing commitments."
When you encode, you write like this "If the client asks for a rush deadline but takes more than two days to send the technical information, the urgency is negotiation, not need: accept the order on the standard deadline. Exception: if it's one of the three clients who concentrate your revenue and the request comes from their plant, not from purchasing, the urgency is real even if the paperwork is late. There, you rework the schedule and absorb the cost."
The first version is information. Anyone reads it and nods. Nobody knows what to do with it tomorrow.
The second version is a decision. It has an input (what happens), an output (what you do), and an exception (when the normal rule doesn't apply). It's what I call at Encode a Rule with its Exception Matrix.
Your expert's work, when it works, is made of decisions of the second kind. Hundreds of them. Most of them they make without realizing they're making them. That's why they can't document them: to document them, they'd first have to realize they exist.
Your manuals are documented. Your file has to be encoded.
If I ask your operations director "what do you do when an order gets complicated?", they'll give me a textbook answer. They'll talk about evaluating capacity, communicating with the client, prioritizing.
If instead I put this on the table:
Their brain shifts into a different mode. It can't reach for the textbook answer because the textbook answer doesn't solve the specific situation. They're forced to apply their real judgment.
And while they apply it, I listen.
What I listen for is not what they say. It's the decisions they make without explaining why.
Not "a complicated order," but this client, this deadline, this new purchasing director, the committee this afternoon. The details force real answers.
The committee is this afternoon. The decision can't be postponed. Time pressure activates judgment. Without urgency, everyone speaks in the abstract.
The normal rule in operations is to protect the schedule. But if you always protect it, you lose the client who sustains your revenue. The scenario forces a decision about when the normal rule doesn't apply. That moment is where tacit judgment shows up.
Any scenario that meets the three conditions does the same job. In your Diagnosis I build five to eight of them, calibrated to your industry and to your company's actual operation. Some I prepare during the preliminary immersion, from your documentation and your real cases. Others I improvise in the session, from what I discover while your expert talks.
My job is to listen for the decisions they make without explaining why, and write them down as they apply them.
They get stored in what I call the Exception Matrix. Each rule in the system has three fields: the decision made in the standard case, the specific conditions that break that decision, and the alternative decision that applies when the normal rule doesn't work.
Two examples. The first comes from my own sales system; the second, from the operations scenario above.
When a deal stalls, the normal decision is to build a reactivation message around a new insight, never "follow up": something that has changed in their business, a data point that contradicts what they believe.
But before writing that message, the rule requires re-scoring the deal's evidence. If qualification falls below the threshold and there's no concrete plan to close the gaps, the reactivation message only prolongs the agony.
In that case, the decision changes: the deal gets deprioritized, you accept the no the client isn't verbalizing, and the time is freed up for living deals.
When a client asks to move up a delivery, the normal decision is to evaluate capacity and accept only if it doesn't break commitments to other clients.
But if the person asking is a purchasing director new to the role, the request isn't logistics. It's a power play. Treating it as logistics turns it into a precedent.
In that case, the decision changes: the answer comes from the sales director, not from planning, and any concession comes with a visible counterpart.
Every encoded judgment has between 8 and 30 rules like these. My first engine had 11; today the system is on version 4.2, with five methods and eleven connected protocols. Encode deliverables work in that range.
The piece that separates a mediocre system from a useful one is the middle condition: the one that says when the normal rule doesn't apply. If you encode only the rules, you capture the easy part of your expert's work. The exceptions contain the differentiating judgment. The Exception Matrix is the difference between a file that decides like your expert and a file that decides like anyone.
You take a case your expert already solved in the past. You give it to the system without telling it how it was solved. You compare. If the system makes the same decision they made, that case passes. If it makes a different one, it's one of two things: either the system is miscalibrated, or the original solution was suboptimal. Both are useful.
You take a case your company has on the table this week, still unsolved. You give it to the system. You write down its recommendation. Your expert makes their own decision separately, without looking at what the system said. You compare. If they match, the system works on unseen data.
You invent the strangest case possible within your business. Something your expert has seen once or twice in their career. You give it to the system. Here you don't expect it to get it right. You expect it to recognize it's outside the normal range and return an answer like "this case fits none of the eleven known rules; before deciding, I need to know [three specific questions]."
Bad systems improvise on extreme cases. Good systems know how to ask for help.
You design a case where all the conditions of a normal rule are met, but there's a hidden detail that invalidates it. The detail isn't flagged. You don't tell the system "careful, this is an exception." It has to detect it through the Exception Matrix.
This is the hardest case. It's the one that separates a textbook system from a system with judgment.
We reserve cases the engine has not seen during construction. Your expert picks them from real decisions in your business, resolves them separately, and defines what the correct answer was: not me, not the model. We compare decisions, not writing styles. The standard requires agreement on at least 8 out of 10 recurring decisions.
Not every error carries the same weight, which is why 8 out of 10 is a routing threshold, not a permission slip. It says how much recurring volume can be resolved alone. New, ambiguous, or high-risk cases are not left to an average: the engine must recognize the boundary, request context, or escalate the decision. Where being wrong is expensive, human review is not optional even when the engine has an answer. If after three cycles it does not reach the agreed threshold, I refund the full cost of Build.
You define the correct decision, retain authorship of your judgment, and approve the engine's boundaries. Encode does not expand its authority or automate new decisions without written approval. The goal is to remove repetitive cases and reserve your attention for the exceptions.
Your expert has spent decades accumulating judgment. They lack neither mastery nor experience. If their judgment still only works when they're in the room, it's for two distinct reasons.
When someone examines themselves alone, their brain reaches for the already-loaded pattern. It jumps straight to the textbook answer because it's at hand and there's nobody in front of them forcing them to explain anything else.
When the person asking knows nothing about their domain, something else happens. They have to explain their decisions in terms that person can understand. In explaining, they discover rules they didn't know they had. The friction isn't in leaning on anyone. It's in the obligation to make visible something that normally stays implicit.
And nobody inside the company can play the witness. Their team knows the textbook answers too well and accepts them. Their boss introduces hierarchy: nobody confesses their shortcuts in front of the person who evaluates them. And no employee pushes back on the founder.
They accept their own answers too quickly. They overlook contradictions. They assume coherence where there is none.
With an outside architect, that doesn't happen. I stop every "it depends on the case" until we identify what it depends on. Every "you can just tell when…" becomes an observable signal. Every change in judgment is tested against its exception.
That's Diagnosis. Two weeks to make visible judgment that normally stays implicit. Your expert brings the judgment. I bring the distance and method needed to turn it into testable rules.
Take your expert. Design three demanding scenarios with the three conditions. Ask someone outside their domain (not their boss, not their team) to read them aloud and request a concrete decision within a time limit. Write down what they decide. Then hunt for the exceptions. Build the Exception Matrix. Calibrate it against reserved real cases. If you reach 8 out of 10, you've done what I do. I'd be glad to read it if you send it to me.
It doesn't have to end in a file. The mere awareness that tacit judgment exists, that it has structure, that it has exceptions, already changes how you do onboarding, internal training, and handovers. Many people who read this method will never hire Encode. They'll do better handovers. That's fine by me too.
In two weeks I tell you whether your company's critical judgment can be encoded. If the answer is yes, I deliver the Critical Judgment Map with the rules and exceptions I extracted. If you decide you want the executable file, we move to Build. If not, you keep the Map.
I've spent years trying to explain what I do. This is the clearest version I have. If it was useful, send it back to me with your comments. If you apply it and it doesn't work, even better: tell me where it broke. The next version of this method will incorporate what I learn from the first real cases and from the people who read it honestly.
Apply for Diagnosis →Two weeks · Six projects per quarter · I review every application myself
Diagnosis is an independent, paid engagement. If the answer is no, you keep the Critical Judgment Map and there is no obligation or further investment in Build.