Reference
Record indexes
Eleven baseline typed indexes, their declared generated views, and the planned module schemas. The examples show inline storage; the specification also defines per-record storage, which the reference renderer does not support. Lifecycle descriptions state the standard's rules; they do not imply an automatic writer for each transition. Choose a type to inspect.
Record index
The backlog
backlog_item.index.toml
namespace BI
.working/toml/
One record per unit of planned work, with a permanent ID, a closed set of states, and a "done" that is ratified, not felt.
Template
Illustrative excerpt: the envelope fields (created_at, updated_at, actor) are omitted for brevity.
The shared index shape is schema = 1 plus [[record]] rows. The envelope requires id, type, status, title, timestamps, and actor.kind (maintainer, assistant, automation, or importer). Timestamps use RFC 3339 UTC; an importer may omit an unknown created_at with provenance. Optional fields include summary, proposed_from (present only on a /proposed status, written by opf record transition), links, refs, and registered x-<vendor> extensions. Links use the closed vocabulary supersedes, resolves, remediates, receipt_of, corrects, follows, relates, exemplifies, and derives_from. References identify a path, URL, or document. Schemas are closed; unknown keys are validation findings.
The problem it solves
Give planned work explicit identities and completion rules.
The standard gives each item a permanent ID, closed states, and ratification rules: an assistant or automation terminal transition lands with /proposed, and only a maintainer removes the qualifier. Blocked-ness is derived from active blocks at render time; the result still depends on the recorded blocks being current.
- Pairs with
-
TODO.mdBACKLOG.mdPIPELINE.mdThree composed views draw on this index joined against blocks, all byte-drift-gated and rendering the actionability join. An optional
BACKLOG_ITEM-INDEX.mdmirror renders the index one-to-one for human reading. - Lifecycle
-
open→active→done|droppedOpen may go straight to dropped. No resurrection: a record in an unqualified terminal state never re-enters a working state, so a revived concern is a new record linking the old one. A ratified
donecreates a one-to-one completion receipt in the done index, and an item is actionable while open or active, not importer-authored, and with no unqualified active block from a non-importer actor scoping it. An importer-authored item is imported history: it is never actionable, whatever its recorded state. - Referenced by
-
opf initopf renderopf doctorCreated by
opf init(empty index), then records by process as work is planned; updated by state transitions under the status grammar and maintainer ratification of proposed terminals; read byopf renderand validated byopf doctor(schema validity, ID uniqueness, transition legality where observations suffice, no-resurrection). Actor-dependent transitions with an unidentified last-transition actor and rejections requiring unavailable pre-proposal state report cannot-evaluate.
What it protects
A ratified "done", not a felt one
The intended benefit is reviewable completion: the standard requires a ratified transition and a durable receipt. The checks validate the recorded relationship, not whether the work was actually completed.
Record index
Completion receipts
done.index.toml
namespace DN
.working/toml/
A durable completion receipt, created in its single terminal state and immutable from birth, linked one-to-one to the backlog item whose ratified completion it witnesses.
Template
Illustrative excerpt: title, created_at, updated_at, and actor are omitted for brevity.
The shared index shape (schema = 1 plus [[record]] rows) with the standard envelope and no type-specific extra fields. The single state is recorded, with no transitions and never proposable: a factual receipt awaits no ratification, so it carries no /proposed qualifier. It links receipt_of to the backlog item it witnesses; a standalone receipt is legal only for imported history with provenance.
The problem it solves
Completion needs its own artefact.
If "done" were only a state flag on the backlog item, the moment of completion, who ratified it, and what it covered would be reconstructable only from history. A separate immutable receipt makes each completion a first-class, linkable fact.
- Pairs with
-
DONE.mdComposed from this index, plus the optional
DONE-INDEX.mdmirror; both byte-drift-gated. - Lifecycle
-
recorded(terminal only)A single state, no transitions, and never proposable. A ratified backlog
donerequires a receipt in the same act, one to one; imported standalone receipts require provenance. Receipts may rotate under manifest-declared thresholds, preserving their IDs and archived content. - Referenced by
-
opf initopf renderopf doctorCreated by
opf init(empty index), by the ratified-done transition, and, as migrated history with provenance, by import (the reference CLI's retired importer, or post-adoption import, which the reference CLI does not implement yet); never updated, since records are immutable, though rotation relocates aged receipts to the archive; read byopf render(DONE.md and the mirror) and validated byopf doctor(schema, uniqueness, the one-to-one receipt link).
What it protects
A linkable completion record
The intended benefit is a linkable completion record. Native receipts witness ratified backlog completion; imported standalone receipts instead rest on provenance. Neither a receipt nor its view establishes that the recorded work occurred.
Record index
The finding register
finding.index.toml
namespace FN
.working/toml/
An observation worth acting on: something wrong, suspicious, or worth noting, that links its remediation rather than containing it and leaves open for exactly one of fixed, routed, refuted, or accepted.
Template
Illustrative excerpt: title, created_at, updated_at, and actor are omitted for brevity.
The shared index shape with the standard envelope plus one type-specific field, severity. Links typically carry remediates toward the backlog item or change that fixes the finding; refs capture the evidence (a path and line, a URL, or a document and section) at the moment the claim is made.
The problem it solves
Record defects with permanent IDs and explicit outcomes.
The standard requires severity grading at or after the fix decision. An assistant or automation terminal transition carries /proposed until maintainer ratification.
- Pairs with
-
FINDINGS.mdComposed from this index, plus the optional
FINDING-INDEX.mdmirror; both byte-drift-gated. - Lifecycle
-
open→fixed|routed|refuted|acceptedFour terminal outcomes, all proposable: fixed (remediated), routed (sent to its real owner), refuted (the observation did not hold), accepted (a recorded decision to live with it). No resurrection: a concern that returns is a new finding linking the old one.
- Referenced by
-
opf initopf renderopf doctorCreated by
opf init(empty index) and by whoever observes a defect, human or assistant; updated by resolution transitions, maintainer ratification, and severity grading at or after the fix decision; read byopf render(FINDINGS.md and the mirror) and validated byopf doctor(schema, uniqueness, transition legality where observations suffice). Actor-dependent transitions with an unidentified last-transition actor and rejections requiring unavailable pre-proposal state report cannot-evaluate.
What it protects
A register with explicit outcomes
The intended benefit is to keep findings visible until a recorded resolution. Permanent IDs and explicit outcomes make the record inspectable; they do not establish that every real defect was recorded or resolved.
Record index
Pending decisions
pending_decision.index.toml
namespace PD
.working/toml/
A question that must be answered before dependent work settles: open until decided or withdrawn, with an all-or-none resolution bundle.
Template
Illustrative excerpt: title, created_at, updated_at, and actor are omitted for brevity.
The shared index shape with the standard envelope plus the resolution bundle fields: decision, decided_at, and decided_by. An open decision carries none of the three; a decided one carries all three. A decided record may be superseded by a new decision linking supersedes; the decision-resolution join walks that chain to find the current effective resolution.
An importer-authored decision is imported history: the join never makes it the current effective resolution, and its supersedes links take no decision out of current authority, so a non-importer decision it supersedes stays current. A new non-importer decision that supersedes an importer-authored one is the current effective resolution of its chain. The chain is every decision its supersedes links connect, through any decision including a proposal, so where importer-authored decisions join non-importer decisions that stay current into one chain, that chain has more than one current effective resolution: opf render stops with a cannot-evaluate before writing any view, and a clean chain beside it is not rendered either. The views read the active index only, not the archive: a chain that runs through an archived decision is evaluated over its active decisions alone, so two current resolutions that only an archived decision joins into one chain are not refused there, although opf doctor reads archived decisions beside active ones when it counts a chain's resolutions.
The problem it solves
Half-recorded decisions are worse than none.
An incomplete bundle omits part of the decision or its attribution. Validation rejects a partial resolution, and the decision-resolution join derives the effective answer through supersession links.
- Pairs with
-
DECISIONS.mdDECISIONS.tomlThe composed
DECISIONS.md(drawing on all four decision types) and the machine projectionDECISIONS.toml, both byte-drift-gated, plus the optionalPENDING_DECISION-INDEX.mdmirror. - Lifecycle
-
open→decided|withdrawnBoth terminal states are proposable: an assistant-recorded resolution lands with the
/proposedqualifier until a maintainer ratifies it. Overturning a decided question is a new record that supersedes the old; the old record is never edited back to open. - Referenced by
-
opf initopf renderopf doctorCreated by
opf init(empty index) and whenever a question is parked for decision; updated by the deciding transition with its full bundle and by supersession from later decisions; read byopf render(DECISIONS.md, DECISIONS.toml, the mirror) and validated byopf doctor(schema, the all-or-none bundle, exactly one effective resolution per chain).
What it protects
Decisions with provenance
The resolution bundle records who decided, when, and what, and the join derives the current effective answer. The intended benefit is fewer stale or contradictory decisions in later work.
Record index
Self-made decisions, on the record
autonomous_decision.index.toml
namespace AD
.working/toml/
A call an actor was authorized to make itself: the classification basis that put it inside that authority, the action taken, and links to what it affected. Created terminal, immutable, and awaiting no ratification.
Template
Illustrative excerpt: created_at and updated_at are omitted for brevity.
The shared index shape with the standard envelope plus two type-specific fields:
classification (the basis that classified the decision as the actor's to make)
and action (what was done). There are no transitions; overturning is always a new
linking record. Because each record is typed and linked, views and audits can walk from any
action back to the authority claim beneath it.
Record autonomous decisions for later review.
The problem it solves
Recording every self-made call with its basis makes autonomous operation reviewable after the fact: a maintainer can audit what was decided under standing authority and overturn anything, not by editing the record, but by a new record or a maintainer decision that links the old one.
- Pairs with
-
DECISIONS.mdDECISIONS.tomlAUTONOMOUS_DECISION-INDEX.mdThe composed decisions view, its TOML projection, and the optional one-to-one mirror.
- Lifecycle
-
recordedA single state, created terminal and immutable: written at the moment the decision is enacted, awaiting no ratification and carrying no
/proposedqualifier. The trail cannot be tidied retroactively; it is overturned only by a new linking record. - Referenced by
-
opf initopf renderopf doctorinitscaffolds the empty index;rendercomposes the views;doctorchecks schema and ID uniqueness. Nothing updates it; it is immutable.
What it protects
The intended benefit is reviewable autonomy: record the basis for each self-made decision and use a new linking record to overturn it.
Record index
Rulings the maintainer made
maintainer_decision.index.toml
namespace MD
.working/toml/
A created-terminal, immutable ruling carrying its decision, the answer plus its rationale. Its actor kind is restricted to maintainer or importer alone.
Template
Illustrative excerpt: created_at and updated_at are omitted for brevity.
The shared index shape with the standard envelope plus decision. A ruling may
link exemplifies to the preference pattern it
instantiates, feeding the distillation of standing preferences from individual rulings. It is
baseline as of spec 1.1.0 (it was module-tier in 1.0.0).
The record, not the conversation, is the source of truth: a ruling made in chat and never recorded did not happen.
The problem it solves
Making rulings a distinct immutable type separates what the maintainer decided from what anyone proposed, and the attribution restriction makes that separation structural: a maintainer ruling with assistant attribution is a contradiction the schema refuses, and importer attribution covers migrated history.
- Pairs with
-
DECISIONS.mdDECISIONS.tomlMAINTAINER_DECISION-INDEX.mdThe composed decisions view, its TOML projection, and the optional one-to-one mirror.
- Lifecycle
-
recordedA single state, created terminal and never proposable: recorded the session it is made, with no transitions. Overturning is a new record linking the old one.
- Referenced by
-
opf initopf renderopf doctorinitscaffolds the empty index, and migrated history carries importer attribution;rendercomposes the views;doctorchecks schema, the actor-kind restriction, and uniqueness. Nothing updates it; it is immutable.
What it protects
The intended benefit is a durable register of the maintainer's rulings. Review the recorded attribution; the schema's actor-kind restriction is not authentication.
Record index
Standing preferences, distilled
preference_pattern.index.toml
namespace PP
.working/toml/
The reusable rule beneath a family of individual rulings, carrying its context and rationale with the envelope's title. It is active until retired.
Template
Illustrative excerpt: created_at and updated_at are omitted for brevity.
The shared index shape with the standard envelope plus context and
rationale. Maintainer decisions may link
exemplifies toward the pattern they instantiate, so the evidence for a pattern
accumulates as links. It is baseline as of spec 1.1.0 (module-tier in 1.0.0).
Use recorded patterns to guide recurring decisions.
The problem it solves
The standard requires an assistant-distilled pattern to carry active/proposed
until a maintainer ratifies it to active. Treat an unratified pattern as a
proposal, not standing policy.
- Pairs with
-
DECISIONS.mdDECISIONS.tomlPREFERENCE_PATTERN-INDEX.mdThe composed decisions view, its TOML projection, and the optional one-to-one mirror.
- Lifecycle
-
active→retiredactiveis the initial, gated state;retiredis terminal when a preference no longer holds. Entering the gated state as an assistant or automation takes/proposeduntil a maintainer ratifies, the same gating mechanism as block and contribution. - Referenced by
-
opf initopf renderopf doctorinitscaffolds the empty index; maintainers record patterns directly and assistants as gated proposals;rendercomposes the views;doctorchecks schema and gated-state legality.
What it protects
The intended benefits are fewer repeated clarifications and explicit standing preferences. Keep assistant-inferred preferences proposed until the maintainer ratifies them.
Record index
Blocks
block.index.toml
namespace BL
.working/toml/
A record that named work cannot proceed: it scopes an enumerated list of record IDs and feeds the actionability rule, so only an unqualified active block hides work; an assistant- or automation-created block stays proposed until a maintainer ratifies it.
Template
Illustrative excerpt: title, created_at, updated_at, and actor are omitted for brevity.
The shared index shape with the standard envelope plus scopes, the enumerated record IDs the block covers. States: active (initial; gated for assistant and automation actors) to released or expired (terminal). Blocked-ness is never stored on the scoped records; it is derived at view time through the block join.
The problem it solves
"Blocked" is one of the easiest states to abuse: it can park inconvenient work indefinitely.
The standard makes a block a scoped, auditable record rather than a mood, and gates its creation: a block created by an assistant or automation is active/proposed, a proposal that hides nothing and justifies no stop until a maintainer ratifies it. The gate applies to assistant and automation actors; an unqualified active block from a maintainer also counts toward blocked-ness. An importer-authored block is imported history and hides nothing, whatever its recorded state.
- Pairs with
-
BLOCKS.mdTODO.mdBACKLOG.mdPIPELINE.mdBLOCKS.mdis composed from this index, and the block join renders insideTODO.md,BACKLOG.md, andPIPELINE.md; an optionalBLOCK-INDEX.mdmirror completes the set. All byte-drift-gated. - Lifecycle
-
active(gated) →released|expiredAn unqualified active block from a non-importer actor hides the records it scopes from actionable views; a proposed or terminal block, and any importer-authored block, hides nothing. The block-actionability join is one of exactly two named joins in the closed transform vocabulary. Active blocks never rotate to the archive.
- Referenced by
-
opf initopf renderopf doctorCreated by
opf init(empty index), by maintainers directly, and by assistants as gated proposals; updated by ratification, release, or expiry transitions; read byopf render(BLOCKS.md and the actionability join in the three backlog views) and validated byopf doctor(schema, gated-state legality, scoped-ID resolution).
What it protects
Blocks you can audit
The intended benefit is an inspectable reason for holding work. The actionability join uses unqualified active blocks; review whether the recorded block is accurate and authorized.
Record index
The session handoff
handoff.index.toml
namespace HO
.working/toml/
The durable state snapshot a session resumes from, current until superseded, with at most one current handoff at any time.
Template
Illustrative excerpt: title, created_at, updated_at, and actor are omitted for brevity.
The shared index shape with the standard envelope and no type-specific extra fields; the handoff's content rides summary, links, and refs. States: current (initial) to superseded (terminal).
The problem it solves
Record the state needed for the next session.
A records-first discipline resumes from the durable handoff rather than starting cold, and the single-current rule means there is never ambiguity about which snapshot is authoritative. A handoff records where the work stands, what is in flight, and what comes next.
- Pairs with
-
HANDOFF.mdComposed from this index, plus the optional
HANDOFF-INDEX.mdmirror; both byte-drift-gated. - Lifecycle
-
current→supersededPosting a new handoff supersedes the previous one in the same act, so at most one current handoff exists; supersession is atomic with posting, the new handoff and the old one's terminal transition landing together. The current handoff never rotates to the archive, and the chain of superseded handoffs remains a readable history of how the work's state evolved.
- Referenced by
-
opf initopf renderopf doctorCreated by
opf init(empty index) and by a new record at each session close or state checkpoint; updated only by supersession, in the same act as the next handoff's posting; read by session resume, byopf render(HANDOFF.md and the mirror), and validated byopf doctor(schema, the at-most-one-current invariant).
What it protects
Continuity across sessions
Resuming from a recorded handoff is intended to reduce context reconstruction and preserve constraints and work in flight. Reconcile it against current state before relying on it.
Record index
Sources, captured at the claim
reference.index.toml
namespace RF
.working/toml/
An immutable captured source, a repository path (with a line where applicable), a URL, or a document and section, recorded at the moment a claim or artefact that rests on it is produced.
Template
Illustrative excerpt: created_at and updated_at are omitted for brevity.
The shared index shape with the standard envelope and no type-specific extra fields; the
captured sources themselves ride the envelope's refs array, each entry
{kind, locator, note} with kind one of path,
url, or doc. This type is the inward counterpart of
contribution, which records what the project proposes or sends out.
A reference reconstructed later from memory is a guess wearing a citation's clothes.
The problem it solves
The standard's rule is capture-at-claim: a record whose claims rest on an external source without a captured reference is unsourced, whatever confidence backs it. Making references a first-class immutable type lets many records share one captured source.
- Pairs with
-
REFERENCES.mdREFERENCE-INDEX.mdThe composed references view and the optional one-to-one mirror, both byte-drift-gated.
- Lifecycle
-
recordedA single state, created terminal, immutable, and never proposable: a captured fact awaits no ratification. Records link toward references rather than editing them, so a source, once captured, stays exactly what was captured.
- Referenced by
-
opf initopf renderopf doctorinitscaffolds the empty index;rendercomposes the view;doctorchecks schema and uniqueness; and any record that links to its captured sources reads it. Nothing updates it; it is immutable.
What it protects
Capture evidence when making a claim so another reader can inspect its source. This is intended to reduce unsupported assertions; the record does not establish source accuracy or continued availability.
Record index
Work proposed or sent to a peer project
contribution.index.toml
namespace CN
.working/toml/
A record of an artefact, fix, or proposal intended for a peer project: the outward counterpart to reference, which records what comes in. It tracks proposal, delivery, and outcome; delivery details become required once sent, while recipient receipt fields are optional and permitted only at acknowledgement.
Template
Illustrative excerpt: created_at and updated_at are omitted for brevity.
The shared index shape with the standard envelope plus recipient,
dedup_class, content_digest, and the delivery bundle
{channel, ref, sent_at, receipt_ref?, receipted_at?}: channel, ref, and sent_at
are required once sent. Before sending, channel and ref may describe planned delivery, but
sent_at is forbidden. Receipt fields are legal only at acknowledged.
acknowledged is the single positive terminal (responded, adopted,
reshaped, or declined); the outcome lives in summary or an extension, never as a
state. A contribution typically links derives_from the internal finding,
decision, or backlog item that motivated it, and carries no fleet-specific semantics; those
ride a registered x-<vendor> extension.
Outbound work is an external action, so its claim, "we sent this", is gated.
The problem it solves
An assistant lands sent/proposed, awaiting a maintainer's ratification that it
was genuinely sent. The standard lets an adopter declare a standing authorization for a named
recipient, which relieves per-send gating; an absent or malformed declaration fails closed. The
reference doctor does not yet read such a declaration, so it treats every assistant or
automation sent as gated.
- Pairs with
-
CONTRIBUTIONS.mdCONTRIBUTION-INDEX.mdThe composed contributions view and the optional one-to-one mirror, both byte-drift-gated.
- Lifecycle
-
proposed→sent→acknowledged|supersededOr from
proposedstraight towithdrawn. Entering the gatedsentstate as an assistant or automation takes/proposed, the same mechanism as block and preference-pattern gating; a re-send is a new record linkingsupersedes. - Referenced by
-
opf initopf renderopf doctoropf recordinitscaffolds the empty index;rendercomposes the view;doctorchecks schema, the delivery-bundle completeness rules, and gated-state legality.opf recordcreates the record and authors its transitions: the send takes--channeland--delivery-refand writes the delivery bundle, and acknowledgement may add a receipt with--receipt-ref. A rejection removes what its proposal wrote.
What it protects
The intended benefit is an auditable record of outbound actions. Review the delivery evidence and any standing authorization; schema validation does not prove a send occurred.
Modules
Optional modules and importer types
Beyond the twelve baseline types, the specification names eight types in four optional modules and reserves three names or namespaces: TX, CL and LF. Modules default off; a manifest edit enables their declarations, while full module record schemas remain planned.
The module and importer types
Governance
One type: maintainer_action (MA), moving open → done | dropped.
Delivery assurance
Four types: artifact (AR, staged → promoted | rejected), gate_run (GR, a recorded three-valued verdict of pass | fail | cannot_evaluate never folded into status), release (RL, planned → published | abandoned), and waiver (WV, active → expired | revoked, expiry required at creation).
Operational policy
Two types: mode (MO, active → retired) and tier_assessment (TA, recorded).
Concurrent operation
One type: session_lease (SL), moving held → released | reconciled.
Reserved namespace
No module toggle: the standard reserves LF unassigned, with no record type on it (spec section 8.1). The reference tooling still recognizes legacy_fragment (LF, quarantined → resolved | ignored) in stores that hold such records from its retired import path; nothing in the reference CLI creates it now.
The full type list
Governance module
maintainer_action MA open → done | dropped
Delivery-assurance module
artifact AR staged → promoted | rejected
gate_run GR recorded, with a three-valued verdict field
(pass | fail | cannot_evaluate), never folded into status
release RL planned → published | abandoned
waiver WV active → expired | revoked; expiry required at creation
Operational-policy module
mode MO active → retired
tier_assessment TA recorded
Concurrent-operation module
session_lease SL held → released | reconciled
Reserved
transaction TX excluded from the adopter standard; name and namespace reserved
(none) CL reserved unassigned, so it can never half-collide with "changelog"
(none) LF reserved unassigned; the reference tooling still recognizes
legacy_fragment (quarantined → resolved | ignored) in stores
holding such records from its retired import path
These are outline state sets; the full module record schemas ship with the module schemas release. The delivery-assurance release record, where enabled, references a version.toml release row by version string: the ledger row is the fact, the record is the delivery-assurance envelope around it.
The standard reserves the LF namespace unassigned and defines no legacy_fragment type (spec section 8.1); the reference tooling still recognizes the type in existing stores and never scaffolds it. Under the reference tooling's retired import contract, everything an import could not confidently map became quarantined fragment data with source path, digest, span, and run ID, so nothing was dropped. Ordinary import is now retired and refuses with exit 2, nothing in the reference CLI creates legacy_fragment records, and the standard directs new imports to the imported series with verbatim unparsed text instead (spec section 8.1); the type remains in the tooling for existing stores and evidence. A new store's counters file has no LF namespace; a store scaffolded by earlier reference tooling may carry LF (at zero, or higher if it imported records), and doctor and re-adoption accept it. That acceptance is the reference tooling's 1.2.0 behaviour and diverges from the standard, whose section 9.2 validation refuses a 1.2.0 manifest as a store. In a store that holds legacy_fragment records, as in a store with module-tier records, doctor reports cannot-evaluate and opf render --write refuses, because the baseline validator does not validate those records' content schemas. Module-type index mirrors are deferred until the module record schemas ship; the reference renderer covers the baseline types today and reports a per-record layout or an unknown view as a clear cannot-evaluate rather than guessing.
The problem it solves
Not every project needs delivery assurance or operational-policy records on day one.
Default-off modules are intended to keep the baseline small while sharing an extended vocabulary. Enabling a module permits its type declarations with normative namespaces; declaring a module type without enabling its module is a validation finding. Enabling it does not supply a missing record schema.
- Enabled by
-
manifest.tomlOne manifest edit per module, under the adopter's own review flow.
- Created by
-
By process, once a module is enabled; the reference CLI's
opf record createauthors baseline types only, since the module record schemas have not shipped. Nothing createslegacy_fragmentrecords now: ordinary import is retired and refuses, and the type remains only for existing stores. - Read by
-
opf doctoropf doctorfor module-toggle validity (a declared module type requires its enabled module); the AIQT profile, which requires the governance, operational-policy, and concurrent-operation modules.
What it protects
Growth without fragmentation
The intended benefit is shared semantics as projects adopt additional record types. A reviewed manifest edit enables declarations; full module record validation and rendering remain separate implementation work.