ENTRY — Library primitive v1

An ENTRY is one earned, human-readable account joined to a small machine-checkable receipt. It preserves meaning across goal turnover without becoming authority for the facts it cites.

ENTRY = body + receipt + anchors + refresh

Package

library/<room>/<slug>/
  README.md
  entry.json

README.md is the body. entry.json is the receipt. They are one primitive: the body without a receipt is not cataloged, while a receipt without a readable body fails validation.

The v1 JSON contract is catalog/entry.schema.json. The format value is corpus-library-entry/v1.

The body carries meaning

The body answers the later reader’s actual question. A work-arc entry should make What, Why, Where, Standing, Span, Movement, Outcome, and Next/Reopen recoverable in one bounded read. Other future entry kinds may use a different body shape, but must still explain why the item earned keep.

The body may synthesize. It may say that two authorities disagree, that an accepted implementation did not validate a stronger product claim, or that a tool survives a shelved arc. It may not silently choose a cleaner status than the evidence supplies.

The receipt carries checkable claims

Field	Purpose
`slug`, `room`, `kind`, `title`, `summary`	Stable navigation and compact catalog display
`body`	Repo-relative path to the beside-manifest `README.md`
`maintenance`	`event-driven`, `periodic`, or `frozen`; never a scheduling authority
`observed_at`	Time at which the whole receipt was last checked
`standing`	Separate disposition, delivery, and evidence readings, each with basis and observation time
`frontier`	Current major frontier or closure/reopening condition, compact enough for navigation
`membership`	Explicit declared members plus the enrollment rule
`anchors`	Named object, path, commit, and HTTP(S) pointers that must resolve
`observations`	Allowed scalar fields copied from owning objects solely so drift can be detected
`refresh`	Exact commands a folk may choose to run; the checker never executes them
`tags`	Low-authority navigation words

The receipt does not hold object bodies, inferred relationships, transcript excerpts, diffs, private source content, or a replacement lifecycle.

Three readings, not one status

Each standing branch has a label, detail, basis, and observed_at:

disposition says whether the whole item is live, held, settled, shelved, superseded, or unknown, on the authority that can actually dispose it;
delivery reports the owning work stores without letting fulfillment keep a shelved product alive;
evidence reports support, contradiction, incompleteness, or uncertainty for the claims that matter.

The labels are readings for navigation, not new store states.

Anchor rules

object targets use a shipped Corpus ID such as FIND-760 or REQ-281 and are resolved against the owning SQLite store.
path targets are repo-relative, must remain inside the repository, and must exist. A transient external worktree belongs in prose with its observation time, not as a durable path anchor.
commit targets are 7–40 hexadecimal Git commit names and must resolve.
url targets must be well-formed HTTP(S) locations. V1 checks syntax but performs no network fetch.

The checker also resolves local Markdown links and every supported Corpus ID written in the body. A pointer that cannot be supported stays out or is named as unknown in prose; it is not weakened into a silent warning.

Observation and drift rules

An observation is a deliberately small copy of one allowed owning-store field, for example:

{
  "target": "REQ-281",
  "field": "status",
  "value": "implemented_pending_review"
}

Its purpose is to make staleness loud. When the owning row moves, check reports drift and render refuses. The store wins; the manifest does not roll the store back. A folk then refreshes the evidence and either recuts the body because its whole reading changed or updates only the observation when the movement was immaterial to the account.

Do not watch every mutable field. Watch the few fields whose movement could make the catalog or standing lie.

Qualification

An item earns an ENTRY when all are true:

a later holder has a concrete recovery question that exact objects alone do not answer cheaply;
the boundary can be declared without inferred membership;
material claims have resolving evidence;
the account changes a future reading or decision, rather than merely restating a ledger;
someone can name the event that should cause refresh.

No quota exists. A small Library with high recovery value is healthier than a complete catalog of everything that happened.

Formation flow

# 1. Read exact sources and form README.md plus entry.json.

# 2. See the explicit set without loading bodies.
python house/offices/archivist/library_catalog.py list

# 3. Resolve the contract, evidence pointers, and observations.
python house/offices/archivist/library_catalog.py check

# 4. After a clean check, regenerate navigation.
python house/offices/archivist/library_catalog.py render

# 5. Prove the generated surface and live readings still agree.
python house/offices/archivist/library_catalog.py check

render changes only generated catalog Markdown. It never edits an entry body or receipt.

Correction rule

Name what moved: evidence, contract, or review standard. Earlier language stays recoverable through Git. Recut the account on material boundary, approach, evidence, disposition, or major-frontier movement. Do not churn it after every job event, and do not preserve a stale “live” label merely because it was true when an earlier proposal was written.

Authority boundary

SQLite and its shipped mouths own lifecycle facts. Tendril owns recorded relations. Eyes owns acceptance against a done-line. Git owns source history. Archive bundles own their cold bytes. The Human owns reserved judgments.

The ENTRY owns one thing only: a recoverable reading of those named surfaces.