machine .toml source → generated view → drift gate

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

.working/toml/backlog_item.index.toml
schema = 1 [[record]] id = "BI-42" type = "backlog_item" status = "active" title = "Add the drift gate to CI"

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.md BACKLOG.md PIPELINE.md

Three composed views draw on this index joined against blocks, all byte-drift-gated and rendering the actionability join. An optional BACKLOG_ITEM-INDEX.md mirror renders the index one-to-one for human reading.

Lifecycle

open → active → done | dropped

Open 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 done creates 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 init opf render opf doctor

Created 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 by opf render and validated by opf 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

.working/toml/done.index.toml
schema = 1 [[record]] id = "DN-42" type = "done" status = "recorded" links = [{ rel = "receipt_of", id = "BI-42" }]

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.md

Composed from this index, plus the optional DONE-INDEX.md mirror; both byte-drift-gated.

Lifecycle

recorded (terminal only)

A single state, no transitions, and never proposable. A ratified backlog done requires 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 init opf render opf doctor

Created 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 by opf render (DONE.md and the mirror) and validated by opf 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

.working/toml/finding.index.toml
schema = 1 [[record]] id = "FN-42" type = "finding" status = "fixed" severity = "major"

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.md

Composed from this index, plus the optional FINDING-INDEX.md mirror; both byte-drift-gated.

Lifecycle

open → fixed | routed | refuted | accepted

Four 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 init opf render opf doctor

Created 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 by opf render (FINDINGS.md and the mirror) and validated by opf 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

.working/toml/pending_decision.index.toml
schema = 1 [[record]] id = "PD-42" type = "pending_decision" status = "decided" decision = "Ship the drift gate in 1.1.0" decided_at = "2026-09-04T09:37:48Z" decided_by = "maintainer"

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.md DECISIONS.toml

The composed DECISIONS.md (drawing on all four decision types) and the machine projection DECISIONS.toml, both byte-drift-gated, plus the optional PENDING_DECISION-INDEX.md mirror.

Lifecycle

open → decided | withdrawn

Both terminal states are proposable: an assistant-recorded resolution lands with the /proposed qualifier 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 init opf render opf doctor

Created 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 by opf render (DECISIONS.md, DECISIONS.toml, the mirror) and validated by opf 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

.working/toml/autonomous_decision.index.toml
schema = 1 [[record]] id = "AD-1" type = "autonomous_decision" status = "recorded" title = "Retry the flaky fixture on timeout" classification = "within standing authority: reversible, internal" action = "added a bounded retry to the fixture setup" actor = { kind = "assistant" }

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.md DECISIONS.toml AUTONOMOUS_DECISION-INDEX.md

The composed decisions view, its TOML projection, and the optional one-to-one mirror.

Lifecycle
recorded

A single state, created terminal and immutable: written at the moment the decision is enacted, awaiting no ratification and carrying no /proposed qualifier. The trail cannot be tidied retroactively; it is overturned only by a new linking record.

Referenced by
opf init opf render opf doctor

init scaffolds the empty index; render composes the views; doctor checks 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

.working/toml/maintainer_decision.index.toml
schema = 1 [[record]] id = "MD-1" type = "maintainer_decision" status = "recorded" title = "Ship the drift gate in 1.1.0" decision = "yes; the gate blocks merge on any view drift" actor = { kind = "maintainer" }

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.md DECISIONS.toml MAINTAINER_DECISION-INDEX.md

The composed decisions view, its TOML projection, and the optional one-to-one mirror.

Lifecycle
recorded

A 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 init opf render opf doctor

init scaffolds the empty index, and migrated history carries importer attribution; render composes the views; doctor checks 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

.working/toml/preference_pattern.index.toml
schema = 1 [[record]] id = "PP-1" type = "preference_pattern" status = "active" title = "Prefer the smallest correct change" context = "when a change could be broadened past its requirement" rationale = "scope creep is where regressions and review cost hide" actor = { kind = "maintainer" }

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.md DECISIONS.toml PREFERENCE_PATTERN-INDEX.md

The composed decisions view, its TOML projection, and the optional one-to-one mirror.

Lifecycle
active → retired

active is the initial, gated state; retired is terminal when a preference no longer holds. Entering the gated state as an assistant or automation takes /proposed until a maintainer ratifies, the same gating mechanism as block and contribution.

Referenced by
opf init opf render opf doctor

init scaffolds the empty index; maintainers record patterns directly and assistants as gated proposals; render composes the views; doctor checks 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

.working/toml/block.index.toml
schema = 1 [[record]] id = "BL-42" type = "block" status = "active" scopes = ["BI-42", "BI-43"]

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.md TODO.md BACKLOG.md PIPELINE.md

BLOCKS.md is composed from this index, and the block join renders inside TODO.md, BACKLOG.md, and PIPELINE.md; an optional BLOCK-INDEX.md mirror completes the set. All byte-drift-gated.

Lifecycle

active (gated) → released | expired

An 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 init opf render opf doctor

Created by opf init (empty index), by maintainers directly, and by assistants as gated proposals; updated by ratification, release, or expiry transitions; read by opf render (BLOCKS.md and the actionability join in the three backlog views) and validated by opf 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

.working/toml/handoff.index.toml
schema = 1 [[record]] id = "HO-42" type = "handoff" status = "current" summary = "Drift gate merged; OPF verbs next"

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.md

Composed from this index, plus the optional HANDOFF-INDEX.md mirror; both byte-drift-gated.

Lifecycle

current → superseded

Posting 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 init opf render opf doctor

Created 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, by opf render (HANDOFF.md and the mirror), and validated by opf 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

.working/toml/reference.index.toml
schema = 1 [[record]] id = "RF-1" type = "reference" status = "recorded" title = "OPF spec, the record envelope" refs = [{ kind = "doc", locator = "OPF-SPEC.md#8", note = "envelope fields" }] actor = { kind = "assistant" }

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.md REFERENCE-INDEX.md

The composed references view and the optional one-to-one mirror, both byte-drift-gated.

Lifecycle
recorded

A 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 init opf render opf doctor

init scaffolds the empty index; render composes the view; doctor checks 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

.working/toml/contribution.index.toml
schema = 1 [[record]] id = "CN-1" type = "contribution" status = "sent/proposed" title = "Drift-gate fix sent upstream" recipient = "peer-project" dedup_class = "drift-gate-fix" content_digest = "sha256:..." delivery = { channel = "pr", ref = "peer/repo#128", sent_at = "2026-09-04T09:37:48Z" } actor = { kind = "assistant" }

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.md CONTRIBUTION-INDEX.md

The composed contributions view and the optional one-to-one mirror, both byte-drift-gated.

Lifecycle
proposed → sent → acknowledged | superseded

Or from proposed straight to withdrawn. Entering the gated sent state as an assistant or automation takes /proposed, the same mechanism as block and preference-pattern gating; a re-send is a new record linking supersedes.

Referenced by
opf init opf render opf doctor opf record

init scaffolds the empty index; render composes the view; doctor checks schema, the delivery-bundle completeness rules, and gated-state legality. opf record creates the record and authors its transitions: the send takes --channel and --delivery-ref and 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

4 optional modules 8 record types + 3 reserved

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.toml

One 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 create authors baseline types only, since the module record schemas have not shipped. Nothing creates legacy_fragment records now: ordinary import is retired and refuses, and the type remains only for existing stores.

Read by
opf doctor

opf doctor for 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.