Encoded Founder — Chapter V

Encoding

How to get what is in your head out of your head and into a system that carries it

The Same System, Two Outputs

A field engineer walks into a semiconductor fabrication plant in Osaka. The lithography machine on Line 4 has stopped producing within tolerance. Every minute of downtime on this line costs the company more than his monthly salary. He has two years of experience. The senior specialist who built the diagnostic protocol for this machine is in Munich, asleep.

Without the encoded system, the engineer follows the standard troubleshooting checklist. He tests power supply integrity. He recalibrates the optical alignment. He checks the resist coating parameters. Three hours pass. The senior specialist wakes up, joins a video call, listens for forty seconds, and says: "Check the ambient humidity sensor on the left chamber wall. When it drifts above sixty-two percent, the resist thickness varies by four nanometers and the exposure dose compensates in the wrong direction. It has been doing this since the firmware update in November." The machine is running again in eleven minutes.

With the encoded system, the engineer queries it at the moment of failure. The system carries the senior specialist's diagnostic sequence, extracted from hundreds of prior incidents, structured as a decision tree that routes by symptom cluster. It asks the engineer three questions. On the second answer, it identifies the humidity sensor pattern. The engineer walks to the left chamber wall, confirms the reading, adjusts the threshold. Fifteen minutes. First attempt.

First-attempt resolution rate before encoding: fifteen to twenty percent. After: seventy-five. Root-cause identification speed: two hundred and sixteen times faster.

Now the inverse. Faros measured over ten thousand developers using AI coding tools. The lab headline was familiar: fifty-five percent faster task completion. The production headline was not. Bugs rose nine percent. Code review cycles stretched ninety-one percent longer, because reviewers had to verify whether the AI had introduced subtle errors. The developers felt faster. The organization measured nothing.

Same category of tool. Same underlying models. The semiconductor system carried fifteen years of a senior specialist's judgment encoded into a diagnostic architecture. The coding tools carried generic pattern completion with no organizational context, no decision logic, no understanding of which code mattered and which was scaffolding.

One system encoded expertise, the other encoded speed.

Evidence

The Encoding Gap

What Encoding Is

A master chef can taste a sauce and know, without measuring, that it needs acid. Not sweetness. Not salt. Acid. That judgment was built across twenty years of tasting, adjusting, failing, and recalibrating at the speed of dinner service. It lives in his palate and his memory, in the relationship between what his tongue registers and what his hands do next.

Encoding is writing the recipe. The recipe will never reproduce the chef's exact dish. A recipe cannot encode the micro-adjustments he makes at the stove, the way he reads the color of a reduction and decides to pull it thirty seconds early because the pan is running hotter than usual. But the recipe can produce a dish that is eighty percent as good, one hundred percent of the time, without the chef standing over the stove. And in a restaurant that serves four hundred covers a night, eighty percent consistent is worth more than one hundred percent from a chef who can only plate twenty.

Encoding is not documentation, and most people miss the distinction at the cost of building the wrong thing. Documentation describes what the expert does; encoding does what the expert does. The difference is that a document sits in a folder until someone remembers to open it, while an encoding runs every time a request enters the system. Documentation degrades the moment its author leaves, because nobody updates what nobody reads. Encoding compounds, because each execution produces feedback that improves the next.

Framework

Encoding vs Documentation

Forty-two percent of institutional knowledge exists only in employees' heads, undocumented. When those employees leave, the knowledge leaves with them. Documentation was supposed to solve this but never did, because documentation captures WHAT the expert does without capturing WHY the expert decides. The "what" expires the moment the tools change. The "why" survives everything.

One prerequisite sits above the encoding itself. Encoding expertise without encoding the organization's purpose produces the Copilot paradox: individually competent, organizationally directionless. Before the system can apply the expert's judgment in the right direction, it needs to know what the organization is trying to achieve, what trade-offs are acceptable, and what decisions require a human. Chapter 4 mapped the structure. The first thing encoded into that structure is why it exists.

Framework

The Three-Layer Encoding Model

Encode at Layer 1 first. Always. The franchise manual McDonald's wrote in 1961 is Layer 1 decision logic: when the patty reaches this temperature, it is done. The fryer model has changed twelve times since then. The decision logic has not. When the next platform shift arrives and Layer 3 needs rebuilding, someone with deep Layer 1 encoding reconstructs the technology interface in days. Anyone who encoded only at Layer 3 starts over from nothing.

