A statement is one testable requirement, extracted from an RFC and stored as its own row. Statements — not documents — are what agents query and what CI findings cite.
The statements table on an RFC page, showing level, statement text and slug for each extracted requirement

​
When extraction runs

Automatically on approval, and again whenever a new revision of an approved or enforced RFC is saved. A domain owner can also re-run it manually with Extract statements on the RFC page. Extraction uses your organisation’s configured LLM — see Settings → LLM. A draft RFC has no statements; that is expected.

​
What a statement carries

​
Slug stability

Slugs never change once assigned. This is the property everything else depends on.
Re-extraction reuses the existing slug whenever a statement is materially unchanged — reworded, moved to a different section, tightened for clarity. New slugs are minted only for genuinely new requirements. The consequence is that a violation recorded in March still resolves to the same statement in November, after two rewrites of the RFC around it. Without stable slugs your violation history becomes unreadable the first time someone edits a heading. When a requirement is genuinely removed, its statement is marked retired, never deleted. Historical findings still resolve; the statement simply stops being served to agents.

​
SDLC stage

Each statement is tagged with the point in the software lifecycle where it applies:

design

Applies while a change is being designed — architecture, interface shape, data model.

implementation

Applies to the code itself. The bulk of statements land here.

review

Applies at code review — things a reviewer should check rather than a linter.

ci

Applies to the pipeline: required checks, build configuration, artefacts.

operations

Applies to running systems — deployment, monitoring, incident handling.
Agents filter on this. A design-review agent asking for sdlc_stage=design gets the handful of statements relevant to it rather than the entire corpus.

​
Querying statements

Both default to enforced statements. Pass status=approved to include advisory ones. Filters available: domain, level, sdlc_stage, status. See MCP server and REST API.

​
Getting good extraction

Extraction quality is downstream of writing quality. If statements come out vague or duplicated, fix the RFC rather than the extractor:
  • One requirement per sentence
  • One uppercase keyword per requirement
  • A named subject — “Every public API schema MUST…”, not “It MUST…”
  • Meaningful ## headings, since they become the section
See RFC 2119 keywords for worked examples.