LiteSpec

Agents meet unknowns in the middle of a task: an unknown access rule, an unclear retention limit, a missing recovery target. When the answer changes behavior, money, data, access, or recovery, only an accountable person can give it. Stopping and taking the question to that person keeps the choice visible instead of buried in code nobody stated. Accountable people decide outcomes, terms, policies, and criteria, and an agent contribution stays a proposal until one of them accepts it.

Reviewed forThe change report naming the unknown fact, the person asked, and the record carrying the answer.

Marked guidance: a reviewer answers this question.

A prompt, ticket, chat message, or code comment can start work, but none of them holds the stated behavior. Starting from the owning records keeps the agent building what the records state, and keeps the records as the lasting statement of what the code does. Without this rule, each task reinterprets intent from its starting message, and the records drift from the code until nobody trusts either.

Reviewed forThe change report listing the Intent and Behavior records the work started from.

Marked guidance: a reviewer answers this question.

The mark is the link from Implementation to Behavior and from Proof to the scenario it proves, in the two kinds the model page states: implements names the record served and follows names the choice followed. A folder or a type name only resembles the record, and a resemblance drifts with the next rename; a mark holds the identifier, so the checks, the analyzers and the editor follow the same link without guessing. One record per handler keeps each file answerable to one use case. Nothing above Implementation is computed from code, so the link points up and the records stay the authority.

The reimburse-expense handler carries a mark naming use-case/spending.reimburse-expense, the Reimburse method on the expense root carries the same mark, and the reminder event handler carries a mark naming reaction/spending.send-approver-reminder-on-expense-submitted.

Checked bylitespec model check reports mark-missing, mark-unknown and mark-count-invalid (check level S) for a code element with no mark, a mark naming no record of the type its element takes, or a handler marking other than one record.

Marked checkable: the tool named here checks it.

Every class in the outer layers exists for a record or for a reason. An input validator or a read model serves one use case, and a repository serves one aggregate, so each names that record in implements like the handler beside it. Code that serves no record still exists for a reason: a provision requires it, a technical decision chose it, or an exception allows it, and a follows mark names that reason by identifier. The named target is the reason for the shape the class carries, so review judges a follows mark by whether its target requires that shape. A reader asking why the command pipeline commits once, or why the repository stores documents, follows the link instead of guessing, and a check finds the code that still follows a deleted decision. A class may carry both kinds when it serves a record in a chosen way.

The Claimwick submit-expense validator carries /// <implements>use-case/spending.submit-expense</implements>. The receipt PDF renderer carries /// <follows>decision/0005-render-receipts-as-pdf</follows>, and the command pipeline's commit step carries /// <follows>litespec/backend/persistence#commit-each-command-pipeline-once</follows>.

Checked bylitespec model check reports mark-missing and mark-unknown (check level S), and dotnet build reports LS5001 and LS5002, for a technical class with no mark, an implements mark naming no Behavior record, or a follows mark naming no provision of the carried release, no decision or exception, or a provision on a page the project's stacks do not apply.

Marked checkable: the tool named here checks it.

The declared edges form the effect graph the checks verify: an undeclared edge is the defect, not the mechanism that carries it. The graph holds no cycles except through domain events with a stated end condition. An inline edge states whether it shares the caller's transaction, and atomic consistency spans no async edge. The behavior page states the edge fields, and the layers page states how Implementation is checked against them.

Checked bylitespec model check emits no effect-undeclared or effect-loop-invalid finding across use cases, reactions, jobs, notifications, and integration events, and reports effect-unimplemented (check level A) for a declared edge no code takes.

Marked checkable: the tool named here checks it.

A use case is done only when a caller can run it and operations can support it: behavior, storage, entry points, automated evidence, and operating impact together. Accepting a thinner slice leaves the missing parts for later, and later rarely itemizes what shipped half-built. Placeholder work leaves the use case unimplemented. Multi-step product outcomes belong to a journey rather than stretching one use case across several goals.

A use case without its tests and operating records is not complete.

Reviewed forThe use case page with its behavior, persistence, entry points, tests, and operating records present.

Marked guidance: a reviewer answers this question.

Records map to current names and paths only when each behavior change carries them along. A change that moves code but leaves the use case page, the tests, or the journey behind splits the project into stated fiction and unstated fact. Updating the records in the same change keeps the change to behavior and the change to its description in one place.

Reviewed forThe behavior change with its use case page, tests, product records, decision, journey, and operating records changed together.

Marked guidance: a reviewer answers this question.