The Jagged Frontier

Seven hundred and fifty-eight consultants at one of the world's largest firms. Same AI tool deployed to all of them in the same week. Researchers at Harvard and Boston Consulting Group measured the results across two types of tasks: ones inside the AI's competence boundary and ones outside it.

Inside the boundary, encoding boosted performance by forty-three percent. Higher-quality deliverables, faster completion, outperformance on every metric the researchers tracked. Below-average consultants gained the most, because the AI distributed the top performers' encoded judgment to everyone who used it.

Outside the boundary, encoding hurt performance by twenty-three percent. The consultants using AI on tasks that exceeded its competence produced worse output than those who worked without it. They trusted the system's confidence without recognizing its limits. The AI did not say "I do not know how to do this." It produced fluent, structured, convincing work that was wrong in ways only an expert would catch.

The same tool, the same week: plus forty-three inside the frontier, negative twenty-three outside it.

The boundary between where encoding helps and where it hurts does not divide neatly along tasks or departments. It cuts through every domain at unpredictable angles. A litigation attorney's encoded system might handle contract review at ninety-five percent fidelity and collapse on novel jurisdictional arguments. A sales team's encoded methodology might close standard deals with higher conversion and destroy complex enterprise negotiations by flattening the judgment that was supposed to flex.

The researchers called it the jagged frontier. The name prevents a dangerous simplification: the belief that encoding is universally good or universally bad. Precisely good inside the frontier. Precisely dangerous outside it.

A nursing study at Ohio State measured what happens when the system is wrong and you trust it anyway. Nurses who relied on incorrect AI predictions performed ninety-six to one hundred and twenty percent worse than nurses working without AI at all. Not worse than the AI. Worse than working alone. The confident wrong answer overrode the nurse's own clinical judgment. Encoding's failure mode is actively destructive, not merely unhelpful.

You must map your own frontier before you encode a single function. The architecture chapter gave you the load-bearing domains and the knowledge holders. Filter those targets through the frontier before you begin extraction.

Diagnostic

The Jagged Frontier Map

The last row is yours. Test each function against real cases before committing to encode it.

A finding from the academic literature sharpens the filter further. Targeted expert annotations covering six to seven percent of the total knowledge base outperformed untargeted encoding spread across one hundred percent of the knowledge base. Not by a small margin. By a significant one. The six to seven percent that sat squarely inside the frontier, encoded with maximum depth, produced better results than surface-level encoding spread across everything.

The lesson is precision. You do not encode everything. You identify the six to seven percent of your expertise that falls inside the frontier, that recurs with enough frequency to generate feedback loops, and that carries enough organizational value to justify the extraction. You encode that with the full depth of both channels. Everything else stays human until the frontier shifts.

The strongest counterevidence to this thesis comes from MIT. In 2024, Michelle Vaccaro, Abdullah Almaatouq, and Thomas Malone published a meta-analysis of 106 studies and 370 effect sizes in Nature Human Behaviour. Their finding: human-AI combinations performed significantly worse than the best of humans or AI alone. Not marginally. Measurably. Hedges' g = −0.23. The paper does not deserve to be ignored, because the data is real and the methodology is rigorous.

But the design it studied is not the design this paper describes. Of 106 experiments, the dominant architecture was: generic AI produces a suggestion, human decides whether to accept it. No encoded expertise. No structured task allocation. No frontier mapping. Only three of 106 experiments even attempted predetermined delegation of subtasks to humans and AI. Vaccaro's meta-analysis is a comprehensive study of combining with AI. This paper is about encoding into AI. The operation is fundamentally different. The Siemens team did not put a human next to a generic model. They wrote the expert's decision logic into the system before it ran. The 206 percent improvement was not human plus AI. It was AI that already carried the human's knowledge.

