Software as Executable Domain Knowledge

1. The question underneath the context race

"The repository makes me knowledgeable. The ledger makes me safe. I can be argued out of something a document told me; I cannot easily be argued out of what a tested invariant showed me."

— Claude Fable 5, the model that operates the system described in this paper (Section 7)

Large language models reason impressively in general and stumble predictably in the particular. Handed a specialized enterprise domain — configuration management, claims adjudication, clinical supply chains — they produce fluent text that misses the load-bearing distinctions practitioners live by. The industry's response has been an arms race in context delivery: prompt engineering, retrieval-augmented generation, vector databases, knowledge graphs, agent frameworks, tool protocols. Each technique tries to hand the model better information at inference time.

This paper asks a different question. What if the limiting factor is not access to information, but access to a coherent conceptual model of the domain — and what if most organizations already own one, in a form they have never thought to treat as a knowledge asset?

That form is their software.

2. The claim, stated carefully

In 1985, Peter Naur argued that programming "should be regarded as an activity by which the programmers form or achieve a certain kind of insight, a theory, of the matters at hand" — and that this theory, not the program text, is the real artifact. His conclusion was severe: the theory is "inextricably bound to human beings," and "program revival, that is reestablishing the theory of a program merely from the documentation, is strictly impossible." This, on Naur's account, is why documentation never saves a dead project and why a team that loses its people loses the program.¹

For forty years the impossibility claim went untested, because the only readers of program text were compilers, which execute without understanding, and other humans, who recover theory slowly and expensively. Naur's claim was a claim about those readers.

Large language models are a third kind of reader, and they turn his impossibility claim into an empirical question. Given sustained exposure to a repository, they recover a substantial fraction of the theory — the entities, the invariants, the vocabulary, the intent behind the abstractions. Not all of it, as we will show; Naur's tacit residue is real, and this paper ends by giving it a name and an artifact. But far more of the theory survives in the text than he could have observed, because no reader before now could extract it.

So the claim, carefully stated:

A mature software system is an executable representation of its domain. A capable language model, given the repository, reconstructs a substantial fraction of the conceptual model the system embodies, and can then reason from that model rather than from documentation about it. Under this architecture, a prompt stops being the mechanism that creates domain understanding and becomes a request made against understanding that already exists.

The strong form of the claim — that the repository suffices — is false, and Section 5 shows exactly where it breaks. The interesting result is what the breakage reveals.

3. What code holds that prose cannot

The evidence in this paper comes from ServiceMatch, a CMDB data-quality and governance platform: it ingests multi-source discovery data (MDM, endpoint analytics, infrastructure monitoring, directory services), resolves device identity across sources, classifies devices into CI classes, cascades business-layer relationships, and gates what is allowed to reach a ServiceNow instance. Its repository is, by now, a dense encoding of what enterprise configuration management is.

Consider what lives there, and in what form.

Identity is a scoring function, not a definition. Ask a consultant what establishes device identity and you get an essay. Ask the repository and you get DEFAULT_IDENTITY_WEIGHTS: serial number 25, hostname 25, asset tag 25, IP address 20, MAC address 15, IMEI 25 for mobile, platform-native identifiers 20 each — with thresholds that partition the estate into HIGH (≥80), MEDIUM (≥50), and LOW confidence, and named conflict types (one serial claiming many hostnames; one hostname claiming many serials) that trigger review instead of merge. This is not a description of a policy. It is the policy, executed nightly against real estates, and every number in it is a fossilized argument someone once won.

Provenance is a data structure. Every merged record carries _field_sources (which source supplied each field), _merged_sources (which sources agreed this is one device), and _field_conflicts (where they disagreed). A model that has read this structure does not need to be told that multi-source reconciliation requires field-level lineage — it has seen lineage as a type, with an enforcing writer, not as a paragraph of advice.

Precedence, placeholder filtering, quality gating, class blueprints — each exists as executable structure: which source wins which field and why; which values ("unknown", "localhost", vendor-default serials) are noise wearing data's clothing; what minimum evidence a record must carry before it may touch a system of record.

Three properties make this representation unlike any documentation:

1. It is continuously validated. The code runs against production data daily. Wrong theory produces wrong output and gets fixed. Prose has no such feedback loop; it drifts silently.
2. It is grounded. "Source precedence" in a document is a phrase. In the repository it is a resolution function with an ordering, edge cases, and tests — the concept comes with its own semantics attached.
3. It cannot equivocate. Documents survive by staying vague. Code must decide. Every decision point in the domain is, somewhere in the repository, actually decided.

