A model writes code that compiles, passes the tests you wrote, and ships. Months later it leaks memory, or a security regression surfaces, or an API it imported never existed. The usual diagnosis is hallucination or a small context window. The real cause is in the representation. The Lattice Coder pattern is a name for that diagnosis and its fix: gate generated code against a registry of named rules, and refuse with a citation.
Dense vector embeddings capture distributional similarity. They do not preserve the positional structure that carries meaning in low-entropy artifacts like code. Averaging distinct structural boundaries into one vector produces a centroid that is syntactically flawless and violates a specific, load-bearing invariant. Scaling, RLHF, and prompt engineering do not repair this, because the relevant information was discarded at the representation step, before generation began.
This is measurable. On a 32-syllable lattice with exactly two coherent readings out of 1,080, text embeddings rank a coherent artifact as more similar to randomly sampled gibberish (0.9810) than to its one true companion (0.9718). A representation that summarizes by distributional features cannot preserve information that lives in position.
The same function has several simultaneously-legitimate readings under different paradigm lenses. It can be correct as an object-oriented lifecycle and catastrophically wrong as a security-model annotation, because the caller controls an input that crosses a trust boundary. Each reading is a valid projection of the code, bounded by a formal frame: the type system, the memory model, the specification, the threat model. A security reviewer queries one projection; a performance engineer queries another. Monosemy-by-default is a professional self-image, not a description of how code actually means.
Current assistants collapse this. They produce one opinion derived from dense retrieval over a training corpus, without surfacing which reading the generated code passes under and which it fails. The collapse is invisible because the output looks right, and the wrongness is found downstream, during an incident or an audit.
Take the OpenSSL heartbeat function (CVE-2014-0160). Read it through five paradigm projections: object-oriented scores it 0.78, functional 0.64, performance 0.58, acceptable. Dataflow scores it 0.12 and security 0.08, both flagging a length field the client controls reaching a memory copy with no bounds-check (CWE-125, RFC 6520 §4). A dense embedding averages this three-against-two split into “mostly fine, some concerns,” and a model writes the same code. The bug lived in production for roughly two years.
A verifier that keeps the projections apart surfaces dataflow.fitness = 0.12 and halts, with the exact
citation. The exposure window closes at compile time rather than at disclosure.
We tested this on the real OpenSSL 1.0.1f tree, with no hardcoded "bounds-check before memcpy" rule. The method
is short. Find every site where a length from the network reaches a risky use, where the security reading is in
play. Then ask whether that length is bounds-checked. Not against our opinion, but against what the codebase does
elsewhere. OpenSSL bounds-checks those lengths at 38 of 43 sites (88%). That consistency is
the requirement; it was never written down. The 5 gaps are the uneven application, and both
Heartbleed functions: the TLS heartbeat (t1_lib.c) and its DTLS twin (d1_both.c)
fall out as gaps. The bug is not a missing rule. It is the uneven use of a rule the codebase otherwise keeps.
The verifier reads the rule from the code and flags the one place it breaks.
The pattern has three parts.
Not every task needs this. The Entropy Requirement Rating routes work by how much precision it demands. High-entropy work (free prose, brainstorming, ordinary code) goes to an unconstrained model; fluency suffices. Medium-entropy work (structured documents, typed code, clinical notes) adds schema validation. Low-entropy work (security-critical code, strict contracts, multi-specialty diagnosis) routes through the registry-verified path, where a single averaged opinion is not acceptable. That low-entropy tier is the regulated tier, and it is where determinism stops being a preference and becomes a requirement (SR 26-2).
A donkey (a deterministic check that runs against generated code) does the gating. The code donkey at code.doloop.io is the core of this pattern: the layer that gates code against the rule registry and refuses with a citation. The full treatment is in the Lattice Coder and Sūtrakṛt papers.