Provision Scopes

One block under the title tells every reader and tool which situation the page governs without reading further. A page without it leaves its provisions unfiled: retrieval cannot tell which change they govern, so it shows them everywhere or nowhere. Declaring both fields once keeps the page, not each provision, as the home of the common scope.

Checked bylitespec-maintain validate emits no SCOPE_BLOCK diagnostic.

Marked checkable: the tool named here checks it.

Retrieval matches situations to values: a value invented on one page matches nothing, so its provisions never surface for the change they govern. One closed vocabulary keeps every value comparable across pages. A new situation earns a value here first, then uses it on its page.

A provision about the expense aggregate narrows with artifact: aggregate rather than inventing artifact: receipt. A provision about marks on a record-model page states conformance: traced rather than inventing a level name.

Checked bylitespec-maintain validate emits no SCOPE_VALUE diagnostic.

Marked checkable: the tool named here checks it.

The page scope already governs every provision on it: repeating it on each provision doubles the homes for one fact, and the copies disagree at the next edit. An Applies to line that widens the page scope misfiles the provision under situations the page never governed. One line, only when narrower, at a different level, or marking the layer-wide scope beside a named kind, keeps retrieval exact.

On a page scoped to layer: domain, a provision for aggregates carries **Applies to:** artifact: aggregate, while a provision for the whole domain layer carries no line. On an application page where a provision names artifact: validator, a provision for the whole application layer carries **Applies to:** artifact: any. On a record-model page, a provision about marks carries **Applies to:** conformance: traced.

Checked bylitespec-maintain validate emits no SCOPE_NARROW diagnostic.

Marked checkable: the tool named here checks it.

litespec rules matches a provision to a file by the kind of file it names. A provision that names none on a page of named kinds matches every file of the layer, so a handler receives the validator and port provisions beside its own and an agent reads provisions that do not govern the file in front of it.

On the application page, the provision for validators names artifact: validator and the provision for the whole application layer names artifact: any, so litespec rules on a command handler returns the second and leaves out the first.

Checked bylitespec-maintain validate emits no SCOPE_ARTIFACT diagnostic.

Marked checkable: the tool named here checks it.

A tool that reports only the part of the contract a project claims reads the level of each provision from the provision index: a provision with no level, or with a level copied from its page, gives the tool no exact part to report. The page folder gives the default, one override states the exception, and the index carries the result beside the artifact, so no reader composes the level by hand.

A provision about expense records on a page under docs/core/ carries records from its page and states no field. A provision about test marks on the same page states **Applies to:** conformance: traced, and its index row carries traced.

Checked bylitespec-maintain validate emits no SCOPE_VALUE diagnostic for a provision with no conformance level.

Marked checkable: the tool named here checks it.

A rule binds every project it reaches: a silent departure claims conformance the project does not hold. The exception record names the provision, the reason, and the expiry date, so the departure stays visible, dated, and ends instead of lingering. The model page states how a live exception outranks its provision.

Claimwick ships its weekend export without the review step, so it records an exception of kind departure whose covers names the authorization provision, with the reason and an expiry date.

Reviewed forEach departure from a provision of Strength rule resolves to an exception record under .litespec/governance/exceptions/ with the provision, a reason, and an expiry date.

Marked guidance: a reviewer answers this question.

A default holds until the project says otherwise in writing: without the record, a reader cannot tell a deliberate choice from a provision nobody read. The provision names the recording place in its Replacement, so each choice sits where its provision points. Advice asks for no record, which is what sets the two strengths apart.

A project that keeps its pattern catalog outside the default path records the path in paths.uiPatterns, as the provision's Replacement names.

Reviewed forEach choice against a provision of Strength default is recorded in the place its Replacement names.

Marked guidance: a reviewer answers this question.