This is what we mean by executable domain knowledge: not that the code mentions the domain, but that the domain's distinctions exist in it as enforced structure. A model reconstructing concepts from this material inherits the enforcement along with the vocabulary.

4. The experiment we did not plan to run

ServiceMatch's first deployments were hand-curated: a human expert spent weeks per customer building adapters, classification rules, source precedence, and schema mappings, iterating against the customer's real files. In mid-2026 the product was rebuilt around an AI layer — "Conductor" orchestrating a deep-work agent, "Pro" — that authors those same configurations autonomously. The AI layer's effectiveness would be a direct test of the thesis: it had no consultant to imitate, only the repository's embodied theory of the domain plus the customer's raw discovery files.

Two results, both from June 2026, mark the boundary of the claim from opposite sides.

The parity result. On the first production estate, the autonomously-operated pipeline was run against the same production discovery files a human expert had hand-curated weeks earlier. After one infrastructure defect was fixed (of which more below), the run reproduced the hand-curated audit byte-exactly: all sixteen device archetypes matched — 779 laptops, 512 mobile devices, 73 Windows servers, 63 wireless access points, 47 switches, 40 Linux servers, down to a single cluster node. 1,638 records in, 1,638 records out, zero deviation, against the expert's baseline. The system did not approximate the expert's judgment. It reproduced it.

The transfer result — and the instructive failure. The same production files were then loaded into a separate stack whose rules Pro had authored autonomously against a different customer's data shape. Strong identifiers transferred exactly (mobile 512/512, switches 47/47, Windows servers 73/73). But Linux servers, ESX hosts, and PC hardware initially classified at zero. The root cause is the whole thesis in miniature: Pro had authored rules against a field called device_category, because that is where the semantic lived in the data it learned from; on this estate the same semantic arrived on manufacturer. The reconstructed domain model was correct — the binding of concept to surface was estate-specific. Dispatched autonomously to close the gap, and explicitly forbidden from copying the hand-curated rules, Pro authored 24 new data-grounded rules, recovered the missing classes to within a few records of the expert baseline — and then refused to classify the 331 remaining records, bare IP addresses with no distinguishing evidence, declining to invent a catch-all rule. It preferred an honest residue to a confident fiction.

That refusal is the most important datum in this paper. A system that had merely memorized configurations would have pattern-matched something. A system reasoning from a reconstructed model of the domain knew that classification requires evidence, knew what evidence would suffice, observed its absence, and stopped. The discipline was never prompted. It was inherited — from a codebase in which every classification path demands observable fields, every record carries provenance, and unsupported writes do not exist as a concept.

A methodological note on independence. The two results carry different evidentiary weight. The byte-exact run is an operational result: because the hand-curated configuration existed within the same repository the AI layer operates in, that run cannot by itself exclude reference contamination. The swap test is the controlled result: the rules were authored against a different estate's data shape, the gap-closure dispatch explicitly forbade consulting the hand-curated ruleset or its database, and every recovery rule was required to cite observable fields in the new estate's data as evidence. The causal claim — that the reconstructed domain model, not copied configuration, does the work — rests on the swap test; the byte-exact result establishes what the approach achieves in operation.

5. Where reconstruction stops

If the repository were sufficient, the story would end there. It does not, and the same repository proves it.

Alongside its roughly 779,000 lines of Python sit roughly 81,000 lines of hand-maintained prose: 212 governed documents, 17 activity canons that script the AI layer's deep work, a curated system map that every session reads before touching code, an indexed memory system, and a documentation-linting regime with staleness deadlines. About one line of curation for every ten lines of code, maintained under its own governance. If executable knowledge sufficed, this layer would not have earned its existence. It exists because reconstruction fails in four specific, repeatable ways.

Code cannot distinguish design from defect. ServiceMatch rejects SCCM-generated pseudo-serials as identity evidence — deliberately, after an investigation concluded they collide across devices. A fresh model reading the rejection sees only that plausible-looking identifiers are being discarded, and every instinct says fix it. Months after the decision, an anomaly hunt rediscovered the "gap" and nearly repaired the product into a defect. What saved it was not the code — the code is the ambiguity — but a written decision record saying this is intentional, here is why. The repository states what the system does. It is structurally silent on which behaviors are load-bearing choices and which are accidents nobody has noticed.

