Software as Executable Domain Knowledge — ServiceMatch whitepaper<br>← PapersWhitepaper<br>Software as Executable Domain Knowledge<br>A mature codebase is the highest-fidelity representation of a domain an organization owns, and an AI model can reconstruct the theory inside it. Evidence from a system built on that premise — including a byte-exact parity result, and testimony from the model that does the reconstructing.

1. The question underneath the context race

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

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

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

This paper asks a different question. What if the limiting factor is not<br>access to information, but access to a coherent conceptual model of the<br>domain — and what if most organizations already own one, in a form they<br>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<br>activity by which the programmers form or achieve a certain kind of<br>insight, a theory, of the matters at hand" — and that this theory, not<br>the program text, is the real artifact. His conclusion was severe: the<br>theory is "inextricably bound to human beings," and "program revival,<br>that is reestablishing the theory of a program merely from the<br>documentation, is strictly impossible." This, on Naur's account, is why<br>documentation never saves a dead project and why a team that loses its<br>people loses the program.1

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

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

So the claim, carefully stated:

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

The strong form of the claim — that the repository suffices — is<br>false, and Section 5 shows exactly where it breaks. The interesting<br>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<br>and governance platform: it ingests multi-source discovery data (MDM,<br>endpoint analytics, infrastructure monitoring, directory services),<br>resolves device identity across sources, classifies devices into CI<br>classes, cascades business-layer relationships, and gates what is allowed<br>to reach a ServiceNow instance. Its repository is, by now, a dense<br>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<br>what establishes device identity and you get an essay. Ask the<br>repository and you get DEFAULT_IDENTITY_WEIGHTS: serial number 25,<br>hostname 25, asset tag 25, IP address 20, MAC address 15, IMEI 25 for<br>mobile, platform-native identifiers 20 each — with thresholds that<br>partition the estate into HIGH (≥80), MEDIUM (≥50), and LOW confidence,<br>and named conflict types (one serial claiming many hostnames; one<br>hostname claiming many serials) that trigger review instead of merge.<br>This is not a description of a policy. It is the policy, executed<br>nightly against real estates, and every number in it is a fossilized<br>argument someone once won.

Provenance is a data structure. Every merged record carries<br>_field_sources...