Series
Encode the System
An arc moving from manifesto toward conclusion: programming is not merely writing code, it is encoding guarantees into systems.
5 of 8 articles available
The series
Build Systems, Don't Polish Prose
We still talk about code as if it were style. But code runs in the world.
Why the implicit becomes fragile when humans and agents co-produce code.
Make Feedback Loops Attribute, Don't Just Detect
Why feedback loops become more powerful when code makes its system concepts explicit.
Enforce Architecture, Don't Trust Intent
Why load-bearing architecture rules must become executable checks rather than trusted intent.
Prove and Admit, Don't Just Lint
Why executable rules are the easy half, and why the checks around agent-written code must require presence, report their blind spots, and be written as a standard rather than collected as rules.
Build Guarantees, Don't Chase Bugs
Why the goal is not fixing bugs faster but encoding guarantees that make whole classes of bugs impossible, rare, or visible.
Structure Domain, Don't Scatter Rules
Why domain invariants belong in domain structures, not in rules scattered across code paths.
Encode Guarantees, Don't Just Write Code
The series' conclusion: programming is the art of deciding which truths to make unbreakable, where, and at what cost.
Series glossary
The concepts used across the essays. Each definition describes what the term means inside this series.
- Abstraction
A representation that hides some details so attention can remain on the concepts that matter.
Central in article 2- Adapter
A thin layer translating between an external technology and the model or contract used by the system.
Central in articles 2, 3- Architectural fitness function
An automated check that continuously evaluates whether a system still satisfies an architectural property.
Central in article 3- Attribution
Identifying which rule, state, boundary, or responsibility produced the problem.
Central in article 3- Authority
The part of the system allowed to decide or perform an operation.
Central in article 1- Baseline
The recorded set of existing violations that a rule accepts when it is introduced, so that only new drift fails. The ratchet that makes enforcement survivable in a real codebase.
Central in article 4- Black-box test
A test that verifies observable behavior without depending on internal implementation details.
Central in article 3- Boundary
A point separating zones with different responsibilities, levels of trust, or kinds of behavior.
Central in articles 1, 2, 3- Cognitive portability
The ability to recognize the same conceptual structure across different languages, frameworks, or implementations.
Central in article 2- Colocation
Placing related pieces of code near one another, even when they belong to different runtime or architectural zones.
Central in article 2- Contract
An explicit statement of what may enter or leave a boundary and what each side guarantees.
Central in articles 1, 3- Correlation ID
An identifier used to connect logs, events, and calls belonging to the same operation.
Central in articles 1, 3- Coverage complement
What a standard reports instead of a coverage number: for each declared guarantee on each change, proved present, proved absent, or not looked at. The last state is where a reviewer's attention should go.
Central in article 5- Detection
Establishing that something is wrong.
Central in article 3- Deterministic transformation
A transformation that always produces the same result from the same explicit inputs.
Central in article 1- Discriminated union
A type representing a finite set of alternatives, each identified by a common distinguishing field.
Central in articles 2, 3- Disposition matrix
A complete table classifying the meaning of every event in every possible state.
Central in article 3- Domain event
A named record that something meaningful happened in the domain or system model.
Central in article 3- Domain structure
A shape of the domain model that carries its invariants together as consequences rather than rules: the ledger for money, the movement journal for stock, the reservation calendar for bookings. Borrowed when the world has debugged one, composed when it has not.
Example: A balance is not a mutable field but a fold over a ledger's entries; no code path can forget the invariant.
- Drift
The gradual divergence of code or behavior from the structure the system was intended to preserve.
Central in articles 2, 3- Executable standard
An engineer's description of what "right" means for a codebase, written once, outside the application, and made into the thing that judges every change. Not a framework (you are measured against it), not a harness (it does not run your agent), not a linter (it proves and admits rather than finds).
Central in article 5- Exhaustiveness
A guarantee that every possible case has been considered and handled.
Central in articles 1, 3- Explicit
A concept represented in a visible, named, and inspectable form.
Central in articles 2, 3- Explicit state
A named situation the system can occupy, represented directly rather than inferred from scattered conditions.
Central in articles 1, 2, 3- Feedback loop
A mechanism that observes the result of a change and returns information that guides the next correction.
Central in article 3- Form and fit
The two judges of a system. Form is the model's coherence as software (boundaries held, states legal, contracts kept) and is verified by tools. Fit is the model's truth to the world and is only validated by reality. Perfect form on a wrong model is the impeccable wrong system.
- Grade
How much a proved cell of the coverage map actually proves: a proved form (a schema is there and strict), never a proved meaning (the schema is the right one). Substance stays with the domain owner.
Example: A strict schema that accepts a negative price passes: the form is proved, the meaning is not.
Central in article 5- Guarantee ladder
The stages a guarantee climbs out of people's heads and into the system: intention, declared constraint, encoded guarantee, verified guarantee. Most of what a seasoned team knows is stuck at the first stage; a bug fix is the moment to climb the last two.
- Guarantee level
How strongly a property is held: impossible (by construction, the violation cannot be written), rare (checked at a boundary or in CI), visible (watched, seen on first occurrence), or hoped (held by nothing, the default). The discipline is to place each property deliberately and to know where it sits.
Example: An order total: impossible inside the typed core, rare at the API schema, visible in the reconciliation job.
- Guarantee system
The composition of mechanisms (type checker, boundary schemas, contracts, property tests, audits, traces) that re-asks on every change whether the system's guarantees still hold. Not a test suite: an environment. Every guarantee in it is executable, every failure attributed.
- Idempotency
The property that repeating the same operation does not produce additional unintended effects.
Central in article 1- Implicit
Information required to understand the system but not directly represented in the code being read.
Central in articles 2, 3- Invariant
A condition that must remain true throughout the relevant life of the system.
Example: A paid order cannot return to the pending-payment state.
Central in articles 1, 3- Invisible dependency
Knowledge on which the code depends even though that dependency is not represented or enforced.
Central in article 2- Local feedback
Fast checks concerned with the code immediately being changed, such as types, compilation, and nearby tests.
Central in article 3- Obligation
A rule that requires a presence, so that its violation is an absence: every port must have a wired adapter, every reachable handler must validate its input. Detecting it needs a model of the required shape, and it is only decidable once the scope it governs is complete.
Example: A handler that is written but never registered passes its unit tests; only an obligation sees the hole.
Central in articles 4, 5- Observability
The ability to reconstruct what a running system did, in which context, and why.
Central in articles 1, 3- Probabilistic machine
A system that generates likely outputs rather than following one uniquely determined continuation.
Central in article 2- Production-like feedback
Checks of critical behavior under conditions resembling real execution.
Central in article 3- Prohibition
A rule that forbids a presence: this edge must not exist, this layer must not be imported here. Its violation is a concrete site, and it is wrong the instant it appears, so it can be checked at every step.
Example: `domain/**` must not import `infrastructure/**`.
Central in articles 4, 5- Property-based testing
A testing approach that verifies general properties across many automatically generated inputs instead of relying only on manually selected examples.
Central in article 3- Proxy rule
A rule that checks a cheap stand-in for a concept (where a file lives) rather than the concept itself (who owns a responsibility). Useful, and gameable: satisfied in the letter while the concept is still violated.
Example: Moving a product-specific component into `ui/` turns the folder rule green while the component still imports product hooks.
Central in article 4- Pure function
A function whose result depends only on its inputs and which does not modify external state.
Central in articles 1, 3- Responsibility
The part of the system responsible for ensuring that an operation is accomplished.
Central in articles 1, 2, 3- Robustness
The capacity of a system to remain understandable, withstand deviations, and reveal what happens when it runs.
Central in article 1- Scattered rule
A domain invariant that exists only as the intersection of the local disciplines of every code path that could violate it, so it is written N times, slightly differently, and the N+1th path is one forgotten check away from drift.
Example: Six code paths that each check, in their own way, that a balance stays sane.
- Scope closure
The moment a scope is declared complete, after which an obligation on it can be judged without false reds. Prohibitions are checked at every step; obligations at closure. Standalone, on a pull request, every scope is closed; inside an agent's loop, the harness says when.
Central in article 5- Seat
The single, statically findable place where a guarantee attaches: the input validator of a server function, the validators of a form, the constructor of a domain type. An obligation is decidable only where there is a seat.
Example: `createServerFn().inputValidator(schema)`: one place to look for the contract of that function.
Central in article 5- Side effect
An interaction with something outside a local computation, such as a database, network, file, clock, or device.
Central in articles 1, 2- Snapshot
An immutable representation of the system state at a particular moment.
Central in article 2- State machine
A model that names possible states, accepted events, and allowed transitions between them.
Central in articles 1, 2, 3- Structural feedback
Checks that verify whether architectural boundaries, dependencies, and responsibilities still hold.
Central in article 3- Trace
A connected record of the steps taken by an operation across the system.
Central in articles 1, 3- Verification surface
The explicit forms in a system that tools and reviewers can inspect and check.
Central in article 3- ViewModel
A representation prepared for a user interface that exposes the state and actions the view needs without embedding domain behavior in the view.
Central in article 2- Witnessed fact
A domain fact that records something that happened in the world (a payment captured, a consent given, an approval granted) rather than a value computed from the system. Append-only, attributed, corrected only by compensation; a missing one must never be silently repaired by automation.