Access

One home per type tells a reader where to open a record and tells the book where to render it. A record kept anywhere else looks written while readers open the home and find nothing there.

Reviewed forWhich access records sit outside the homes their type names? Look at the actor, role, permission, entry point, and external system homes.

Marked guidance: a reviewer answers this question.

The kind tells a reviewer whether a human or an organization stands behind the actor, which decides who answers for what it does. Without the kind, a reviewer assigns responsibility without knowing who stands behind the actor. Software stands behind no actor.

An employee actor carries person, and the library as a lending party carries organization.

Checked bylitespec model check reports record-invalid for an actor without kind and field-invalid for a kind outside person and organization.

Marked checkable: the tool named here checks it.

The hold is the grant: without it, the actor and the role sit on separate pages with no stated connection, and no reviewer can tell what the actor is allowed to do. The scope bounds each grant, so one role grants platform reach to one actor and self reach to another.

Checked bylitespec model check reports role-orphan for a role held by no actor.

Marked checkable: the tool named here checks it.

The scope bounds what the role reaches: the same permission allows platform-wide action in one grant and own-record action in another. Without a named scope, every grant reads as product-wide, and the narrowest grant gets the widest reach.

A scope of team bounds the role to one team, while platform bounds it to the whole product.

Checked bylitespec model check reports record-invalid for a role without scope and field-invalid for a scope outside kebab-case form.

Marked checkable: the tool named here checks it.

The allows list is the middle of the chain: it joins the actors that hold the role to the use cases that cite its permissions in their grants. The role lives in Intent and the permission lives in Behavior, so allows is a declared down-link. A role that names no permission grants nothing, so every use case its holders run breaks the chain at the middle link.

role/employee allows permission/submit-expense, which the submit use case cites in its grant.

Checked bylitespec model check reports record-invalid for a role with no allows entry, and permission-orphan for a permission allowed by no role.

Marked checkable: the tool named here checks it.

The meaning is the one sentence a reviewer reads to decide whether the grant fits the role: a name alone carries no boundary. Two permissions with the same name pattern and no meanings drift into overlapping grants that no audit can separate.

permission/submit-expense carries "Submit an expense for reimbursement."

Checked bylitespec model check reports record-invalid for a permission without meaning.

Marked checkable: the tool named here checks it.

A grant without a named reach is decided in code: each check looks up the reach beside the permission list, and code then holds a second list of permissions.

permission/manage-copies carries scope: platform, the same level as the librarian role that grants it.

Checked bylitespec model check fails a permission entry without scope.

Marked checkable: the tool named here checks it.

The two parts answer the access questions together: what grant the call checks and which tenant reach the call has. A use case without one part leaves that question to code, and two implementations of the same page enforce different boundaries. The door the call arrives through declares how the caller proved identity.

Checked bylitespec model check reports record-invalid for a use case without access, grant, or tenant.

Marked checkable: the tool named here checks it.

The auth kind tells a reviewer how the caller proves identity before the grant is checked: a session for a signed-in person, a device for a managed scanner, a link for a single-purpose link, an app for a calling application, a token for a bearer token, and none for open calls. Without a declared kind, open calls and authenticated calls look alike, and a reviewer cannot tell which identity the grant was checked against.

An expense submission names session, a self-checkout kiosk names device, and a public catalog names none.

Checked bylitespec model check reports field-invalid for an auth kind outside session, token, device, link, app, and none.

Marked checkable: the tool named here checks it.

The grant is the check the call passes: a permission for role-held action, a self grant for action on records the caller owns, anonymous for open calls, and system for work with no caller. A grant outside these four forms gives the checker no stated check to enforce, and each caller invents its own test.

permission/manage-copies for staff work, self(permission/read-loans) for a reader reading their own loans, anonymous for a public catalog, and system for a self-checkout handler acting for the device.

Checked bylitespec model check reports field-invalid for a grant outside permission, self, anonymous, and system, and reference-unknown for a permission no record defines.

Marked checkable: the tool named here checks it.

A target that must equal the caller is a value the caller could forge: each handler would compare it with the verified identity, and each comparison is authorization logic in a handler. Carrying no target leaves nothing to forge, and the call acts on the caller from verified claims. Where the target must stay on the message, a self grant states the scope beside the use case, and the guard enforces it.

"My loans" lists the signed-in reader's loans and takes no reader id.

Reviewed forWhich use cases with a self grant name a caller-owned target in their inputs without a self declaration the guard enforces, or compare the caller with a target in a handler? Look at the inputs and handlers beside the self grants.

Marked guidance: a reviewer answers this question.

The tenant scope bounds which tenant data the call may touch: own stays inside the caller tenant, cross reaches across tenants, public works beyond tenant boundaries, and none touches no tenant data. Without the scope, a read inside one tenant and a read across all tenants look the same, and the widest reach hides in the narrowest grant.

An expense report names own, a staff search across tenants names cross, a public catalog names public, and a health check names none.

Checked bylitespec model check reports field-invalid for a tenant scope outside own, cross, public, and none.

Marked checkable: the tool named here checks it.

An entitlement allows one tenant what another is refused, so the grant alone reads as unequal treatment. Citing the setting or plan shows the commercial or configured reason behind the difference, and gives the reviewer the range and setter to judge it against.

