Project Model

One home per type tells a reader where to open a record and tells the builder where to read it. A record kept anywhere else is invisible to the checks that scan its home, so it looks sound while nothing validates it.

A decision lives at .litespec/intent/decisions/0001-receipt-threshold.yaml.

Checked bylitespec model check reports folder-invalid for a folder outside the closed set of its layer and level, module-undeclared for a modules folder naming no declared module, and record-placement-invalid for a record outside its home.

Marked checkable: the tool named here checks it.

Type, identifier, and title are the fields every join needs. Without them on every record, the builder cannot connect decisions to requirements, scenarios to results, or records to terms, and the model falls apart into loose pages. A record adds terms when it uses glossary terms and records when it holds entries.

Checked bylitespec model check reports record-invalid for a record missing a common field.

Marked checkable: the tool named here checks it.

One file per page tells a reader where to open a record and tells the builder where to read it. The mapping holds exactly the fields the schema defines for its type, with entries in records, so every record has one shape and the checks read every record the same way. A record kept anywhere else is invisible to the checks that scan its home. Settled by decision/0020-records-in-yaml on the evidence in research/record-format-evidence.

Claimwick keeps use-case/spending.submit-expense in .litespec/behavior/modules/spending/expense/submit-expense.yaml, with its results and scenarios in records.

Checked bylitespec model check reports record-invalid for a record file that does not parse or whose top level names no record type or container page style.

Marked checkable: the tool named here checks it.

The file name is the link: no field joins the two files, so a rename moves both and nothing else. Plain Markdown with no frontmatter keeps the explanation readable in any reader and tells every check to read fields from the record file only. The file opens with the record title and uses H2 sections, so each explanation has one shape.

submit-expense.yaml explains its Example and Notes in submit-expense.md beside it.

Checked bylitespec model check reports explanation-orphaned for a Markdown file under a record root with no frontmatter and no record file beside it.

Marked checkable: the tool named here checks it.

Fields are checked; explanation prose is not. A fact a check reads that sits in prose is invisible to the check. The page explanation cites entries by identifier, so entries need no file of their own.

The submit-expense summary lives in the summary field of submit-expense.yaml, while why the flow reads well lives under Notes in submit-expense.md.

Reviewed forWhich explanation files state a fact a check reads? Look at each explanation file beside its record file.

Marked guidance: a reviewer answers this question.

An article is read as prose: the Answer of a research and the Context of a decision are what the reader comes for. The required sections keep each article complete: Answer for research, and Context, Options Considered, Decision, and What Would Reopen It for decision.

research/approval-time-benchmarks carries its Answer in approval-time-benchmarks.md.

Checked bylitespec model check reports explanation-missing for an article type with no explanation file or with a required H2 section missing.

Marked checkable: the tool named here checks it.

One layout for every record keeps diffs small and readers on content: a change shows the moved fact, never reflowed prose or reordered keys. The tool owns the layout, so litespec model format rewrites every record file into canonical form and the check reports any file that differs.

A use-case file opens with type, id, and title, holds its own fields in schema order, and closes with records.

Checked bylitespec model check reports format-drift for a record file whose text differs from its canonical form.

Marked checkable: the tool named here checks it.

A record with no parent has no place in the book, and a record with two parents appears twice. One parent per record puts every record exactly once: the container is the parent, so an entry sits under the record file that holds it, a scenario sits under its result, and a record file sits under its folder node. A requirement sits on its feature page, and types at product level sit under the product with no field written. Settled by decision/0002-parent-for-every-record on the evidence in research/behavior-containment-evidence, research/intent-hierarchy-evidence, research/book-outline-evidence, and research/established-traceability-practice.

In the Claimwick product, requirement/approval-reminders.receipt-over-threshold sits on the feature/approval-reminders page under intent/modules/spending/features/; use-case/spending.submit-expense sits beside its aggregate; and scenario/submit-expense.submitting-with-a-receipt-succeeds sits under result/submit-expense.submitted.

Checked bylitespec model check reports record-parent-missing (level G) for a record whose required parent is missing.

Marked checkable: the tool named here checks it.

