Codification

Type: types/definition.md · Tags: learning-theory, constraining

Replacing an LLM slug generator with python-slugify, or turning the allowed values of a frontmatter field into a schema enum, moves a rule from text a model reads into an artifact whose consumer is held to a reference. That move is codification.

Codification moves a rule or operation stated in natural language into symbolic form: into an artifact, such as code or a schema, in a language that has a formal semantics or is close to one. Fixed rules, implemented by a runtime, parser, validator, type checker, query engine, resolver, or adopted model package, determine what behavior is permitted, including any variation, external selection, or clarification step the rules explicitly provide for. The consumer changes from a model or human who reinterprets the text on each use to one bound by those rules, so what the artifact permits no longer depends on who reads it.

Codification is the symbolic region of constraining, committing choices that narrow or rank permitted readings or behaviors. Making natural language more precise also constrains interpretation, but remains outside codification until the language's users hold consumers to a reference that settles what the result permits.

Criterion

A route table and its resolver pass the criterion. A policy that says "escalate serious incidents", read by whoever is on call, does not, however precise its wording, because no reference settles what it permits. The criterion is the one that symbolic form states: the artifact's language has a formal semantics or is close to one. Here, close means its users hold consumers to a reference (a standard or an implementation) from which a formal semantics could be derived.

The C11 committee draft N1570, §§3.4.1–3.4.4, provides alternatives for unspecified behavior, requires each implementation to document how implementation-defined choices are made, and imposes no requirements for undefined behavior. An ambiguous passage in the standard settles nothing. What the reference leaves open is permitted variation, a required external selection, an excluded guarantee, or a defect, and only the last is a failure of the reference. An artifact whose consequences no reference fixes is reinterpreted on each consumption, and two readings of it can both be reasonable. Execution can still fail: implementations can have bugs, and natural-language interpreters can also violate unambiguous instructions.

Codification can include declared clarification steps. These are part of execution, not revisions to the governing rules.

The move into symbolic form is made in one of two ways. Rewriting a prose checklist as a Python validator is the usual way: the artifact is rewritten in a language that meets the criterion. Pinning a model version with its decoding procedure and treating the package's output as what the prompt means is the other: a consumer is adopted as the reference for an operation. The text does not change, but its form under that consumption path does. The adopting system is then a user of the language of prompts as that package reads them. It treats the package's behavior as what those prompts mean.

As symbolic form states, a formalization of a consumer is not the semantics of the language it reads. Adopting a frozen model therefore codifies the operation it is adopted for and leaves the semantics of English untouched.

A codified artifact can be opaque, in the sense symbolic form gives the modifier: a large codebase from its scale, an adopted model package from the form of its reference. Opacity sets how the artifact is checked and where it is revised. An opaque codification loses the advantages that reading gives, keeps what membership gives, and is still a codification.

The clerk and testing

Turing derived the formal machine by asking what a human computer, the clerk, can do when following exact instructions without insight (Church–Turing). That is why a formal semantics can be derived from a reference whose every step of application is mechanically checkable, and why designating a judge does not supply one. A human following a formal procedure is the clerk. A reference settled by unformalized judgment lacks the procedure, not a machine. A protocol that takes a human decision as an input formalizes the step as an external selection without formalizing the judgment. The clerk explains derivability and does not appear in the criterion. The condition applies to the steps. Deciding every consequence of the reference is a stronger claim and is often false.

Independent implementations and conformance tests corroborate conformance to the reference by trying to reveal disagreements about what it permits. Agreement alone is insufficient: clerks can share an assumption, compilers can share a bug, and a test suite can miss both. The reference must specify what is permitted independently of the observed agreement. A disagreement may reveal an implementation bug or a defect in the reference; repairing a defect fixes a previously unsettled choice. Testing does not prove conformance outside the tested cases.

A lone implementation can serve as the reference once its users hold consumers to it, but its repeatability alone does not show that another consumer could preserve the same rules. An artifact written in a language with independently tested semantics inherits that support within the tested scope.

