machine .toml source > generated view > drift gate

Record indexes

Module and importer record types

Beyond the twelve baseline types, eight record types ship in four optional modules, one type belongs to the importer alone, and two names are reserved.

About

Modules are base-level optional capability bundles, default-off, each enabled by one manifest edit. Enabling a module makes its types valid to declare, each with its normative namespace; a module-tier type declared without its module enabled is a validation failure.

Why

Not every project needs delivery assurance or operational-policy records on day one. Default-off modules keep the baseline small while keeping the extended vocabulary standard: when a project grows into a capability, the types, namespaces, and states are already defined, so no adopter invents an incompatible local variant.

Description

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
Importer-only (no module toggle)
  legacy_fragment     LF   quarantined > resolved | ignored
Reserved
  transaction         TX   excluded from the adopter standard; name and namespace reserved
  (none)              CL   reserved unassigned, so it can never half-collide with "changelog"

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.

How it works

legacy_fragment is created only by an importer, never scaffolded: everything an import cannot confidently map becomes quarantined fragment data with source path, digest, span, and run ID, so nothing is dropped. The scaffolded counters file already carries the LF namespace at zero, so a fresh store can accept quarantine imports without a schema change.

Generated view

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.

Value

Growth without fragmentation: capability arrives as a reviewed manifest edit with standard semantics, which helps prevent per-project dialects of the same operational ideas.

Usage

  • Enabled by: one manifest edit per module, under the adopter's own review flow.
  • Created by: process, once enabled; legacy_fragment by opf import alone.
  • Read by: opf doctor (module-toggle validity: a declared module type requires its enabled module); the AIQT profile, which requires the governance, operational-policy, and concurrent-operation modules.