The folder wins: an identifier whose home segment disagrees with its folder names a home the record left. Only identifiers whose first segment names a module change with a module move. A rule identifier keeps its home segment, because the segment names the aggregate or module the rule is about rather than the folder that holds it. A move between product and module level changes no identifier, so no citation changes.

Claimwick moves use-case/spending.submit-expense from the spending module to the finance module, so the use case becomes use-case/finance.submit-expense and every citation changes in the same change.

Checked bylitespec model check reports identifier-folder-drift for an identifier whose home segment disagrees with its folder.

Marked checkable: the tool named here checks it.

Short identifiers resolve with no lookup table only when each name means one record. Folders do not narrow uniqueness: two features with one name in two modules still collide everywhere the identifier is read.

Claimwick names one feature approval-reminders; a second feature with that name in another module is reported even though the folders differ.

Checked bylitespec model check reports name-duplicate for a name segment that occurs twice in the product.

Marked checkable: the tool named here checks it.

Product and technical decisions share one identifier space, so a number identifies one decision wherever it sits. litespec new decision takes the next free number, and no two decisions share it.

decision/0005-render-receipts-as-pdf is the fifth decision, whether it sits under Intent or under Implementation.

Checked bylitespec model check reports decision-number-duplicate for two decisions sharing one number.

Marked checkable: the tool named here checks it.

One writing site keeps a link and its source in one edit: changing the source updates the link in the same change. Links written on the target instead would scatter each relationship across every page it touches. Settled by decision/0002-parent-for-every-record on the evidence in research/behavior-containment-evidence, research/intent-hierarchy-evidence, research/book-outline-evidence, and research/established-traceability-practice.

Checked bylitespec model check reports reference-unknown for a link whose target no record carries.

Marked checkable: the tool named here checks it.

A use case, reaction, job, notification, or setting with no served journey step and no fulfilled requirement answers to nothing above it: no promise explains why it exists. Pointing up with serves or fulfills ties every behavior to the Intent that asks for it. record-link-missing fails a use case, reaction, job, notification, or setting carrying neither. A use case is background-only when a reaction or job runs it, so use-case-journey-missing skips it.

Checked bylitespec model check reports record-link-missing for a use case, reaction, job, notification, or setting with neither serves nor fulfills, and use-case-journey-missing (level G) at large size for a use case that no reaction, job or other use case runs and that serves no journey step.

Marked checkable: the tool named here checks it.

The folder fixes where a record sits, and reachability fixes that it leads to software. A record that reaches no Behavior is either unfinished work, which belongs on the backlog, or not software. A branch may be incomplete, so a local run reports unreached records while the pull-request check blocks on them. The same planned-Intent rule covers requirement-fulfillment-missing, step-use-case-missing, goal-mover-missing and constraint-unreached: each reports locally and blocks only in the pull-request check. A record that must stay unreached past a merge carries an exception with expiresOn, which parks reachability for that record until it expires.

In Claimwick, problem/expenses-wait-weeks reaches Behavior through feature/approval-reminders and its requirements; a problem no feature or requirement addresses is reported.

Checked bylitespec model check reports intent-unreached for a record that reaches no Behavior; a local run reports it and the pull-request check blocks on it. The planned-Intent findings requirement-fulfillment-missing, step-use-case-missing, goal-mover-missing and constraint-unreached take the same outcome.

Marked checkable: the tool named here checks it.

A step no use case, reaction, or job serves promises a moment the product never builds. Use cases, reactions, and jobs point up with serves, so each step id collects the behaviors that carry the walker through it. step-use-case-missing fails a step with no serving use case, reaction, or job. The pair sits side by side: step-use-case-missing names a step no use case, reaction, or job serves, and step-screen-missing names a step a browser or device use case serves that no screen serves.

Checked bylitespec model check reports step-use-case-missing for a journey step with no serving use case, reaction, or job, beside step-screen-missing for a step a browser or device use case serves that no screen serves.

Marked checkable: the tool named here checks it.

