Operational records, governed like code
Operational records, with checks for schema and view drift.
Use structured operational records and configured checks with the aim of improving consistency. Review recorded claims against their evidence: schema and drift checks do not establish factual accuracy. Under the hood: machine-written TOML paired with generated human-readable views, checked by a drift gate when you configure it as a required commit or CI check.
Generated by opf render --write. Do not edit; edit the store and regenerate.
BACKLOG
BI-1active Add the drift gate to CI actionable
Illustrative excerpt. The source on top is what your tools and assistants write. The view below is what your people read. When configured as a required check, a gate compares the view with a fresh render of its sources.
The model
Three parts. One record, with a configurable drift gate.
backlog_item.index.tomlBACKLOG.mdThe source leads to the view: every view is regenerated from its declared sources, never edited by hand. Configured as a required commit or CI check, the gate re-renders and compares the bytes; if the source and the view disagree, the build fails.
See it in one file
Edit the source. Run the renderer. Check the view.
Generated by opf render --write from backlog_item.index.toml and block.index.toml. Do not edit; edit the store and regenerate.
BACKLOG
BI-1active Add the drift gate to CI actionable
You edit the TOML. The Markdown is generated. When configured as a required check, the gate compares the view with a fresh render of its sources.
Who it is for
Built for the people who set the standard, and the people who work to it.
For leaders and decision-makers
Use one recording standard across projects, teams, and AI assistants, and configure its checks in your review pipeline. The aim is a shared operational record you can cite in a review, an audit, or a handover.
For individual developers
Edit the TOML, regenerate the declared views, and run the drift check to compare their bytes. The aim is less time chasing stale docs and reconstructing context, with a shared records-first process.
Start with a structured record
For vibe coders
OPF defines record schemas and checks for malformed records and source-to-view drift. Ask your assistant to use them, and review the recorded claims against their evidence. The aim is to make the project's state easier to inspect from the first commit.
Why it holds up
Check schemas, references, and generated views.
Check for view drift
Configured as a required commit or CI check, the drift gate re-renders declared views from their sources and rejects byte differences. Schema validation and drift checks are intended to catch structural defects; they do not establish that a record's claims are true.
Governed like code
The standard requires a tracked git store and a review flow. Configure its checks in your source pipeline. Released worklog spans and published changelog entries carry recorded digests for detecting changes.
Cite it, not just read it
Typed index records carry a permanent ID and a typed status; links and captured references are optional envelope fields. Capture evidence for claims that depend on external sources. The standard forbids ID reuse and record deletion and requires archived IDs to remain resolvable.
One standard, every assistant
The schemas, status grammar, and gates belong to the standard, not to any vendor's tool or any one developer's habits. Switch an assistant, a contractor, or a team and the recording contract is unchanged.
Machine-written, human-readable
Structured TOML for tools and AI assistants; generated Markdown for people. The intended benefit is less context reconstruction. Measure any change in errors or effort in your own workflow.
One CI step
The standard names the store, the views, and the checks; opf doctor runs the integrity checks as one command you can configure as a required CI step, with the cannot-evaluate residuals listed on the disclosure page.
What is in the box
The baseline types, initial views, and command vocabulary.
The specification defines twelve baseline record types and eight command verbs; the reference scaffold declares thirteen generated views.
12 baseline record types
11 typed indexes plus the worklog ledger, each with a closed schema that refuses what does not fit.
13 generated views
The scaffold declares twelve Markdown views and one TOML projection. Regenerate declared views and check them for byte drift; do not hand-edit them.
8 command verbs
init, import, doctor, render, migrate, sync, upgrade, absorb.
Adopt it
Ask your assistant for a plan. Review it, then authorize.
Let your AI development assistant do the adoption
Ask your AI development assistant to read the standard, inspect your project, and propose an adoption plan naming what it would create, import, or retire. Review that plan before authorizing changes, then inspect the scaffolded store and validation results.
Give your assistant this site's machine-readable entry point (/llms.txt and the adoption guide, /adopt.md) as the starting material.
opf init
opf render
opf doctor
opf upgrade
opf import
opf absorb
opf migrate (planned)
opf sync (planned)
init scaffolds, render regenerates and checks, doctor verifies, upgrade applies the in-place base-schema upgrade, import brings legacy files in, and absorb drafts changelog entries for human curation. migrate and sync are specified but not yet implemented in the reference CLI.
Where next
Pick the door that fits you.
Read the standard
The specification and quickstart: store layout, record model, gates, and what they do and do not establish.
Quickstart
The store layout and the first steps to create and work in a store.
View on GitHub
The source, the reference tooling, and the spec.
Adopter guide
Reference pages for core files and record indexes, plus the manual adoption path.