Edges and Screens

A published fact without a direction is read both ways: an outbound notice is answered as an order, an inbound claim is trusted as law. The direction, the CloudEvents type, source, and subject, the payload with classifications and types, and the trust of trigger-only or payload state what the fact is and how far readers follow it. Each payload field carries the field types use-case inputs use, as litespec/core/use-cases#describe-every-use-case-input-with-origin-and-classification states, and a money field carries an amount with an ISO 4217 currency, as the Record Language states. An event may name the dataschema URL its payload follows. An inbound event also declares its correlation; an outbound event declares its translates domain event and its optional addresses.

Checked bylitespec model check fails an integration event without direction, CloudEvents identity, typed payload, or trust.

Marked checkable: the tool named here checks it.

An emitted fact no edge declares is a hidden coupling: downstream readers depend on a promise the records never made, and the promise breaks without a diff. Declaring each emission as an emits effect states the coupling beside the behavior causing it. The effect-undeclared check reports an emitted event no record declares.

Checked bylitespec model check reports effect-undeclared for an emitted integration event no record declares in effects.

Marked checkable: the tool named here checks it.

An integrator reads the published name as the business fact; staged, dispatch or outbox describe the machinery that delivered it. A name carrying the fact travels across the boundary unchanged. The internal words are staged, dispatch, dispatched, outbox, handler, queued, worker, and job.

expense-reimbursement-requested names the requested reimbursement; expense-reimbursement-staged names the staging step and is reported.

Checked bylitespec model check reports integration-event-name-invalid (level G) for an outbound event named with an internal word.

Marked checkable: the tool named here checks it.

An inbound fact with no door is accepted anywhere: each handler invents its own intake, and trust scatters across the code. Arriving through a webhook entry point gives each inbound fact one door with one auth, where trust and correlation hold.

Reviewed forWhich inbound integration events lack a webhook entry point as their door? Look at the inbound events beside the entry points.

Marked guidance: a reviewer answers this question.

A message without declared addresses and consent is sent on hope: the wrong actors receive it, the channel ignores consent, repeats annoy. Declaring the template with its parameters and locale, the addresses, the channel, the consent rule, the frequency of once or per-attempt, and the dedup key states the message beside its promise. Suppression lives on the notification in suppressedWhen, and suppression scenarios show the message sending nothing. The notification-sender-missing check reports a notification no use case, reaction, or job sends.

Checked bylitespec model check reports notification-sender-missing for a notification no use case, reaction, or job sends, and fails a notification without its declared fields.

Marked checkable: the tool named here checks it.

The template key is the one join between a notification's promise and the text a person receives. A declared key the store lacks fails at send time, and a stored template no notification declares is text nobody reviewed. The store is the stack's own file, so the check reads it where it is instead of copying the keys into a record. A notification whose body the sender composes at send time declares template: none and is left out.

Claimwick's notification/spending.receipt-reminder declares template: receipt-reminder-manager, and the template store holds receipt-reminder-manager.

Checked bylitespec model check reports template-unimplemented (level S) for a declared key the store the stack page names lacks, and template-unrecorded (level S) for a stored key no notification declares, in a project whose stack configuration names a template store.

Marked checkable: the tool named here checks it.

A declared parameter is part of the message's promise: the order number in a confirmation, the name in a reminder. A parameter the template never uses is a promise the message does not keep, and it usually means the template was rewritten without the record.

notification/spending.receipt-reminder declares the parameter submitterName, and the receipt-reminder-manager template uses {{SubmitterName}}.

Checked bylitespec model check reports template-param-drift (level S) for a declared parameter whose placeholder, in the case the stack page states, appears in none of its template's texts.

Marked checkable: the tool named here checks it.

A key naming its subject, its event and its audience tells each reader what the message is about and who receives it; a key naming none of the three hides both.

receipt-reminder-manager names the receipt, the reminder and the manager audience; email-change-confirmation names no audience and is reported.

Checked bylitespec model check reports template-key-invalid (level A) for a template key ending in no name the notification declares in addresses.

Marked checkable: the tool named here checks it.

A message promising what no requirement holds is a promise no requirement states: the text assures a refund the policy never states. Citing the requirement behind each claim keeps every assured sentence a carried promise.

Reviewed forWhich notification claims lack a cited requirement? Look at the claims beside each notification.

Marked guidance: a reviewer answers this question.