A record linked from another module with no declared tie is not local: it belongs at product level. The declared dependency or the integration event names the tie, so the seam where a monolith would split stays visible. Links from one layer down to the next may cross modules, because that is how one capability spans modules.

A spending rule cited from the finance module with no dependsOn tie and no integration event between them is reported; the rule moves to product level or the modules declare the tie.

Checked bylitespec model check reports link-locality-invalid for a record under a module that is linked from another module with no declared dependency or integration event.

Marked checkable: the tool named here checks it.

A dependency cycle says each module builds on the other, so neither has a seam to split along. The module order stays a directed graph with no cycle, like the effect edges.

Spending depends on finance and finance depends on spending, so the cycle is reported.

Checked bylitespec model check reports module-dependency-invalid for a module dependency cycle.

Marked checkable: the tool named here checks it.

An event with two publishers has two writers of one fact: readers cannot tell which module states it. One publishing module gives the fact one home, and every other module reads it through the event.

integration-event/expense-submitted is published from the spending module; a second publisher in the finance module is reported.

Checked bylitespec model check reports event-publisher-invalid for an integration event with a second publishing module.

Marked checkable: the tool named here checks it.

The module record declares the module; rules are behavior and live with Behavior. A rule written into module.yaml hides behavior in a declaration no rule check scans.

A spending rule lives in a rule-set file under behavior/modules/spending/rules/; the same rule written into module.yaml is reported.

Checked bylitespec model check reports record-placement-invalid for a rule in module.yaml.

Marked checkable: the tool named here checks it.

Intent records outrank Behavior records: constraint over product, product over requirement, requirement over rule, rule over use case, use case over result, and result over scenario. The order settles a conflict without a meeting: a use case asking for behavior its rule forbids loses to the rule. Where Intent has spoken, the specification wins over code; where the specification is silent, an agent builds nothing, as the Authority section states. Goals, problems, features, journeys, actors, research, and prose carry no authority, so none outranks the ladder.

Reviewed forConflict decisions under .litespec/intent/decisions/ name the higher record that won, in the order this page states.

Marked guidance: a reviewer answers this question.

Missing work with no date is invisible: nothing reports it. An exception of kind gap with an expiresOn date turns the same missing work into a visible promise: the findings its covers names report until the date, and exception-expired reports the exception after it. Settled by decision/0014-one-exception-record on the evidence in research/lower-layers-practice.

The running Claimwick example accepts that exporting expenses has no handler yet, so the gap lives as an exception with an expiry date in .litespec/governance/exceptions/export-expenses-unimplemented.yaml.

type: exception
id: exception/export-expenses-unimplemented
title: Export expenses unimplemented
kind: gap
covers:
  - use-case-unimplemented
subject:
  - use-case/spending.export-expenses
reason: Export waits for the finance file format.
expiresOn: 2027-06-01

The use-case-unimplemented finding reports without failing until 2027-06-01, which satisfies this provision.

Checked bylitespec model check reports record-invalid for an exception missing its date, exception-expired (level G) past its expiresOn date, and exception-finding-unknown (level G) for an exception naming a finding code no check uses.

Marked checkable: the tool named here checks it.

A decision that names nothing governs nothing. Naming at least one settled record gives the decision something to govern. A technical decision governs the code that follows it instead.

Checked bylitespec model check reports decision-decides-missing for a product decision with an empty decides field, and decision-decides-duplicate for two decisions deciding one record.

Marked checkable: the tool named here checks it.

Why a pattern, a library, or a configuration value was chosen is the first thing a maintainer asks before changing it. Written in a comment, the answer drifts and no tool finds it. Written as a decision, it carries its options, what speaks for and against each, and what would reopen it, and every code element shaped by it names it in a follows mark. A choice a LiteSpec provision already makes needs no decision, because the provision is the record. Technical decisions sit under Implementation because they name technologies and code, which Intent never holds, and they share the numbered sequence of product decisions, so all decisions share one identifier space.

Claimwick renders each receipt as a PDF file. decision/0005-render-receipts-as-pdf weighs a PDF library against an HTML-to-PDF browser, chooses the PDF library, and names what reopens the choice: receipts no longer needing a downloadable file. The receipt PDF renderer carries /// <follows>decision/0005-render-receipts-as-pdf</follows>.