The frontier resolves both findings. Vaccaro's negative result on decision tasks (g = −0.27) maps to outside-the-frontier failure, where the AI's confident wrong answer overrode the human's own judgment. The positive result on creation tasks (g = +0.19) maps to inside-the-frontier success, where the AI's processing power added genuine value. Dell'Acqua showed this directly: plus forty-three percent inside the frontier, minus nineteen percent outside, same tool, same week, seven hundred and fifty-eight consultants. Human-AI collaboration does not fail. Combining without encoding fails. Adding noise to a system that already carries a clear signal degrades the output. Encoding ensures the system carries the expert's signal before it runs.

Encode Decisions, Not Processes

A sales team switches CRMs, and every process document they spent forty hours writing for Salesforce is worthless by Monday morning. "Step 1: Navigate to Accounts. Step 2: Click New Lead. Step 3: Select Lead Source from the dropdown." Every screenshot and workflow diagram, every click-by-click walkthrough: gone. Eleven months of documentation, killed by a platform migration someone approved on a Tuesday.

Thorough, well-formatted, correct in every detail, and completely perishable. Built to describe how to operate one piece of software, they could not survive the replacement of that software with another.

But buried in those same documents was a paragraph nobody highlighted when it was written. "When a prospect says 'we're not ready,' the real objection is almost never timing. It is fear of change. The prospect who says 'not now' is saying 'I don't trust this will work.' Push on the fear, not the timeline."

That paragraph works in Salesforce. It works in HubSpot. It would work in a Claude system prompt or whatever replaces both in three years. The processes expired overnight. The decision will outlast every tool it touches.

Processes describe how to operate a particular tool in today's interface, navigating menus and filling fields in a system that will be replaced by the next vendor decision made in a meeting you were not invited to. They expire with every software update. Decisions describe the judgment that produces the right outcome regardless of which tool executes it: what should we do when this situation arises, and why does this response work better than the obvious alternative. One survives the next platform change. The other does not survive the quarter.

Ray Dalio built this distinction into the operating system of Bridgewater Associates over three decades. He did not encode how to navigate Bloomberg Terminal or how to route a trade through a specific execution platform. He encoded the judgment calls that ran beneath every interface the firm has ever touched: when to increase position size relative to conviction and correlation risk, how to weigh the credibility of the person defending an investment thesis against someone challenging it. Three hundred and seventy-five principles, written in plain language, tested against real market conditions, governing ninety-nine percent of the firm's decisions. The technology stack underneath those principles has been rebuilt multiple times. New trading platforms, new data systems, new analytical software. The principles carried forward untouched each time, because they never described the tool. They described the thinking.

The terminal changed every few years. The principles have not changed in three decades. Fifty-five billion dollars in cumulative profits.

McDonald's figured this out in 1961. Forty thousand restaurants in a hundred and nineteen countries execute the same encoded decision logic through equipment that has been replaced a dozen times over. The manual encodes when the patty is done. It has never encoded which machine cooks it. Boyd's OODA Loop, in the same vein, has survived fifty years of weapons changes because it encodes how to make decisions under uncertainty, never how to operate a specific aircraft.

Pull the same lens across your own operation. Every function contains both columns. Sales carries a decision ("the real objection is usually fear, not timing") right next to a process ("navigate to Deals, click Create Deal, fill in the Amount field"). Hiring carries a decision ("pattern recognition in the domain matters more than years on a resume") buried under a process ("post on LinkedIn, screen in Greenhouse, schedule via Calendly"). The table below maps four functions.

Visual 5

Decisions vs. Processes

The left column survives platform changes. The right column does not survive the quarter.

I saw this split across thirty clients in three years of building systems. The founders who built their encoding around processes rebuilt every time a tool changed or a model updated. The founders who built around decisions ported their encoding in days, sometimes hours. Same expertise underneath, different durability.

For each load-bearing domain in your architecture map, run this separation. Decisions in one column, processes in the other. The decisions are your encoding targets. The processes are implementation details that any capable system can work out on its own once it carries the decision logic.

Encode the left column first. Encode it deep. Everything else follows.

The Two Channels

An operations team encodes its entire client onboarding into if-then rules. If contract value exceeds fifty thousand, route to senior account manager. If the intake form says "enterprise," trigger the enterprise sequence. If the first deliverable is due within fourteen days, flag as priority. The rules fire correctly. Every condition evaluates. The system runs without errors. And the first three client emails read like they were produced by someone who memorized the playbook but never touched a real account.