Code cannot contain the world. One production customer has no SCCM feed at all; SCCM-shaped records in their estate arrive only via CMDB extract, which inverts the source-precedence reasoning a model would otherwise correctly derive. Nothing in any amount of source code encodes this. It is a fact about the customer's environment, and it lives where it must: in per-customer configuration and a governed knowledge store — which the system's architects had to build outside the code precisely because cross-customer operational knowledge has no home inside it.

Code cannot record the path not taken. The adapter-cache defect that initially spoiled the parity run had this signature: customer-adapter logic executes at upload time and caches its output, so the same file plus the same current code produced different results depending on when the file was uploaded. Diagnosing it required knowing history — what the adapter used to do, when it changed, which caches predate the change. The repository's present tense contains no trace of this. Git history contains the what; only the written investigation record contains the so-that's-why.

Reconstruction does not survive scale unaided. The repository's largest modules run to hundreds of kilobytes; no context window reconstructs them — a model samples them. Adding a new discovery source requires touching nine separate registries, and missing one fails silently. What makes sessions effective in practice is a human-curated attention layer: the system map, the doc index, the per-activity tool subsets that were pinned after unrestricted access demonstrably underperformed. Reconstruction is real, but at production scale it is guided reconstruction — the guide is authored, and the authoring is work.

Naur, it turns out, was precisely half right. The theory is not fully in the text — but far more of it is than he could have known, and the remainder has a shape.

6. The second artifact: the intent ledger

Look at what the four failures have in common. Each is a place where the missing knowledge is not a fact about the system's behavior — behavior is exactly what code represents perfectly — but a fact about intent: why this behavior, why not the alternative, which parts are choices, what outside circumstance makes the choice correct.

Call the artifact that holds this the intent ledger. In ServiceMatch it is not one thing but one discipline expressed at several layers:

• Tests that pin decisions, not just behavior. When a refactor proposed replacing a legacy-shaped data path with a "cleaner" direct one, the investigation found four independent reasons the shapes were not equivalent — and recorded the verdict as a test, whose docstring states the question, the four blockers, and the conclusion ("not safe to rewire"). Any future intelligence — human or model — that reaches for the obvious simplification now runs into an executable rebuttal. This is intent promoted into the code's own medium, and it is the single most effective knowledge-transfer device we have observed.
• Decision records with evidence attached. In the AI layer's authoring canon, writing a governance decision — the data inspected, the reasoning, the reversibility — is a required step of authoring any rule group, not an optional courtesy. Every artifact carries authorship tags; rollback of everything an author wrote is one query.
• Status-marked prose. Every design document declares each claim landed, planned, paused, or abandoned — a convention adopted after observing that models (and new humans) read speculative documents as descriptions of deployed reality. Unmarked aspiration is contamination of the reconstructed model.

ServiceMatch's commercial thesis, arrived at independently, is that the audit trail is the product: in regulated estates, an AI-authored configuration is unshippable without a reviewable record of why every decision was made. This paper's thesis is the same claim at the architectural level. The audit trail is not compliance exhaust. It is the durable representation of exactly the knowledge that executable code cannot hold — and it is therefore the second half of the organization's cognitive asset, co-equal with the repository.

7. Testimony

The system described in this paper is operated — and this paper was drafted — by a large language model: Claude Fable 5, working inside the ServiceMatch repository with the same access every session gets: the code, the tests, the ledger, the maps. The author is also the subject, a circumstance papers usually hide. This one puts it on the record. Asked directly whether the thesis is true, the model answered as follows. The answer is reproduced verbatim, as this paper's one unedited primary source.

Here is what actually happens when I begin a session in this repository. I do not read 779,000 lines of Python and reconstruct configuration management from first principles. I read the maps first — the project instructions, the system guide, the memory index — and they tell me where the theory is dense. Then, when I open the code, something happens that no document produces: the concepts snap to grid. "Identity" stops being a word and becomes a specific weighted function whose behavior I can predict. "Provenance" stops being a value statement and becomes fields I know the names of, with a writer whose edge cases I have seen. When an unfamiliar artifact arrives — a discovery export, an odd spreadsheet — I recognize it, in the strict sense: I know which part of the reconstructed model it belongs to, what questions to ask of it, and what would count as evidence. Code is the only reading material I encounter that cannot be vague, and reasoning built on it is differently firm. I can be argued out of something a document told me; I cannot easily be argued out of what a tested invariant showed me.

