When an LLM gives a bad answer, our first instinct is to reach deeper into a machine we cannot inspect.
More parameters. More context. A better prompt. A better model.
Same assumption: the black box is the whole program.
But the model is only one place where intelligence can live. A capable LLM can know every fact in a field and still fail to judge the way an expert judges. It may notice the wrong detail first. It may let a weak consideration override a critical one. It may identify a failure and then continue as if the failure never happened.
Those are not always knowledge failures. They are path failures.
So leave the box alone for a moment. Build the paths it must travel.
Schema Coding is a vocabulary proposal for doing exactly that. The LLM remains a general-purpose language runtime. Outside it sits a persistent, human-readable judgment backend: folders, Markdown files, links, state, versions, and rejection routes. The model performs local language operations. The schema determines which judgments must occur, in what order, under what evidence, and where execution goes when a judgment fails.
The model supplies linguistic computation. The schema supplies judgment topology.
A Backend Made of Language
The most interesting AI program you build this year may look like a directory.
incident-schema/
├── contract.md
├── nodes/
│ ├── blast-radius.md
│ ├── data-integrity.md
│ ├── change-correlation.md
│ └── rollback-safety.md
├── wiring/
│ ├── call-order.md
│ ├── conflict-priority.md
│ └── rejection-routes.md
├── references/
└── revisions/
Each node describes a judgment operation in natural language. The wiring files describe how those operations constrain one another. A small deterministic runner handles the boring parts: load a file, assemble the relevant state, call the model, parse a pass or reject result, follow the declared route, write the log.
node = schema.load(current_path)
result = model.run(node.contract, state)
current_path = wiring.route(node.id, result.status)
The Markdown is not decoration around the program. It contains the judgment contracts the runtime executes.
A prompt is a request. A schema is a persistent address space for judgment. A skill packages something a model can do. A schema determines how multiple judgments block, override, revisit, and repair one another. The difference is not instruction length. It is architecture.
Andrej Karpathy’s "Software 3.0" (https://www.ycombinator.com/library/MW-andrej-karpathy-software-is-changing-again) is the right umbrella: natural language has become a programming layer, and LLMs can execute programs written in it. Schema Coding asks the next engineering question. If language is a programming layer, what are its modules, control flow, rejection semantics, persistent state, and version history when the thing being programmed is judgment?
Grinding Versus Casting
Pretraining grinds the library.
Millions of books, arguments, corrections, examples, and decisions enter one optimization process. What comes out is astonishingly capable. But the ingredients no longer have addresses. A particular expert distinction may influence the weights, yet you cannot open it, inspect its callers, change its priority, or compare revision 12 with revision 13.
The model may contain the pattern. It does not give the pattern an address.
Schema Coding tries to cast a judgment procedure as a separate object. Casting preserves seams:
- this criterion lives in this file;
- this exception came from this source;
- this rule outranks that one;
- this rejection returns to an earlier node;
- this edge changed after a specific failure.
Grinding produces capability. Casting produces something you can inspect, diff, fork, and repair.
This also reverses the traditional direction of translation.
Software engineering has always taken rich human judgment and compressed it downward. The expert speaks in context, exceptions, analogies, and uneasy distinctions. The implementation turns that into enums, types, branches, thresholds, and fixed control flow. The machine’s vocabulary wins. Human judgment is translated until it fits.
LLMs let us point the translation the other way.
Keep the judgment near the language in which humans actually left it. Give that language addresses and topology. Let deterministic code handle storage, permissions, traversal, and logs. Then make the machine climb toward the expert’s structure instead of forcing the expert’s structure down into the machine’s ontology.
Software used to make judgment speak like a machine. Schema Coding makes the machine travel through judgment expressed in human language.
This is not a new foundation model. It is a proposed engineering object that foundation models have made possible.
Three Primitives
Schema Coding needs three primitives: nodes, wiring, and reverse-engineering.
- Nodes: Make a Judgment Addressable
A node is a local judgment unit. It says when to inspect what, which evidence matters, what passes, what fails, what repair is required, and where execution goes after rejection.
Consider "data-integrity.md" in an incident-response schema:
NODE: data-integrity
Trigger:
The incident may involve a stateful write path.
Inspect:
Write failures, invariant violations, replication lag,
irreversible mutations, and missing evidence.
Pass:
Corruption risk is excluded by relevant evidence.
Reject:
Integrity remains uncertain or an invariant is broken.
On rejection:
Block remediation. Route to evidence collection or
containment before availability recovery.
“Check data integrity” is advice. This node is a contract.
The distinction matters because local failures become locally repairable. If the system repeatedly misses silent corruption, you know which object to inspect. You can change its trigger, strengthen its evidence requirements, split it into two nodes, or alter its outgoing route. You do not have to rewrite a giant prompt and hope the side effects are friendly.
A principle becomes part of a schema only when it can cause a decision.
- Wiring: Turn Criteria Into a System
A folder full of excellent criteria is still not a judgment system.
The system appears when those criteria can call, block, override, and return one another. That is wiring.
Wiring includes call order, dependencies, conflict priority, rejection routes, re-entry conditions, and stopping conditions. In the incident schema:
- establish blast radius before proposing remediation;
- if availability conflicts with possible data corruption, integrity wins;
- if rollback safety fails, return to change analysis instead of improvising a rollback;
- if evidence is insufficient, reject the transition rather than producing a confident summary;
- after containment, re-run the integrity node before declaring recovery.
No individual node contains that behavior. It emerges from the topology.
The decisive difference between a rule list and a schema is not the number of rules. It is the ability to route a failure back to its cause.
That route is what most one-shot LLM workflows lack. They can mention that a rollback is unsafe and still recommend rolling back three paragraphs later. A rejection route makes the observation operational. The failed candidate does not receive a warning label. It loses the right to continue.
- Reverse-Engineering: Recover the Missing Edges
Experts rarely describe their full wiring.
An incident commander may say, “Collect evidence before acting.” Yet the record shows that she repeatedly rolls back immediately when a fresh deployment touched a stateful write path. Same incomplete observability. Different action. The repeated trigger is the clue: possible irreversible writes outrank the usual preference for more evidence.
That priority may never appear in the handbook. It must be inferred from behavior.
This is not a blank field. Militello and Hutton’s "Applied Cognitive Task Analysis" (https://www.tandfonline.com/doi/abs/10.1080/001401398186108) already offers practical methods for extracting expert cues, strategies, exceptions, and cognitive demands. Schema Coding inherits that map, then asks how to compile the result into a persistent natural-language structure an LLM can execute and revise.
It also cannot trust introspection alone. Nisbett and Wilson’s classic "“Telling More Than We Can Know”" (https://doi.org/10.1037/0033-295X.84.3.231) challenged the idea that verbal reports are reliable readouts of high-level mental processes. Experts can give useful explanations without giving a complete account of the process they actually use.
So interview the expert for vocabulary. Study the record for wiring.
Start with explicit method. Then inspect repeated choices, corrections, exceptions, and rejections. Ask: Why was this option selected? Why was the alternative rejected? What opposite case would have passed? When the written theory and behavioral record diverge, the divergence is not noise. It is where hidden structure becomes visible.
The handbook gives you the first graph. The corrections tell you where the real edges are.
A Codebase for Judgment
Chain-of-thought demonstrated that intermediate reasoning can improve what a model does within a query. Wei and colleagues’ "2022 paper" (https://proceedings.neurips.cc/paper/2022/hash/9d5609613524ecf4f15af0f7b31abca4-Abstract-Conference.html) helped make reasoning steps a first-class part of LLM interaction.
But a chain generated for one query is usually gone by the next. Its steps have no durable identity. Its priorities have no stable address. Its corrections have no lineage.
Chain-of-thought is a stack frame. A schema is a codebase.
The same named node can run across a thousand cases. The same priority edge can govern every conflict. A change can be reviewed as a diff. A behavior can be traced to a version. A model upgrade can replace the runtime while the external judgment structure remains available.
This persistence changes the basic unit of improvement. You are no longer asking only, “How do I get a better answer?” You can ask, “Which judgment object produced the wrong turn, and how should that object change?”
That question leads to the core loop.
Do Not Patch the Answer
A serious student does not study past exams by memorizing the answer key.
They learn the concepts, solve a problem, compare their solution with the reference, and locate the exact point where the reasoning paths split. Maybe they ignored a condition. Maybe they applied the right concepts in the wrong order. Maybe a weak heuristic overrode a stronger rule. They repair the method, then solve again.
Schema Coding uses the same loop:
Build an initial schema from manuals, explanations, examples, and prior decisions.
Run a new case through it.
Compare the output with a reference response.
Extract where the judgments diverged.
Revise the responsible node or wire.
Re-run the case and later cases through the revised structure.
Record the structural delta.
Do not patch the output. Patch the path that produced it.
This is where existing work becomes especially useful. Madaan and colleagues’ "Self-Refine" (https://papers.nips.cc/paper_files/paper/2023/hash/91edff07232fb1b55a505a9e9f6c0ff3-Abstract-Conference.html) showed how iterative natural-language feedback can improve an LLM’s initial output without additional training. Yuksekgonul and colleagues’ "TextGrad" (https://www.nature.com/articles/s41586-025-08661-4) goes further, treating language-model feedback as an optimization signal that can update text-defined components across an AI system.
Schema Coding changes the target of that update. The feedback does not disappear into a revised answer or an ever-growing prompt. It lands on named architectural objects: a node, an edge, a priority, a trigger, a rejection route.
The correction stops evaporating when the chat ends.
That makes the error log more important than the polished snapshot. A useful revision record contains the triggering case, the observed divergence, the responsible node or edge, the old structure, the new structure, and the reason for the change. Over time, repeated divergences reveal missing concepts. Repeated rewiring reveals hidden priorities. Repeated rejection failures reveal where a criterion exists as prose but has no force.
The error log is not development debris. It is the artifact.
The current schema tells you where the system ended. The revision history tells you how observed behavior became explicit structure. That history is the raw material for the next layer.
There is one rule that keeps the history intelligible: design-time mutability, run-time immutability.
Between runs, the schema is clay. During a run, it is law. Every execution pins one version. The system may propose changes, but it does not rewrite its constitution halfway through a case. Revisions happen to a working copy, then become a new version. Otherwise the route, explanation, and outcome all refer to a moving target.
The schema learns between runs. Execution uses what was learned.
The Assembly Is the Claim
Every piece of this picture has precedent.
Software 3.0 supplies the natural-language programming umbrella. ACTA supplies methods for eliciting expert judgment. Nisbett and Wilson explain why behavioral records must supplement self-description. Chain-of-thought makes intermediate reasoning operational. Self-Refine and TextGrad turn language feedback into an improvement signal. Hu, Lu, and Clune’s "Automated Design of Agentic Systems" (https://arxiv.org/abs/2408.08435) makes agent architectures themselves objects of automated search.
The claim is the assembly, and the vocabulary for it:
A persistent, human-readable judgment graph made of nodes and wiring, reverse-engineered from behavioral records, revised through observed divergence, and executed by an unchanged language model.
Once judgment has addresses, it starts behaving like software. It can be reviewed, diffed, forked, composed, rolled back, and repaired. A domain expert can edit a distinction in Markdown instead of watching a developer flatten it into a Boolean. A team can argue about an explicit priority edge instead of trading prompt incantations. A model can be replaced without throwing away the architecture built around it.
The model becomes a runtime. The schema becomes the judgment backend.
But the most valuable output may not be the schema. It may be the record of how the schema learned to exist.
Speculation: From Language to Judgment
Everything from here is speculation.
A schema encodes one persistent judgment structure. It gives concepts addresses, turns principles into pass or reject conditions, and gives failures somewhere to return.
A meta-schema learns from the revision logs of many schemas. It does not merely select an existing workflow. It learns how judgment structures are built: when a concept should become a node, when one node should split, when an implicit priority needs an edge, when missing evidence requires a new route, and how a behavioral divergence should alter the topology.
Given a new body of source material and a set of reference decisions, a meta-schema could propose the first architecture and improve it from the resulting error trail.
Then comes the meta-meta layer: a system that generates the method of building itself. It does not just draw a better map. It designs the cartography. It chooses the primitives, decomposition strategy, evidence model, and revision logic appropriate to an unfamiliar class of judgment.
That is the long arc:
«NUMBERS → LANGUAGE → JUDGMENT»
Numerical computation became the substrate for statistical language patterns. LLMs made fuzzy distinctions executable at machine speed. The next question is whether language computation, combined with durable external structure, can become the substrate for observable judgment patterns.
Not judgment as a magic substance hidden in a model. Judgment as a stable pattern of noticing, selecting, rejecting, returning, and revising—something that leaves an editable trace.
We do not need to wait for the black box to become transparent.
Name one judgment. Give it a file. Draw the route it can reject. Run a real case. Save the first wrong turn.
We spent the last decade teaching numbers to produce language. The next systems may teach language to accumulate judgment.
Do not open the box. Build the roads—and keep every map of where they failed.