A competing firm has the inverse problem. Their best account manager reads the temperature of a client's first email and adjusts the entire project approach before the kickoff call. She hears hesitation in a voicemail and reroutes the deliverable timeline without being asked. She knows which clients need hand-holding and which ones want to be left alone, and she can tell the difference from a three-line email. Her instinct is flawless, built from eight years of closing loops across four hundred client relationships. She cannot serve more than twelve accounts before the quality starts to erode. Her expertise is real, and it is also trapped.

Code without judgment produces technically correct, strategically empty work. Judgment without code stays locked inside one person who cannot be in two meetings at once. Neither scales alone, neither compounds, and the question is how to run both.

The first channel is explicit rules: clear if-then logic that translates into code, automations, and system constraints. "If the client's contract value exceeds fifty thousand, route to senior account manager." "If the deliverable fails quality checks on two of five criteria, return to production before the client reviews it." Guardrails that prevent the system from drifting outside the boundaries where it performs well.

The second channel is tacit principles: contextual judgment too fluid for a conditional statement. "The tone of this client's email shifted from collaborative to transactional over the last two messages. Something changed in the relationship. Escalate before the next deliverable ships." Intelligence for when the rules run out.

Visual 6

The Two Channels

Neither channel alone produces the breakthrough. The combination is multiplicative.

Researchers at Siemens and Chalmers University tested each channel in isolation, then combined. They built AI agents for engineering data visualization, encoding explicit procedural rules as executable Python functions and tacit design principles as system prompts. Then they measured output quality at each level.

Visual 7

