Supported Scope

One size and explicit stacks tell every check which records and pages apply. The size decides which record types the project carries and which test projects prove them; each stack decides which technology pages and checks apply. Without the declaration, each agent infers the architecture from the directory tree, and two agents infer two architectures. At records a project may leave the stacks empty or absent, or name them for information alone, since no code reader runs at that level; at traced and full the stacks name the code the reader and the checks govern.

A project with one web frontend and no journeys selects small with the svelte stack; the running Claimwick example, with journeys, selects large.

The running Claimwick example declares large with a server shape and two stacks in .litespec/project.json:

{
  "size": "large",
  "shape": "server",
  "stacks": ["dotnet", "svelte"],
  "conformance": "full"
}

The size selects the large record set, the shape selects a backend stack, and each stack selects its technology pages, which satisfies this provision.

The diagram shows the three project choices and what each decides.

Checked bylitespec model check refuses, at traced and full, a shape whose backend stack count is wrong and a platform that names no frontend stack.

Marked checkable: the tool named here checks it.

A project can take the record model without LiteSpec's code layout, or trace its code to its records in a layout of its own. The level tells every tool which part of the contract the project claims, so model check, the book, rules and the analyzers report that part and nothing else. The levels nest: traced claims everything records claims, and full claims everything traced claims. The table in The Three Conformance Levels states what each level claims, what each tool runs at that level, and what the book and rules show.

The running Claimwick example declares "conformance": "full". A product that keeps its own folder layout and proves its records only through result files declares "conformance": "traced". A product that takes the record model alone and keeps its own layout and tooling declares "conformance": "records".

Checked bylitespec model check reports project-invalid for a project file that names no level or a value other than records, traced or full.

Marked checkable: the tool named here checks it.

One business language and one deployment boundary keep every module, record, and use case in a single consistent model. Modules organize related language, models, use cases, and code without becoming independent services or bounded contexts. A second language or boundary splits the project into systems that the records, links, and checks can no longer hold together.

Posts, Authors, and Comments can be modules in one publishing context.

Reviewed forModule pages and .litespec/project.json name one business language and one deployment boundary, with no second of either.

Marked guidance: a reviewer answers this question.

A record about running the company states no behavior the checks confirm: retention, revenue, market sizing, sales tactics, and launch plans pass no software check. The software test in the Concepts section tells what belongs for each type, so a goal about nights without oversell stays while a goal about revenue leaves. A record that reaches no Behavior gets a blocking finding: it is either unfinished work for the backlog or not software.

Claimwick keeps its expense areas under product names; a market fact that binds the product enters as dated research or as a constraint citing it, and a folder under intent/modules/ naming no declared module is reported.

Checked bylitespec model check reports a blocking finding for a folder under intent/modules/ naming no declared module and for a record reaching no Behavior.

Marked checkable: the tool named here checks it.

Conditional capabilities stay inactive until a documented product or engineering condition applies, so no project carries caching, messaging, or tenancy machinery it never justified. Selecting exactly the extensions whose criteria hold keeps the active rule set minimal and reviewable. The manifest's extension list is the closed set a project selects from, so there is no informal extension.

Caching, durable messaging, and multitenancy are extensions; the extension index lists each with its activation criteria.

Reviewed forEach entry in selectedExtensions carries a criterion that holds, and no applicable extension from the extension catalog stays unselected.

Marked guidance: a reviewer answers this question.

The project record determines which extension boundaries apply to the project's work. Writing each selection with its criterion lets a later reader check whether the condition still holds. Without the record, extensions drift in through dependencies and prose while the checks apply a different set.

Checked bylitespec model check reports project-invalid for a selection without a criterion.

Marked checkable: the tool named here checks it.

An outside rule the project never names is a law the product can break unknowingly. Recording the answer, even when it is empty, proves the team asked the question: an empty answer states that no outside rule binds the project. A later reader can then tell a project with no constraints from one that never looked.

A clinic booking system records that medical-device regulation does not apply to appointment scheduling.

Reviewed for.litespec/project.json states which outside constraints apply, or records an empty answer.

Marked guidance: a reviewer answers this question.

The shape decides which backend pages still apply. A client-only product keeps a domain model, so it applies the backend architecture, domain, application, and identifier pages that the manifest lists under shapes. Persistence, the HTTP API, and API testing have no target without a server, and the decision names those uncovered surfaces. Adding a server only to obtain conformance contradicts litespec/core/principles#require-current-complexity-activation, which permits new machinery only for a current documented requirement.

litespec/quality/ci#run-applicable-gates-on-every-pull-request already permits skipping a gate whose surface does not exist, so a missing backend gate is a recorded consequence rather than an unexplained absence.

Checked bylitespec model check refuses a client-only project that names a backend stack.

Marked checkable: the tool named here checks it.

Microservices, multiple contexts, native clients on a platform with no mobile stack, other platforms, event sourcing, active-active regions, and large pipelines each change the assumptions this page rests on: one language, one deployment, one API and database. A separate project decision records that the team saw the boundary and chose deliberately. Without it, the project drifts outside the supported scope while claiming its checks still apply.

Reviewed forA project decision names each architecture outside the supported boundary the project adopts.

Marked guidance: a reviewer answers this question.

A conformance claim tells a reader that the whole part of the contract the project claimed holds, not only the parts the project chose to follow. At records that part is the provisions about records; at traced it also takes in the provisions about marks and proof; at full it takes in every provision that applies. A recorded exception whose expiry date has not passed outranks the provision or findings it covers, so a project that records its exceptions still meets this provision; an unrecorded departure at the claimed level breaks the claim at that level and leaves any lower level the project does meet untouched.

A consumer that selects the dotnet stack and the caching extension and declares full claims conformance when every page those selections apply holds and their checks pass, with each departure recorded as an exception. A consumer that declares records claims conformance when the provisions about records hold, while its own code layout and tooling stay outside the claim.

Reviewed for.litespec/project.json names the declared conformance level beside the selected size, shape, stacks, and extensions; each departure from a provision that applies at that level resolves to an exception record under .litespec/governance/exceptions/, and the checks that run at that level pass.

Marked guidance: a reviewer answers this question.

The builder joins records, queries, diffs, and the book from one declared root. A Behavior tree the project record never names is one the tools never see, so its records skip every check. One declared folder keeps authors and tools on the same tree.

Checked bylitespec model check reports project-invalid for a project record without paths.behaviorDocs.

Marked checkable: the tool named here checks it.

One folder with one name in every consumer makes the LiteSpec material identifiable at a glance: a reader, a tool, or an agent finds the whole contract in one place, moves or deletes it without hunting the tree, and keeps it apart from the application's code, tests, and infrastructure. Generated output inside it stays covered by its .gitignore, so a checkout never mixes committed records with built files. Every path in .litespec/project.json stays relative to the repository root, so moving the folder never rewrites the paths inside it, and a command finds the consumer by walking up from the working folder to the first folder that holds .litespec/project.json.

Claimwick holds its project file, glossary, example cast, and the Intent, Behavior, Implementation, Proof, and Governance folders under examples/claimwick/.litespec/ (in a real consumer, at its repository root), beside its application code and tests, which keep their own places. An agent asked to read the contract opens that one folder instead of collecting a root project file, a documentation tree, a model folder, and a book folder from four places.

Reviewed forWhich files created, read, or governed by LiteSpec sit outside .litespec/, or at the repository root? Look at the repository tree beside the project's .litespec/ folder.

Marked guidance: a reviewer answers this question.