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.

Actor, role, and external system pages sit under docs/domain/actors/, docs/domain/roles/, and docs/domain/systems/; permission and entry point entries sit in docs/domain/permissions.md and docs/domain/entry-points.md.

Marked guidance: a reviewer answers this question.

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

An employee actor carries person, and a payout service carries system.

litespec model check reports record-shape for an actor without kind and invalid-field for a kind outside person, organization, and system.

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.

Each actor page under docs/domain/actors/ names in holds every role the actor acts through, with the scope of each grant.

Marked guidance: a reviewer answers this question.

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.

litespec model check reports record-shape for a role without scope and invalid-field 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 need its permissions. 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 needs.

litespec model check reports record-shape for a role with no allows entry.

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 approval."

litespec model check reports record-shape for a permission without meaning in docs/domain/permissions.md.

Marked checkable: the tool named here checks it.

The kind tells a reviewer how callers arrive: an app serves people, an api serves callers over a boundary, a cli serves operators, and a job or reaction runs without a request. Without the kind, interactive operations and background work look alike.

The web shop carries app, and the nightly export carries job.

litespec model check reports record-shape for an entry point without kind and invalid-field for a kind outside app, api, cli, job, and reaction.

Marked checkable: the tool named here checks it.

The actor link attributes everything the system does to a party the access records know: journeys, holds, and permissions all start from actors. A system with no actor acts in the product as nobody, and its messages enter use cases with no stated party behind them.

The text gateway names actor/reader as its actor.

litespec model check reports record-shape for an external system without actor.

Marked checkable: the tool named here checks it.

The sends list bounds what flows out of the product: each entry names one message the product hands to the outside system. Without the list, a new outbound message ships as an unreviewed dependency on behavior the product does not control.

The text gateway names "Overdue notices" in sends.

Each page under docs/domain/systems/ names in sends every message the product hands to that system.

Marked guidance: a reviewer answers this question.

The receives list bounds what flows into the product: each entry names one message the product accepts from the outside system. Without the list, a new inbound message arrives as unreviewed input to behavior the reviewers approved without it.

The text gateway names "Delivery receipts" in receives.

Each page under docs/domain/systems/ names in receives every message the product accepts from that system.

Marked guidance: a reviewer answers this question.

Outside systems fail on their own schedule: the record states what the product does until they answer, such as queueing work or refusing with a named result. Without the stated behavior, each caller invents its own fallback, and one outage produces as many behaviors as callers.

The text gateway states "Notices queue until the gateway answers." in failure.

Each page under docs/domain/systems/ states in failure what the product does until the system answers.

Marked guidance: a reviewer answers this question.

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.

litespec consumer fails an actor or role page without an H2 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.

litespec consumer fails an external system page without an H2 Summary.

Marked checkable: the tool named here checks it.

The lists hold entries only: each permission and entry point is one row with its fields, and prose around them would restate the meanings the entries already carry. A list with no body section stays readable as a list even as entries grow.

docs/domain/permissions.md and docs/domain/entry-points.md hold entries with no H2 body section.

Marked guidance: a reviewer answers this question.