Checked bylitespec model check reports decision-unimplemented (level S) for a technical decision that no code element follows. The check runs in the CLI only, with no analyzer rule: whether any code follows a decision is known only across every project, and one compilation sees one project.

Marked checkable: the tool named here checks it.

A technical decision chooses one way among alternatives, and a better alternative may replace it tomorrow. A rule such as keeping personal data in the European Union, or a target such as answering checkout within two seconds, does not change when the library does: overriding it needs a business, legal, or organizational change. Written inside a decision, the rule disappears the day the decision is replaced, and nobody holds it as the promise it is. Kept in Intent, the rule and the target stand as the promises they are, the decision points up to them, and the chain runs unbroken from code through the decision to the constraint or requirement and the goal above it. A decision with no basis is advice, level A, while a product decision that decides nothing blocks at level G: a technical choice among equal options may serve no rule or target yet and still govern the code that follows it, but a product decision that settles no record governs nothing.

Claimwick keeps each receipt for the tax file because constraint/tax-receipt-retention requires it, and answers submissions quickly because requirement/expense-submission.month-end-load sets the target. decision/0005-render-receipts-as-pdf names the constraint in basedOn, and decision/0004-serve-receipts-behind-one-proxy names the requirement in basedOn; neither the seven years nor the two seconds is written in a decision.

Checked bylitespec model check reports decision-basis-missing (level A) for a technical decision whose basedOn names nothing, and counts a quality requirement as fulfilled when a technical decision names it in basedOn.

Marked checkable: the tool named here checks it.

A link that points at a moved file or an unknown identifier reads as navigation and leads nowhere. A link whose target is a record identifier, with an optional #<step-id>, cites that record: link checks resolve it against the model's identifiers, citation checks count it, and the book links it to the record. Prose cites a record by its identifier, never by its file path.

The Claimwick receipt rule is cited as [the receipt rule](rule/expense.approver-is-not-submitter).

Checked bylitespec model check reports link-unknown for a link that resolves to no file and no written record identifier.

Marked checkable: the tool named here checks it.

Size decides which record types and test projects the checks require, while stacks decide which technology pages and checks apply. Without the declaration, the builder cannot tell a missing record from one the project never needed.

The running Claimwick example declares large with a server shape and two stacks.

Checked bylitespec model check reports size-type-missing and record-invalid for a project missing its declaration or a required type.

Marked checkable: the tool named here checks it.

Callers branch on named endings: success or a specific refusal with its code. Refusals stand in precedence order, so the first match wins. A refusal that stores its attempt carries recorded, and a success with recorded outcomes inside it carries codes. Generic refusals are derived, never written, so they need no entry. A use case with no named success leaves callers guessing what good looks like, and scenarios prove one ending each, so unnamed endings stay unproven.

A submit use case names submitted and receipt-missing.

The running Claimwick example carries this in use-case/spending.submit-expense, which names result/submit-expense.submitted and result/submit-expense.receipt-missing with scenario/submit-expense.submitting-with-a-receipt-succeeds:

records:
  - type: result
    id: result/submit-expense.submitted
    title: Submitted
    outcome: success
    meaning: The expense is submitted.
  - type: result
    id: result/submit-expense.receipt-missing
    title: Receipt missing
    outcome: refusal
    code: spending.receipt-missing
    meaning: The expense is above the receipt threshold and carries no receipt.
  - type: scenario
    id: scenario/submit-expense.submitting-with-a-receipt-succeeds
    title: Submitting with a receipt succeeds
    given: An employee paid for a train ticket and kept the receipt.
    when: The employee submits the expense with the receipt.
    then: The expense is submitted.
    result: result/submit-expense.submitted

Success names the submitted ending, the refusal carries the code spending.receipt-missing, and the scenario pairs one given and when with the success result, which satisfies this provision.

Checked bylitespec model check reports use-case-success-missing and scenario-result-unknown for a use case missing its success or a scenario naming no result.

Marked checkable: the tool named here checks it.