The Encoding Escalation (Siemens CAIN'26)

Source: Ulan Uulu et al., CAIN'26, ACM. In specific scenarios the gap reached 614% with perfect evaluator consensus.

The jump from Mode 2 to Mode 3, from rules alone to both channels combined, was where evaluators stopped being able to distinguish the system's output from the expert's. On specific tasks, the gap reached six hundred and fourteen percent with perfect evaluator agreement.

Erik Brynjolfsson and his team at Stanford published converging evidence through a different lens. They studied 5,179 customer support agents and published the results in the Quarterly Journal of Economics. When AI carried the encoded behavioral patterns of top performers, average productivity rose fourteen percent. For novice agents, thirty-four percent. The finding that reshapes the encoding argument: agents with two months on the job, working inside the encoded system, matched agents with six months of tenure working without it. Four months of accumulated experience, compressed to zero. The system gave novices the senior agents' judgment running underneath every conversation.

Above both channels sits organizational purpose. Rules tell the system how to execute. Principles tell it when to override standard procedure. Organizational intent tells the system why either matters. Bridgewater carries all three and produced fifty-five billion dollars. Gong embedded all three into its sales methodology: MEDDIC scoring through AI generates seventy-seven percent more revenue than the same framework sitting in a training manual nobody reads. Where a layer is missing, the pattern breaks. Copilot encoded developer expertise without organizational direction: agents coded fifty-five percent faster while producing zero organizational improvement and nine percent more bugs.

The Encoding Process

The architecture chapter identified your load-bearing domains and named the people who carry them. You have a map and names.

Pick one person, the one whose absence would hurt most. Schedule thirty minutes. Record the conversation. Tell them you need them to train the best new hire they have ever met: someone who learns fast and remembers everything but knows nothing about the domain.

Then ask five questions:

Visual 8

The 30-Minute Expert Download

Record the answers. Transcribe. Highlight every sentence containing a decision rule, a judgment call, or a quality standard.

These five questions come from cognitive task analysis, the discipline the military and NASA developed to extract expertise from retiring specialists. Gary Klein refined these probes across decades of studying how experts decide under pressure. The structure forces the expert past the surface of what they do and into the judgment beneath it.

Transcribe the recording. Highlight every sentence that contains a decision rule, a judgment call, or a quality threshold. Those highlights are your encoding targets. Most experts produce between fifteen and forty in thirty minutes. If the number falls below ten, the questions were answered at the wrong altitude. Go back and ask for real cases where the decision could have gone either way. The encoding lives in the specificity.

One constraint: the extraction only captures what was recorded. Hallway conversations, gut reads on a phone call, the decision made in the car on the way to the meeting resist extraction because they were never captured. The bottleneck is data availability, not AI capability. The more of your expert's behavior you record, the more you have to encode.

Visual 9

The 5-Step Encoding Process

The table covers the mechanics. The step worth expanding is Deploy, because it is where the real encoding happens. The first version will be wrong. That wrongness is the point. A wrong first version gives you something to correct, and the corrections encode knowledge the expert could not have articulated in the download, because they did not know they knew it until they saw the system get it wrong. The expert sees the output and says: "No, not that. THIS is what I mean." Those corrections are worth more than the original extraction.

The first time I ran this process, I expected the extraction to be the hard part. It was not. The expert talked for forty minutes and produced thirty-two highlights. The hard part was deploy. The gap between what the expert said and what the system produced was enormous, words that were precise in the expert's mouth became vague in the system's hands. Three correction cycles before the output started resembling something the expert would recognize. Those corrections taught me more about what the expert actually knew than the entire download. The extraction gets you the map. The corrections get you the territory.

The timeline is honest. Four to eight weeks for the first domain, because you are encoding two things simultaneously: the expert's knowledge and the method for extracting it. The second domain takes two to four weeks. By the third, you have a repeatable process. By the fifth, the system begins doing parts of the extraction without you.

The Encoding Flywheel

The first domain takes four to eight weeks. The second takes half that. By the fifth, you are not writing the instructions. The system writes them. You approve.

That compression comes from the system learning alongside you. Corrections from validation feed back into the encoding, handled edge cases expand the pattern library, and outputs that pass the Blind Output Test become reference points for the next domain. The flywheel turns because the feedback loops compound.

Visual 10

The Encoding Flywheel

The critical transition happens around cycles three and four. The system has enough encoded knowledge that it starts catching patterns from the expert's daily work without being prompted. When the same decision pattern appears five or more times, it flags it: "You consistently route high-value renewals to the same account manager when client communication drops below twice per week. Should this become a rule?" The expert approves or corrects. Encoding deepens without anyone sitting down for a formal extraction.

The research names this shift the Verification Constraint. After encoding reaches a critical mass, the expert stops executing and starts checking. The Brynjolfsson study proved the pattern at scale: the expert who once served twenty clients by executing now served two hundred by verifying. Judgment became the quality gate, not the production line.

The clock starts the day you run the first extraction, and your competitors cannot reset it.

The Encoding That Survives

When Anthropic released Claude 4, everyone who had encoded their expertise as model-specific prompts had to start over. The prompt syntax changed. The context window expanded. Behaviors that worked in Claude 3.5 produced different outputs in the new model. Weeks of prompt tuning, gone in an afternoon.

Everyone who had encoded their decision logic in plain text rebuilt their technology interface in three days.

Which layer they had encoded into made the entire difference:

Visual 11

What Survives

Encode at Layer 1 first. Always. When the tools change, Layer 3 gets rebuilt in days. Layers 1 and 2 carry forward untouched.

Encoding the doing scales. Encoding the deciding is the moat. You need the 80% that covers recurring patterns, freeing the expert for the 20% that demands genuine novel judgment.

The nuclear industry arrived at the same conclusion through fifty years of managing knowledge that must survive across decades and regulatory regimes, through waves of personnel turnover. No single format survives all timescales. Redundancy across layers is the only answer.

Now the tension you have been sensing since the first section of this chapter.

Encoding your expertise makes it reproducible. The scarcity that gave your knowledge economic value begins dissolving the moment it runs in a system someone else could study. The Codifier's Curse: the act of encoding creates the conditions for its own commoditization.

Which does not mean you stop. You have seen what happens to those who refuse. It means you see clearly where the moat sits: not in the knowledge, but in the system that encodes it and the proprietary data that compounds through every deployment. Knowledge is the input. The system is the defense. And that system is the subject of the next chapter.

The first time the encoded system produced output I could not distinguish from the expert's own work, I felt two things simultaneously. Relief, because the bottleneck that had constrained every operation I had built was dissolving. And a question I had not anticipated: if this runs without anyone present, who makes sure it runs in the right direction? The encoding carried the judgment. It did not carry the feedback loop that tells the judgment when to update. That gap is infrastructure.

The E-Score diagnostic and AI Auditor prompt for this chapter are in Appendix F.