The task that disappears

A reservation page can pass a collection of page checks while a visitor still cannot reserve a book. The missing piece is often not another check. It is a precise statement of the task those checks are supposed to protect.

The Library reservation journey is fictional. It stands in for one critical web task and contains no real people, institution, or outcome. Its local practice page supplies a no-code case; results from it are not conformance evidence.

The anchor course introduced a harness as a repeatable set of checks with evidence and a consequence. Here the first input to that harness is not a selector or screenshot. It is the promise that a person must still be able to complete.

A page-level PASS can hide a broken task

Suppose search renders, the book detail has a heading, and the Reserve button exists. Those observations say nothing about whether sign-in returns the visitor to the same book or whether confirmation appears. Checking pages independently loses the thread that joins them. A journey contract restores that thread by stating one user goal and the ordered states that make it complete.

Do not begin with every possible behavior. Choose one critical journey and write its finish line in ordinary language. For the fictional Library reservation journey, the goal is: “reserve an available book and receive an unambiguous confirmation.” Search, detail, sign-in when required, reservation, and confirmation are states in support of that goal. They are not five unrelated mini-tests.

Turn the promise into inspectable clauses

The runnable contract has six top-level fields, not four. journey is the short name of the fictional task. user_goal says what the visitor is trying to finish. steps is a non-empty ordered list of states that must remain possible. owner names the role that resolves missing or disputed evidence. release_evidence names the one record that supports this contract. practice_packet carries the observation you made on the local practice surface.

The practice packet is deliberately small: state identifies one visible journey state; method says how you inspected it; observation says what happened; decision is exactly PROMOTE or HOLD; and limit says what that observation cannot establish. This is a small document, not a full requirements archive. Empty values and template wording such as “replace with” remain HOLD, because they do not describe an observation.

The packet's limit prevents a narrow record from expanding into a broad promise. A recorded confirmation can support the claim that the included scripted path reached confirmation. It cannot establish that every person can use the journey, that every device behaves the same way, or that a standard has been met.

Worked example: contract plus practice packet

The Library reservation contract names the fictional journey and user goal, then lists “search catalogue,” “open an available title,” “sign in if prompted,” and “confirm reservation.” Its release evidence is a completed-path capture. The owner is “release reviewer,” a role rather than a private identity. The practice packet records one state from the local surface: a keyboard walk at 320 CSS px returned focus to the Reserve control. Its decision stays HOLD because that synthetic local observation is not assistive-technology or user evidence.

Now remove the packet's observation. Search and detail records may still be green, but the contract is incomplete. The correct response is HOLD: the stated rule requires a concrete practice record as well as the journey clauses. HOLD does not prove that confirmation is broken. It says the record cannot yet support advancement.

contract = {
    "journey": "library reservation",
    "user_goal": "reserve an available book",
    "steps": ["search", "detail", "sign_in", "confirmation"],
    "owner": "release reviewer",
    "release_evidence": "completed-path capture",
    "practice_packet": {
        "state": "confirmation dialog",
        "method": "keyboard walk at 320 CSS px",
        "observation": "focus returns to Reserve this book",
        "decision": "HOLD",
        "limit": "synthetic local practice is not AT or user evidence"
    }
}
verdict = "PASS" if all(contract.values()) else "HOLD"

Counterexample: inventory is not a contract

“Search page, detail page, account page” looks tidy, but it names screens rather than the visitor’s task. It omits the required return after sign-in and says neither what evidence matters nor who resolves a gap. A checker could mark all three pages present while the reservation path still dead-ends.

The repair is not to add more page names. Rewrite the list around a verb and an observable finish: reserve one available book; finish when a confirmation identifies the book and the reservation state. Then connect every intermediate state to that finish. This gives later checks a shared object instead of eight isolated notions of quality.

Interpret before you decide

A PASS from the contract checker means the fictional record contains the six required fields and the packet's five concrete fields. It supports the decision to continue collecting evidence. It does not mean the journey works. A HOLD points to an absent journey label, goal, step, owner, release-evidence field, or practice-packet field; the owner must repair or explicitly revise the contract before the release record can reconcile it.

Your turn: challenge the record

Write a one-sentence goal for another familiar journey, such as changing a delivery address. List the few states without which the goal is unfinished. For one state, name the record you would accept and one conclusion that record cannot support.