A feature worked from problem to scenario stays complete at every level: each record lands with the Intent above it already written. Parallel slices leave Behavior records resting on Intent nobody wrote yet.

Reviewed forBehavior records show Intent above them through their fulfills and decides links.

Marked guidance: a reviewer answers this question.

Handwritten state drifts: a record marked implemented stays marked after its handler is deleted. Computed state cannot drift, because the builder re-derives it from handlers, routes, scenarios, and test runs on every run. A use case reads implemented when a handler, reaction, job, or endpoint marked with it carries it out, verified when every scenario has a passing proof through the public boundary that is not stale, and stale when the scenario hash or the test-body hash differs from .litespec/proof/proofs.json. A requirement reads met when everything fulfilling it is verified and its measure's check passes. A record reads tested when a passing test that asserts something links to it. A journey step reads exercised when a passing proof of a use case serves it. A proof reads flaky when its test both passed and failed within the runs read. Nothing above Implementation is computed from code: derivation from code into any other record is forbidden, and code-computed facts live in the book and the model output. Settled by decision/0017-proof-that-holds on the evidence in research/lower-layers-practice.

A use case reads implemented when its handler exists.

Checked bylitespec model check reports use-case-unimplemented, proves-unreached, and refusal-unimplemented for a use case whose handler, proof, or refusal code is missing, and proof-invalid (level A) for a test that both passed and failed within the runs read.

Marked checkable: the tool named here checks it.

Nothing blocks on an unverified scenario day to day, so the release gate would depend on someone reading the book. Reporting the use case keeps daily work loose, and litespec model check --release makes the finding block, so the release stays honest without slowing ordinary work.

Claimwick adds use-case/spending.export-expenses with two scenarios and one passing proof: litespec model check reports use-case-unverified for it and exits zero, and litespec model check --release blocks on it.

Checked bylitespec model check reports use-case-unverified (level A) for a use case whose scenarios are not all proved, and litespec model check --release blocks on it.

Marked checkable: the tool named here checks it.

Completion is a fact the builder can count from fulfilment, code and proof, so no record carries a shorthand saying how far it is. One ladder reads the same everywhere: unfulfilled when no Behavior record fulfills a record, specified when it is fulfilled and no code is found, implemented when code is found for every in-scope child, and proven when every in-scope child is verified or met with fresh proof. When the model holds no test run, an implemented record stays implemented with proof unknown, so proof unknown never reads as a failure. A requirement an exception parks stays out of the stage and the counts and names itself in heldBy, so deferred work stays visible.

In Claimwick, feature/expense-submission shows implemented with proof unknown before any test run, held by the one requirement with no fulfiller; after a passing run proves every fulfiller, the same feature shows proven with no held-by entries.

Reviewed forWhich features read below proven, and which children hold each one back? Look at completion on each feature in the model.

Marked guidance: a reviewer answers this question.

A reader judging a screen needs to see it, and a capture named by its route, theme and width is the copy the built screen makes. The route slug names the file the same way everywhere: the leading slash dropped, segments joined with a hyphen, a parameter reduced to its name, and the root route named home. A missing gallery folder captures nothing and fails nothing, so a project with no photography yet still builds its model.

The Claimwick web gallery holds expenses--light--1440.png, so screen/expenses.list at /expenses shows that capture at theme light and width 1440 with captureState captured; a screen with no address shows no-route.

Reviewed forWhich screens with a route have no capture? Look at captureState route-not-captured on screen records in the model.

Marked guidance: a reviewer answers this question.

The level tells a reader what a finding means: G reads records only and always blocks, S reads code through a stack reader and blocks only where the reader is qualified, and A reports and never blocks. litespec model check prints the level beside each finding, so a reader tells a blocking defect from advice at a glance. A missing required link is level G.

Checked bylitespec model check reports reader-missing (level S) for a frontend whose reader is missing or failing, and prints the level beside each finding.

Marked checkable: the tool named here checks it.

Two styles in one language are two ways to do one job: a reader learns both, a check covers both, and a search for a record finds half its code. The C# style is a project choice made once, so every tool reads it from the project file and refuses the other style within C#. TypeScript and operations files have one form each, so a typed constant beside a C# documentation tag is two languages, not two styles. A code fix converts a mark to the form its language takes.