Not all English passes the clerk. The fragment that does, once its users hold consumers to a reference, is a programming language in the making. Where instructions still require judgment to settle what is permitted, they remain natural-language constraining: two readings can both be reasonable, and no reference settles the disagreement. The boundary concerns the rules supplied for the operation, not a claim that no fragment of natural language can have a formal semantics.

Terminology

This definition is the KB's internal technical use of the word. It is narrower than ordinary "codification," which can mean putting norms into systematic written form, including legal codes, formal policies, or other precise prose. The programming-language term operational semantics (Plotkin) and operationalism's definition of a concept by measurement (operationalism) are not used here; the vocabulary collision ledger records the senses.

Scope

Use the term when a rule or operation has been committed to a symbolic artifact: code, scripts, schemas, validators, tests, parsers, route tables, grammars, type declarations, query expressions, or other artifacts whose language has a formal semantics or is close to one, instead of a model reinterpreting them on each use.

Examples: replacing an LLM slug generator with python-slugify; moving CSV statistics from LLM arithmetic to Python's statistics module; extracting mechanical frontmatter checks from a validation skill into a Python script; turning allowed frontmatter values into a schema enum; expressing a route decision as a table consumed by a resolver. Executable code is the main practical KB case because it inherits support from independently tested language semantics within the tested scope, and KB operations often need commands and validators.

Exclusions

Writing a convention that stays in natural language constrains interpretation while keeping the model or human as the interpreter. A skill extracted from methodology notes is not codification while its instructions remain natural language. This is because skills derive from methodology without changing representational form: how the content is encoded and consumed.

Turning a rule into legalese, a standards document, or a formal prose policy may be strong constraining while still depending on natural-language interpretation.

Structured Markdown, YAML, or JSON becomes codification only where a consumer holds fields, values, sections, or operations to a reference.

An exact numerical claim can be stated and tested in natural language; it needs symbolic form only when it must be settled by a reference, such as mechanically repeatable computation or acceptance.

Codified parts of a theory

A part of a retained theory that makes the move into symbolic form has consequences fixed by computation. A natural-language part's consequences depend on what its interpreter derives. A codified part's consequences are fixed by its reference. Codification alone does not supply diagnosis or successful repair. A failed check must be connected to the theory commitments it tests before it can guide candidate edits. Addressability makes parts available for inspection and separate revision; it does not guarantee that the identified part caused the failure or that the revision repairs it.

Codification and relaxing

Progressive constraining commits a pattern to code once observed runs show it is stable; committing a single LLM output instead fixes an arbitrary reading. How far codification can go depends on the available checks: hard oracles make it easier, weak oracles resist it. Every codification is a bet that the committed reading stays right. Relaxing reverses the codification when the reading turns out to be a wrong proxy, or when a more general component handles the case well enough.

Misuse Cases

  • Calling every clearer instruction "codified" even though the consumer is still an LLM interpreting natural language.
  • Calling legalistic or policy prose codified in this KB's technical sense just because it is formalized.
  • Calling a natural-language skill codified merely because it has frontmatter. The frontmatter may be symbolic, but the instructions that guide behavior can still be natural-language.
  • Treating agreement among consumers, or repeatability from one consumer, as sufficient for codification. The consumers must be held to a reference that settles what is permitted independently of that agreement.
  • Denying that adopting a pinned model codifies the instructions it reads. It does; the codification is opaque, which is why it loses the advantages that reading gives.
  • Treating a wrong output of an adopted package as a defect in the reference. The package specifies the output; whether it satisfies the requirement is the adequacy question, which codification leaves separate.
  • Treating only executable code as codification. Schemas, grammars, tables, and other symbolic artifacts also codify when their users hold consumers to a reference.
  • Treating a codified check as a codified requirement. A validator excludes readings only within the predicate it checks; when that predicate is a proxy, the requirement itself remains interpreted.

Relevant Notes: