A5.1.2 · dive 2/3
Every reference exact
A reference that resolves to one reading is a contract; a reference that resolves to two is a decision the brief handed the agent by omission.
A5.1.1 put the links first. This dive sharpens the links themselves: name each source precisely enough that the agent reads the one right thing, not an approximation. Turn the dial on the right to watch one reference resolve from "the facade" to a function pinned to its exact return shape.
One reference, three phrasings · turn the precision dial
What an exact reference is
A5.1.1 settled the order: links first, the agent reads the sources before any narrative. This dive
settles the links. A reference is exact when it names its target to a precision that admits
one reading. “The facade” names a thing that could be any of several. “The
Portal facade” narrows it to one module. Portal.courses_of/1
:: {:ok, [%Enrollment{}]} pins the function, its arity, and its return shape, so there is nothing left
for the agent to choose.
The cost of a loose reference is not that the agent fails — it is that the agent improvises. Faced with two readings, it picks one, and the pick is a decision the brief was supposed to make. An exact reference removes the pick. The agent reads the one right thing and builds it; a loose one hands it a fork and hopes it chooses the branch the spec intended.
- exact reference
- A source named to a precision that admits one reading: the module, the function, the arity, the return shape — whatever it takes to leave nothing to choose.
- ambiguity
- The number of readings a reference admits, minus one. Zero is a contract; one or more is a fork the agent has to pick.
- improvise
- What an agent does at a fork the brief failed to close: it picks a reading, and the pick is an unwritten decision.
- pinned signature
- A reference that names a function with its arity and its return shape, e.g.
courses_of/1 :: {:ok, [%Enrollment{}]}— the most exact form a function reference takes.
An exact reference and a loose one cost the same to write. The difference is paid later, once, by whoever reviews what the agent built against what the brief meant.
The contract reference, named exactly
The Portal's real agent brief, f6.1.llms.md, carries one reference that is also a
constraint — the upstream facade contract. It is the example to study, because it is named to a
precision the agent cannot misread. Quoted verbatim from the brief's ## References
block:
## References # Upstream contract (do not modify). The Portal facade — query # courses_of/1 :: {:ok, [%Enrollment{}]} (as-built and total / success-only: # the wrapped list, no bare-list arm, and no {:error, %Portal.Error{}} producer — # an unknown or malformed user id yields {:ok, []}). The controller still # pattern-matches the {:error, %Portal.Error{} = e} arm defensively, so the 422 # render path exists and is unit-testable. And the closed error set # %Portal.Error{code, message, field} with code in # :already_enrolled | :course_not_found | :lesson_locked | :invalid_progress.
Read what the reference pins: the function (courses_of/1), the success shape
({:ok, [%Enrollment{}]}, total / success-only), the defensive arm
({:error, %Portal.Error{} = e} → a 422 render), and the
closed code set. Requirement F6.1-R4 reads exactly this and
builds the controller's two arms — the success list and the 422 error render
— without inventing a third shape. The same contract is the controller's reference on the companion
course: see the controller lifecycle for how the call is
wired.
Now strip the contract to “render the user's courses, handle errors.” The function arity is gone,
the return shape is gone, the error set is gone. The agent can still build the success arm — a list is a
list — but the error arm has no shape to render and no closed set to match. It invents a
%Portal.Error{} with fields that do not exist, or drops the arm. The interactive
below counts the arms an agent can build at each level of precision.
Which arm does the agent build · switch how the contract is named
%Portal.Error{} set, so both arms have a shape to render.An exact reference is a contract; a loose one is an invitation to improvise.
On the Portal
The lesson lands on the Portal's real controller rung. The brief reference pins
courses_of/1 to its exact return shape and the closed
%Portal.Error{code, message, field} set; the controller reads it and renders, never
guesses. The success tuple yields the index render; the defensive error tuple yields the
422 render of a struct whose fields are named, not invented. Because the reference is
exact, the two arms are a transcription, not a design problem.
# f6.1.llms.md References — the exact contract the controller reads: # courses_of/1 :: {:ok, [%Enrollment{}]} (total / success-only) # closed set: %Portal.Error{code, message, field}, code ∈ {:already_enrolled, ...} # F6.1-R4 transcribes the two named arms — nothing invented. def index(conn, %{"user_id" => user_id}) do case Portal.courses_of(user_id) do {:ok, courses} -> render(conn, :index, courses: courses) {:error, %Portal.Error{} = e} -> conn |> put_status(422) |> render(:error, error: e) end end
The principle
Name each source precisely enough that the agent reads the one right thing. An exact reference admits one reading; a loose one admits several, and the agent has to pick — a decision the brief failed to make.
On the Portal
f6.1.llms.md pins courses_of/1 to its exact return shape
and the closed %Portal.Error{} set, so the controller renders the success list and
the 422 error — never a guessed third shape.
An exact reference is a contract; a loose one is an invitation to improvise.
Recap — precise enough to read once
Links first put the sources before the prose; exact references make those sources unambiguous. A reference is
exact when it admits one reading — the function, its arity, its return shape, the closed error set
— so the agent reads the one right thing and transcribes it. The Portal's
f6.1.llms.md pins its facade contract this way, and the controller builds both arms
without inventing a third. The closing dive collects the order and the precision into one form: the shape a
whole machine brief takes.
Next in A5.1: A5.1.3 · The shape of a machine brief — the
llms.txt form: a links block, then the parts an agent acts on, the narrative removed.
References
Primary sources for writing a reference an agent reads once, and where it connects in the course.
Sources
- Howard, J. — The
llms.txtconvention — a brief written for a machine reader: exact links, no approximation. - Anthropic — Building effective agents — clear, explicit tool and reference specifications over leaving the agent to infer.
- Hunt, A. & Thomas, D. — The Pragmatic Programmer — design by contract: a precise interface admits one reading.
Related in this course
- A5.1 · Writing for an agent: the llms.txt convention — the module hub.
- A5.1.1 · Links first — the order this dive sharpens.
- A5.1.3 · The shape of a machine brief — the closing dive.
- Phoenix · The request lifecycle — the companion course where this facade contract is built.
- A5 · The agent brief — the chapter.