The unit is a contract

Design by Contract — Meyer's principle, born in Eiffel — specifies a routine by three obligations. A precondition the caller must meet for the routine to run; a postcondition the routine guarantees in return; and an invariant that holds before and after every call, on every path. State those three, and the routine is specified — not described, specified.

The agent-era reading is sharper than the original. The contract is the acceptance criterion. A diff that satisfies the contract is acceptable; one that does not is rejected by the named clause it broke. That verdict is reachable at the boundary — from the contract alone — so you do not re-read the implementation to render it. An agent need not handle the impossible: if the precondition is unmet, the routine refuses, and the case is out of scope by construction.

Once a unit has a contract, acceptance stops being a reading exercise and becomes an evaluation. You do not re-read the agent's diff line by line to decide whether to take it; you check the diff against the contract. Each clause is a gate the work passes or fails, and the verdict carries the reason: the first clause that does not hold names exactly why the work is rejected.

Model an agent's submitted output below. The slider is the produced id's length — the contract requires exactly 14. The two toggles are the other guarantees: does the id decode back to the type, and is it unique within a node-millisecond. The contract accepts only when every clause holds; otherwise it rejects, and names the first failing clause.

Take one unit on the Portal — the learning platform this course builds — and write its contract. The branded id has exactly three clauses. Precondition: the namespace is a known type (:user, :event, :lesson). Postcondition: the result is a 14-character TSK…-prefixed id that decode/1 maps back to that type. Invariant: ids are unique and monotonic within a node-millisecond — never two the same.

This is exactly the contract that made “generate one id” an acceptable thin slice back in A1.01.3: the slice carried its own acceptance. The contract names what to build and what to check, so the unit is the same precise thing whether an agent implements it or you accept it.

# The branded-id contract, stated as three clauses.
# PRE  : the namespace is a known type (:user | :event | :lesson)
id = Portal.ID.generate(:user)        # => "USR0NbAb1xcFCy"

# POST : 14-char TSK… id that decodes back to that type
assert byte_size(id) == 14
assert Portal.ID.decode(id).type == :user

# INV  : unique & monotonic within a node-millisecond — never two the same
next = Portal.ID.generate(:user)
refute next == id
assert Portal.ID.decode(next).timestamp >= Portal.ID.decode(id).timestamp

A diff that keeps every assertion green satisfies the contract and is acceptable; one that breaks an assertion is rejected by the clause it broke — a length that is not 14, a type that does not round-trip, a collision within the node-millisecond. The verdict is the failing clause, not a re-read of the routine.

A unit handed to an agent needs a contract: a precondition the caller meets, a postcondition the routine guarantees, an invariant that always holds. That triple is precise enough to implement against and precise enough to accept against, which is what moves acceptance from re-reading the diff to checking it against the named clauses. Knowledge has a home; a unit has a contract — two of three re-weighted principles down.

Primary sources for Design by Contract, and where the principle connects in the course.