Three load-bearing invariants

PETROVA upholds twelve meta-rules (MR-1 through MR-12). Three are load-bearing — without them, the system falls apart even if the others hold. This page gives each one a concrete example drawn from PETROVA’s own evolution.

MR-7 — decisions are dated, append-only, in-repo

A decision doc has a date in its filename, a Status: field, and a sign-off block. Once closed, it is not edited. Supersession is via a new dated doc with Supersedes: pointing back.

Concrete example from PETROVA’s evolution:

The 2026-04-29 control-plane decision was opened in open status with <<pending>> as the human countersign. After all eight tasksets shipped, the operator countersigned it — and that countersign was the only edit permitted to the closed-side doc. The status flipped from open to closed. The body content stayed identical.

If we’d silently rewritten the rationale section after seeing how the tasksets actually played out, future readers would have no way to know the decision as it stood when it was made vs as it sounds in retrospect. MR-7 prevents that drift.

The verbs that emit decision docs (open_decision, close_phase, start_phase, verify_round) all enforce MR-7 mechanically: they write a new dated file rather than editing existing ones.

MR-10 — verification rounds are mandatory at phase close

Every phase, regardless of how smooth, runs a verification round before closing. Even if the round surfaces nothing, it must record that fact (the ROUND-CLEAN sentinel item).

Concrete example from PETROVA’s evolution:

When TASKSET 8 wrapped, the human’s instinct was “everything passed, just close it.” MR-10 prevented the shortcut. The verify_round verb requires non-empty items[] — a clean round still has to enumerate what was checked and assert no friction surfaced, with at least one item describing what was inspected.

Without MR-10, smooth phases would close without paper trails, and “smooth” would silently start meaning “nobody looked.” MR-10 makes the act of looking an artefact.

MR-12 — CLAUDE.md is a projection, not a source

The CLAUDE.md at any consumer repo’s root projects from grounded sources (docs/north-star/, docs/spec/, MILESTONES.md). It does not introduce facts of its own.

Concrete example from PETROVA’s evolution:

When this documentation site was scaffolded (Increment A), the sync script was deliberately built to project from spec/verbs/*.json, core/templates/META-RULES.md, docs/decisions/, and other source files. Every generated page carries source: frontmatter pointing back to its origin.

If a verb’s schema changes, the doc page changes on the next sync. There is no “documentation that gets out of date” — the source IS the spec, and the doc site is one of many projections of it.

This is enforced for all of docs/site/generated/ by convention: hand-editing those files is forbidden by docs/site/_meta/conventions.md.

Why these three specifically

The other nine MRs are scope-shaping or methodology-clarifying. These three are substrate — they make the audit trail real.

• Without MR-7, the audit trail can be silently rewritten.
• Without MR-10, the audit trail can have holes.
• Without MR-12, the audit trail can drift from reality.

Together they’re what makes “every action becomes a reviewable PR with a stable audit trail” actually true rather than aspirational.

See also

• Meta-rules index — all 12 MRs.
• Changing an MR — the process when an MR itself needs to evolve.
• Why a thin centre — how these invariants shaped the architecture.