Operational records, governed like code
Integrity and consistency, built into how your projects run.
Keep every project's operational record accurate and consistent, so your teams and their AI assistants work from one source of truth, gated against quiet drift. 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. A gate checks the view against a fresh render of its sources.
The model
Three parts. One record, gated against drift.
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
You write the source. The view writes itself.
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. The gate checks the view against 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
Mandate one standard and every project, every team, and every AI assistant you use records its work the same way, in a record gated against silent drift, like the code itself. The aim is operational truth you can cite in a review, an audit, or a handover, without reconciling anyone's notes.
For individual developers
Edit one TOML file; the human-readable view regenerates and the gate proves it matches. The aim is less time chasing stale docs and reconstructing context, with the same records-first process on every project you join, whichever assistant or tooling it uses.
A better starting point than most seasoned developers ever had
For vibe coders
Starting a project with OPF (and AIQT) gives you the structure, organization, and integrity most developers never had at the start: your assistant writes into a schema that refuses what does not fit, and the gate catches malformed or drifted records. The aim is a project that stays true to what you meant, from the first commit, without babysitting.
Why it holds up
Integrity you can check. Consistency you can count on.
No silent drift
Configured as a required commit or CI check, the drift gate re-renders every view from its sources and rejects any that disagree. That catches malformed records and source-to-view drift, which reduces errors; it does not make a record true, since a schema-valid record can still say something false.
Governed like code
The record lives in a git repository, changes through review, and is gated in the same pipeline as your source. Released history is frozen by recorded digests.
Cite it, not just read it
Every record carries a permanent ID, a typed status, and captured references. IDs are never reused and records are never deleted, so what you cite today still resolves later.
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. Structured, schema-validated input means less context to reconstruct and fewer places for a confident guess to land.
Open source, drop-in for CI
Apache License 2.0 (except vendored third-party material, which remains under its own terms). The standard names the store, the views, and the checks; the reference tooling runs them as one CI step. Adopt the standard on its own, or as part of AIQT Guardrails.
What is in the box
Every record type, every gated file, counted from the specification.
Twelve baseline record types, thirteen generated views, and seven command verbs, each count taken from the specification rather than asserted.
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
Every declared view is rendered from its sources and byte-gated, so it is read, never hand-edited.
7 command verbs
init, render, doctor, upgrade, import, migrate, sync.
Adopt it
Point your assistant at it. Say yes.
Let your AI development assistant do the adoption
The primary path is one instruction: point your AI development assistant at this site (or the repository) and tell it to adopt OPFiles, or to adopt AIQT. It reads the standard, investigates your project, and presents a short plan: what it will create, import, or retire, and how the pieces wire together. On your yes it carries out the adoption, scaffolds and validates the store, wires the records-first process into your project's assistant instructions, and leaves the .working/ store for your review.
Point your assistant at this site's machine-readable entry point (/llms.txt and a machine-readable adoption guide, /adopt.md) and it reads the standard, inspects your project, and proposes a plan.
opf init
opf render
opf doctor
opf upgrade
opf import
opf migrate
opf sync
init scaffolds, render regenerates and checks, doctor verifies, upgrade migrates a store in place, and import brings legacy files in.
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 steps to a gated store.
View on GitHub
The source, the reference tooling, and the spec.
Adopter guide
Every standard file, what pairs with it, and the manual path if you need it.