The Claimwick product declares "marks": "xml", so its submit-expense handler carries a documentation tag naming use-case/spending.submit-expense, and an attribute naming the same use case is reported. Its use-case module carries the same identifier as a typed constant, and its deployment file carries its follows mark as a comment.

Checked bylitespec model check reports mark-style-invalid (level S) for a mark written in a form its language does not take.

Marked checkable: the tool named here checks it.

Copying a handler and forgetting its mark is the most common agent mistake, and the folder already says what the mark should be. A handler that sits in one use-case folder while naming another sends readers and checks to the wrong record. An aggregate method and a technical class carry the mark of the use case that calls them, which may sit in another module, so their folder says nothing about their mark. The frontend mirror already compares each mark with its module; the backend check applies the same comparison to handlers, endpoints, and aggregates.

A handler in Booking/Holds/HoldRoom/ marked use-case/booking.release-hold is reported, because the folder holds use-case/booking.hold-room.

Checked bylitespec model check reports mark-folder-drift (level S) for a handler, endpoint, event handler, job host or aggregate root whose mark names a record outside its module and folder, and code-placement-drift (level S) for a code element, test, or folder outside its record's qualified path.

Marked checkable: the tool named here checks it.

A test outside the record tree is either proof of something the specification forgot to state or a test that verifies nothing anyone promised. Naming the lowest record it verifies places each test: a scenario or rule for behavior, a quality requirement for how well the product behaves, a technical decision for a technical choice, an external system or integration event for an agreement with the outside, and a provision for a structural rule the code must keep. A test that verifies a choice no record states shows a missing record, which is written at the level where the choice lives, as safety-critical standards resolve derived requirements; a test that verifies nothing a record should state is deleted. Proof stays layered: only scenario and rule proofs verify a use case, and a passing test that asserts something links to a quality requirement, a technical decision, an external system, an integration event, or a provision marks that record tested, so "the adapter is right" never reads as "the promise is kept". A background use case is verified through the passing proofs of the use cases it serves. A browser success proof asserts the result sentence or the scenario Then text.

In Claimwick, the submit-expense acceptance test proves scenario/submit-expense.submitting-with-a-receipt-succeeds; a load test of month-end submissions proves requirement/expense-submission.month-end-load; a receipt-rendering test proves decision/0005-render-receipts-as-pdf; and the layering test that Domain references no persistence package proves litespec/backend/architecture#point-dependencies-inward.

Checked bylitespec model check reports mark-missing and mark-unknown (level S) for a test that names no record or a record of a kind a test does not take.

Marked checkable: the tool named here checks it.

A mark points up, so a check reading marks alone finds code nobody recorded but misses a record nobody built. Checking each record that the marks table maps to code from the top closes the loop in the other direction: an entity aggregate with no root, a reaction with no event handler, a job with no host, an external system with no port, and a use case people reach with no endpoint. A store has no root, so it needs no mark. A use case with no screen calling it is reported as advice, because whether a browser reaches it depends on the deployment.

reaction/spending.send-approver-reminder-on-expense-submitted has no event handler carrying its mark, so the check reports reaction-unimplemented and blocks.

Checked bylitespec model check reports aggregate-unimplemented, reaction-unimplemented, job-unimplemented, external-system-unimplemented, and use-case-endpoint-missing (level S) for a record no mark names, where aggregate-unimplemented fires only for an entity aggregate, and use-case-unreached (level A) for a browser use case no screen calls.

Marked checkable: the tool named here checks it.

A project-wide lowering in .editorconfig is a departure from the standard rather than a setting. An exception of kind departure names the provision, the reason and the expiry date, so the lowering is dated and ends instead of staying silent.

A project that lowers LS5001 to a suggestion in its root .editorconfig records an exception of kind departure citing litespec/core/system#point-code-and-tests-up-to-records.

