待翻譯：Software as Executable Domain Knowledge

AI 服務暫時不可用，以下為來源正文，待恢復後補全翻譯。

← Papers Whitepaper Software as Executable Domain Knowledge 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 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.1 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: 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. 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. 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 m [truncated for AI cost control]