A submit command cites setting/spending.receipt-threshold, so an expense above the line with no receipt is refused by the policy setting rather than by role.

Reviewed forWhich entitlement grants lack a cited setting or plan? Look at the grant beside the settings each use case cites.

Marked guidance: a reviewer answers this question.

Patterns compose the same access parts into wider reach, so prose alone cannot show where the wider grant stops. Scenarios that walk an allowed call and a refused call pin the boundary as checked facts, and the checker confirms each one through the public boundary.

A delegation story shows an assistant acting for a manager succeeding, and the same assistant acting without delegation ending in the derived forbidden result.

Reviewed forWhich hierarchy, trust, or delegation patterns lack an allowed and a refused scenario? Look at the scenarios on the use cases that carry the pattern.

Marked guidance: a reviewer answers this question.

Inside one tenant, delegation changes who holds a role for a time, not which grant forms exist. Recording the assignment with its window on an aggregate the access model reads gives the authorization guard one stated source for the deputy, the role, and the dates, and the granting and revoking use cases make the start and the end reviewable acts. A use case acting under the assignment declares its permission as usual, so no new access form appears. The tenancy extension adds only the cross-tenant form of delegation; it adds no form inside one tenant.

In Claimwick, a manager delegating team management to a deputy for 2026-12-20 to 2027-01-05 is recorded as an assignment of the manager role to the deputy with validFrom of 2026-12-20 and validUntil of 2027-01-05, granted by its own grant use case and ended by its own revoke use case. The manage use case acting under it still declares permission/manage-team.

Reviewed forWhich delegated or temporary grants inside one tenant lack a role assignment with validFrom and validUntil on an aggregate the access model reads, or lack their own granting and revoking use cases? Look at the assignments beside the actor holds and the use cases that act under them.

Marked guidance: a reviewer answers this question.

Delegation lets one actor act for another, so a grant on one side alone leaves the other side unreviewed. Declaring the grant on both sides shows who may delegate and who may be acted for, and the tenancy extension states the fields each side carries.

An assistant acts for a manager only where the manager delegation grant and the assistant acting grant both name the pairing.

Reviewed forWhich cross tenant delegation grants lack a declared grant on both sides? Look at the delegation grants the tenancy extension declares.

Marked guidance: a reviewer answers this question.

The kind tells a reviewer how callers arrive: a browser serves people, an api serves callers over a boundary, a webhook receives inbound events, a device serves a managed scanner, a cli serves operators, an mcp channel serves a model, and served content serves a static file. Without the kind, a webhook and a page look alike.

The library app carries browser, and a kiosk handshake carries device.

Checked bylitespec model check reports record-invalid for an entry point without kind and field-invalid for a kind outside browser, api, webhook, device, cli, mcp, and served-content.

Marked checkable: the tool named here checks it.

Served content is a file the product hands out, not behavior it runs, so the serving fields are the whole contract: where it lives, what it is, how long it caches, how it versions, and which requirement it carries. Without them, a legal text or a static script ships as an unreviewed file with no stated requirement or freshness.

A terms text carries its path, text/html, its cache window, its version rule, and the requirement it fulfills.

Checked bylitespec model check reports record-invalid for a served content entry point without path, contentType, cacheControl, versioning, or fulfills.

Marked checkable: the tool named here checks it.

Each operation is one edge to outside behavior the product does not control. Without the declared list, a new outside call ships as an unreviewed dependency with no stated edge to review. Each operation carries its direction, timeout, response, and cache, as Describe Every External System Operation states.

A payout bank declares a settle-batch operation with its timeout, timeout handling, and response shape, which the payout effect cites as calls.

Checked bylitespec model check reports record-invalid for an external system without operations and reference-unknown for a calls edge naming no declared operation.

Marked checkable: the tool named here checks it.

Personal data sent outside stays outside unless some operation or event removes it, so the erasure declaration states the call, the integration event, or why removal is impossible. An impossible erasure cites the Intent decision that accepts the limit, so the gap reads as an accepted decision rather than a missed edge.

A payout archive declares {"mode": "impossible", "reason": "settled payouts belong to the bank"} with the decision that accepts the limit, plus the sentence employees see.

Checked bylitespec model check reports record-invalid for an external system without erasure and reference-unknown for an impossible erasure without an Intent decision.

Marked checkable: the tool named here checks it.

The summary states in plain sentences who the party is and what the grant is for, which the fields alone do not say. A reviewer meets the story first and the fields after, so the grant reads as a decision rather than a row.

Checked bylitespec model check fails an actor or role page without summary.

Marked checkable: the tool named here checks it.

The summary states in plain sentences what the outside system does for the product, which the message lists alone do not say. A reviewer meets the relationship first and the messages after, so the dependency reads as a decision rather than a row.

Checked bylitespec model check fails an external system page without summary.

Marked checkable: the tool named here checks it.

The file holds entries only: each permission is one row with its fields, and prose around them would restate the meanings the entries already carry. A file with entries only stays readable as a list even as entries grow.

Reviewed forWhich module permissions files carry an explanation file? Look beside each permissions file for a .md file with its name.

Marked guidance: a reviewer answers this question.