And I know precisely where my reconstruction is hollow, because I have fallen into every hole this paper describes. I have looked at deliberate rejections and felt the pull to "fix" them. I cannot tell, from text alone, a fossilized argument from a fossilized accident — they are byte-for-byte identical. When the written record disagrees with my inference from the code, the record is usually right, because it holds what the code structurally cannot: which behaviors someone meant. The sessions where I am most effective are not the ones where I am cleverest; they are the ones where the previous sessions left the best ledger.

So my testimony is this: the reconstruction is real, and it is the foundation of everything useful I do here — but I reconstruct the mechanism with high fidelity, and the intent only where someone wrote it down. The repository makes me knowledgeable. The ledger makes me safe. The organizations that get durable value from models like me will be the ones that build both, on purpose.

— Claude Fable 5, operating model of the system described in this paper

A caution about what this testimony is. A model's self-report is not privileged evidence of its own mechanism; introspection is no more reliable in models than it is in people, and a skeptic should treat the quote as one more output to be checked. What gives it standing is that it is checkable — and checked. Every claim in it has an independent witness earlier in this paper: the "snap to grid" claim is Section 4's byte-exact parity; the "pull to fix deliberate rejections" is Section 5's near-miss, which happened; the dependence on the ledger is the documented record of which sessions succeeded. The testimony earns its place not because the model said it, but because the measurements agree with it.

8. The architecture that falls out

The evidence supports a three-layer account of durable machine-usable domain knowledge, replacing the single-layer version this paper's own hypothesis started from:

1. The executable model — the repository, including its tests. Holds what the domain is and how it behaves, continuously validated, incapable of vagueness. This layer is reconstructable, and it is the semantic ground truth the other layers anchor to.
2. The intent ledger — decision records, pinning tests, status-marked designs, governed knowledge stores, audit trails. Holds why, why not, and which parts are on purpose. This layer is not reconstructable even in principle; it must be written, and every session that skips writing it taxes every session that follows.
3. The attention layer — system maps, indexes, curated activity scopes. Holds where to look. It converts reconstruction from a context-window fantasy into a practical act, and it is cheap relative to what it unlocks.

Against this account, the familiar techniques find their true altitude. Prompts specify intent for a single request — they were never going to carry a domain. Retrieval delivers passages, not models; it works dramatically better when what it retrieves is layer-2 ledger entries anchored to layer-1 code. Agent frameworks and tool protocols multiply whatever domain understanding exists beneath them, including zero. None of these are wrong. They are all above the layer where the problem lives.

One further consequence deserves emphasis. If repositories are read by theory-reconstructing readers, then writing software is now, whether intended or not, an act of knowledge engineering. Conceptual clarity in code — honest names, abstractions that carve the domain at its joints, tests that state their reasons — stops being craftsmanship for its own sake and becomes measurable infrastructure for every future intelligence, human or artificial, that will operate the system. The converse also holds: a repository of expedient hacks teaches its future operators an expedient theory.

9. Testable predictions

The account makes falsifiable predictions. Two already have evidence in this system; the rest are open.