Checked bylitespec model check reports analyzer-lowering-unrecorded (level S) for a project-wide lowering in .editorconfig, .globalconfig, <NoWarn>, #pragma warning disable or [SuppressMessage] that no live exception covers.

Marked checkable: the tool named here checks it.

The book is how people read the model, so it shows the model's own hierarchy. A reader who learns Intent, Behavior, Implementation and Proof in the book reads the same structure in the docs folder, in the model output and in every other LiteSpec project. An outline of the book's own invention is a second hierarchy to learn, and it drifts from the one the records keep. Settled by decision/0002-parent-for-every-record on the evidence in research/behavior-containment-evidence, research/intent-hierarchy-evidence, research/book-outline-evidence, and research/established-traceability-practice. Settled by decision/0008-book-follows-record-layers on the evidence in research/book-outline-evidence, research/behavior-containment-evidence, and research/check-coverage-evidence.

In the Claimwick product, use-case/spending.submit-expense sits under Behavior, its module and its aggregate; its results under it; each scenario under the result it shows; and the handler that carries its mark under Implementation.

Reviewed forWhich book headings or groupings are not a record layer, a record type, or a record the identifier names? Look at the book's outline beside this page's record type table.

Marked guidance: a reviewer answers this question.

LiteSpec already names every concept once, for people and agents alike. A friendlier synonym in the book, such as promise for requirement, is a second word for one concept: the reader learns it, then meets the real word in the records and the checks, and has to translate. Settled by decision/0008-book-follows-record-layers on the evidence in research/book-outline-evidence, research/behavior-containment-evidence, and research/check-coverage-evidence.

A use case page heads its results "Results" and its scenarios "Scenarios", never "Endings" and "Examples".

Reviewed forWhich book labels are neither a record type, a field name, a computed state, a glossary term, nor the reads-as phrase the Links table states for a connection? Look at the book beside the glossary and the Links table.

Marked guidance: a reviewer answers this question.

The book explains itself so nobody needs a learning curve, and the explanation stays true only when it has one source. An explanation written for the book drifts from the definition the records follow. Settled by decision/0008-book-follows-record-layers on the evidence in research/book-outline-evidence, research/behavior-containment-evidence, and research/check-coverage-evidence.

The book explains an exception with the glossary definition of Exception.

Reviewed forWhich explanations in the book are not a glossary definition or a record type question? Look at the book's explanations beside the glossary and the record type table.

Marked guidance: a reviewer answers this question.

The book is a view of the model, not a second authority. A judgement only the book makes, such as its own idea of what to do next, cannot be checked, cannot fail a build, and cannot be found by an agent reading the model output. Settled by decision/0008-book-follows-record-layers on the evidence in research/book-outline-evidence, research/behavior-containment-evidence, and research/check-coverage-evidence.

The book orders features by the completion the builder computes.

Reviewed forWhich statuses, counts, orders or findings in the book does no builder output or check produce? Look at the book beside the model output.

Marked guidance: a reviewer answers this question.

Rendering the book is a probe: what it cannot show is a gap in the specification. Closing the gap in LiteSpec gives every project the fact, checked; closing it in the book gives one view an unchecked fact. Settled by decision/0008-book-follows-record-layers on the evidence in research/book-outline-evidence, research/behavior-containment-evidence, and research/check-coverage-evidence.

The book needs to say that a refusal has no scenario, so LiteSpec gains a check for it, and the book shows that check's findings.

Reviewed forWhich facts does the book show that no record field, computed status or check defines? Look at the book beside the model output and the finding codes.

Marked guidance: a reviewer answers this question.

The book is where a reader notices what to change, and the source is where the change is made. A link to the file and line makes the next step one click, and it shows that every entry comes from a written record or from code, not from the book. Settled by decision/0008-book-follows-record-layers on the evidence in research/book-outline-evidence, research/behavior-containment-evidence, and research/check-coverage-evidence.

The submit-expense use case page links to .litespec/behavior/modules/spending/expense/submit-expense.yaml at its first line, and its handler to the handler file at the class.

Reviewed forWhich book entries lack a link to their file and line? Look at the book's record, code, test and finding entries.

Marked guidance: a reviewer answers this question.