A door with no kind is entered any way: a webhook is called as a page, a device as a browser. Declaring the kind of browser, api, webhook, device, cli, mcp, or served-content with its auth states how callers arrive and prove themselves.

Checked bylitespec model check fails an entry point without kind or auth.

Marked checkable: the tool named here checks it.

A page is where a person meets the product, and an unrecorded page offers use cases nobody reviewed as a page: what it lets someone start, which journey step it carries, which refusal it shows. One record per page, with one mark on the route, makes the page a reviewable promise and lets every other link (calls, results, journey coverage) be computed from it.

Claimwick's web route /expenses carries implements: "screen/claimwick-app.expense-list", and behavior/entry-points/claimwick-app/screens/expense-list.yaml offers use-case/spending.list-expenses.

Checked bylitespec model check reports screen-unimplemented (level S) for a screen no route marks, and behavior-unrecorded (level S) for a route with no mark or a mark naming no screen.

Marked checkable: the tool named here checks it.

A route screen without an address is unreachable, and an overlay with one is two pages fighting over a route. An address places a screen on its route; a host places an overlay on the screen it opens on. Exactly one of the two leaves every page placed once.

The expense list carries the address /expenses; its confirm overlay names the expense list in host instead.

Checked bylitespec model check fails a screen without exactly one of address and host.

Marked checkable: the tool named here checks it.

offers is the recorded promise of what a person can start on the page, and the calls are what the page really does. When the two differ, either the page grew a capability nobody recorded or the record promises one the page dropped. Comparing them on every run keeps the record honest without anyone re-reading the page.

The expense list offers use-case/spending.list-expenses, and its route calls ListExpenses through the generated client.

Checked bylitespec model check reports screen-offers-drift (level S) for a screen whose offers and computed calls differ, naming each use case on one side only.

Marked checkable: the tool named here checks it.

A journey step is achieved through use cases, and a person reaches those use cases on a screen. Naming the step on the screen lets the book say where each step happens, and checking it against the offered use cases finds a screen claiming a step its use cases do not carry.

The expense form serves journey/submit-and-reimburse#s1 because it offers use-case/spending.submit-expense, which serves that step.

Checked bylitespec model check reports screen-serves-drift (level G) for a served step no offered use case serves.

Marked checkable: the tool named here checks it.

A step a person achieves in a browser happens on some page. A step no screen serves is either carried by a page nobody recorded or not reachable at all, and the book cannot tell the reader where it happens. The pair sits side by side: step-use-case-missing names a step no use case serves, and step-screen-missing names a step a browser or device use case serves that no screen serves.

journey/submit-and-reimburse#s1 is served by the expense form.

Checked bylitespec model check reports step-screen-missing (level G) for a step a browser or device use case serves that no screen serves.

Marked checkable: the tool named here checks it.

A refusal a person can trigger on a page is part of what the page says to them. Without a sentence, the person sees a code or a generic error; without a test, nobody knows what they see. Requiring one of the two only where a screen can reach the refusal avoids demanding sentences for refusals no person meets. Each frontend names its dictionary in its paths.frontends[] entry, so the check reads that frontend's words rather than a convention.

The expense form offers use-case/spending.submit-expense, whose spending.receipt-missing refusal has a sentence in the dictionary the Claimwick web frontend names in refusalDictionary.

Checked bylitespec model check reports refusal-sentence-missing (level A) for a refusal a screen can reach with neither a sentence in its frontend's refusalDictionary nor a browser test asserting its code.

Marked checkable: the tool named here checks it.

A static file modeled as a use case invents behavior where none exists: results, scenarios, and handlers for bytes served unchanged. Serving it as content with its path, content type, cache control, versioning, and fulfilled requirements keeps content apart from behavior.

Reviewed forWhich static scripts or legal texts sit outside served content, or lack path, content type, cache control, or versioning? Look at the static files beside the served-content entries.

Marked guidance: a reviewer answers this question.

An outside call without a declared shape fails by surprise: timeouts hang, retries double-charge, responses unparse. Describing each operation with its direction of out or in, its timeout with its timeout handling, its response, and its cache states the coupling beside the system. The retries prose states the retry behavior in words beside onTimeout. The retry count lives on the calling edge in onFailure.retry.maxAttempts. The system stands alone and names no actor.

Checked bylitespec model check fails an external system operation without direction, timeout, timeout handling, response, or cache.

Marked checkable: the tool named here checks it.