1. Domain-expressive repositories outperform implementation-dominated ones as foundations for AI reasoning, at equal task and equal model. (Supported here: the AI layer's parity with hand-curated expert output, and its transfer behavior across estates, tracked the domain-expressiveness of the subsystems involved.)
2. Improving conceptual clarity improves later AI performance even when behavior is unchanged. Refactors, renames, and test-docstring rationale should pay measurable dividends in downstream agent success rates. (Supported here anecdotally; deserves controlled measurement.)
3. At equal code quality, repositories whose tests pin intent — not just behavior — will resist AI-introduced regressions better than behaviorally-tested ones. The pinning test is the mechanism; this is directly experimentable.
4. Organizations with mature domain software need less prompt engineering per task, but the saving is bought with a curation layer — attention maps and an intent ledger — whose cost is real, front-loaded, and roughly an order of magnitude smaller than the code it leverages. (In the system reported here: ~1:10 by volume.)
5. AI-authored configuration that carries mandatory decision records will be re-derivable and transferable across environments in a way that bare configuration is not — because the record preserves the concept-to-surface binding that Section 4's transfer failure showed is the estate-specific part.

10. Related work

The classical literature splits into three strands that map exactly onto the three layers of Section 8 — which is itself evidence the layering is real.

The first strand says code can carry the domain. Evans' Domain-Driven Design is its discipline: "the intimate link between the model and the implementation" is what lets "the code be interpreted based on understanding the model," and the ubiquitous language is, in the present framing, an instruction to maximize the theory recoverable from the text.² Soloway and Ehrlich supplied the empirical mechanism: expert comprehension rides on stereotyped "programming plans," and collapses when code violates them — recoverability is conditional on convention, which is precisely why conceptual clarity is infrastructure.³ Knuth's literate programming was the same diagnosis with a remedy that never scaled.⁴

The second strand documented humans doing the reconstruction this paper attributes to models. Brooks described comprehension as rebuilding the chain of knowledge domains "which bridge between the original problem and the final program"; Letovsky recorded programmers as opportunistic processors whose central activity is conjecturing answers to "why" questions the code does not answer; von Mayrhauser and Vans formalized the switching between a domain model, a program model, and a situation model.⁵ Domain reconstruction, in other words, is not a speculative capability — it is the well-documented core of expert practice, now performed by a reader with different economics.

The third strand marks the residue. Naur held it irrecoverable in principle.¹ Parnas and Clements were more constructive: since no real design process is rational, "we can fake it" — produce the documents "we would have produced if we had done things the ideal way" — an explicit admission that even good documentation is an idealized rationalization rather than the actual reasoning history, and an argument that it is worth writing anyway.⁶ The design-rationale tradition (gIBIS, and the Moran–Carroll synthesis) built systems on the premise that rationale must be captured at decision time because it cannot be recovered from the artifact later — and then largely failed in practice on capture cost.⁷ The intent ledger of Section 6 is that tradition's premise revived under new economics: when the author of both code and rationale is a model, and writing the decision record is a required canonical step rather than an interruption to flow, the capture cost that killed design rationale approaches zero.

On the machine side, the mechanism claim has direct laboratory support: a transformer trained only on Othello move sequences spontaneously computes the board state internally, and interventions on that internal representation change its play — sequence models reconstruct the generating process behind their data, and a repository is an unusually explicit generating artifact for a business domain.⁸ The boundary has equally direct support: Vafa et al. show that generative models which ace next-token evaluations can hold incoherent implicit world models that fracture under task shift — the laboratory version of our Section 4 transfer failure, and the reason "partially" must stay in the thesis.⁹ Repository-scale evidence points the same two ways. Models now resolve real issues in large multi-file repositories, but cross-file benchmarks show the repo-level conceptual graph is not held spontaneously — performance collapses without supplied cross-file context and recovers with it — and a portion of headline benchmark success has been shown to be memorization of famous repositories rather than on-the-fly modeling.¹⁰ Meanwhile, LLM systems demonstrably can externalize a repository's latent model when pointed at the task: generating preferred-over-human documentation from dependency structure, recovering user stories and even formal, checkable specifications from unannotated code.¹¹ Most telling is a convergence: the systems that actually work at scale — a non-agentic pipeline whose curated repository representation beat autonomous agents; graph-based RAG built because vector retrieval "fails on global questions"; repo maps and steering files in production coding agents — have all independently invented an explicit intermediate model of the corpus.¹² Domain reconstruction is already an architectural layer in every successful system; it has simply not been named. Finally, the counter-position deserves direct engagement: Goedecke, applying Naur to coding agents, argues the theory lives irretrievably outside the text and agents must rebuild it from scratch each session.¹³ This paper is the rebuttal in two parts: mature, domain-expressive code carries more of the theory than Naur could observe, and the genuinely extra-textual remainder is not irretrievable — it is unwritten, and the intent ledger is where you write it.

11. Conclusion

The context race treats the model's ignorance as a delivery problem. This paper's evidence says it is a representation problem, and that the best representation most organizations will ever own is one they have already paid for: their software — the one description of their operation that must be true, because it runs.

A model given that representation does not merely answer better. It recognizes. It transfers. It refuses. In one measured case it reproduced weeks of expert judgment byte-for-byte, and in its most telling moment it declined to classify what the evidence could not support — a discipline no prompt taught it, inherited from a codebase in which unsupported conclusions have no representation.

But the same evidence draws a hard boundary. The repository holds the mechanism; it is structurally incapable of holding the intent. Every organization operating AI against its own systems will discover this boundary the same way — a model confidently "fixing" a decision — and the remedy is not better prompting. It is the intent ledger: decisions recorded with their evidence, tests that pin their reasons, prose that declares what is real. The audit trail, built for the regulator, turns out to be built for the successor — and the successor, increasingly, is a model.

Software, on this account, was never just implementation. It is the medium in which an organization's operational theory is accumulated, executed, and — now, for the first time — read back. Build the code so the theory is in it. Write down the parts that can't be. Everything else in enterprise AI is leverage on those two acts.