The requirement tree has four roots, not two — admit PTV-SR-0003, 0004, 0009 and 0011 as premises

Date: 2026-08-12 Status: closed — ratified 2026-08-12 Supersedes: none Superseded-by: none — current Raised by: F-02, docs/decisions/2026-08-12-ptv-scf-0001-p1-verification-round.md Blocks: PTV-SCF-0001 P1 close

Context

P1’s exit gate asserts “every SR traces to root (SR-0001 or SR-0002) or is reclassified.” Six of fourteen do neither.

The relation set in docs/PETROVA-SDD-BASELINE.md §3 is:

0001 contains 0005      0001 contains 0006      0002 contains 0007
0002 contains 0008      0005 derives  0012      0003 derives  0006
0009 derives  0013      0014 refines  0003      0010 refines  0002

Reaching a root: 0005, 0006, 0007, 0008, 0010, 0012. Not reaching one: 0003, 0004, 0009, 0011, 0013, 0014.

§3’s rationale states the intake rule and its justification:

SR-0001 and SR-0002 are the only two requirements with no parent — they are the system’s reason for existing, and everything else derives from them. If a proposed requirement cannot be traced up to one of those two, it does not belong in SR and is almost always an OR (operator discipline) or a DR (domain-specific) in disguise. Intake rule: trace-to-root or reclassify.

Six orphans out of fourteen is a 43% failure rate against an intake rule. A rule that rejects nearly half of what it admitted is more likely to be wrong about the admission criterion than about forty-three percent of the requirements.

What the orphans actually say:

SR	Text (abridged)	Is it a consequence of 0001 or 0002?
`0003`	one declarative registry is the sole authority on which repos are governed	No. Nothing in “the system is the sole path for fleet change” or “every mutation is a reviewable PR” implies a registry, let alone a single declarative one.
`0004`	reads are permitted without authentication and without side effect	No. Both roots are about write. An unauthenticated read surface is a separate commitment, and arguably the opposite commitment.
`0009`	conformance is evaluated at read time, independently of any write invocation	No — and the requirement says so itself. Independently of any write invocation is a statement that it does not descend from the write path.
`0011`	control-loop prompts are served as a versioned service, not carried as copies	No. This is about how law reaches a consumer, which neither root addresses.
`0013`	a value past its freshness budget renders as stale with its age	Yes, via `0009` — but only if `0009` is admitted.
`0014`	project truth in the repo, methodology in the control plane	Yes, via `0003` — but only if `0003` is admitted.

0013 and 0014 are not independently orphaned. They inherit the orphaning from 0009 and 0003, which means the question is about four requirements, not six.

Decision

Ratified 2026-08-12. (Drafted as a proposal; countersigned as recorded at the foot of this record.)

Admit PTV-SR-0003, PTV-SR-0004, PTV-SR-0009 and PTV-SR-0011 as roots, making the root set four premises rather than two, and restate the intake rule as trace-to-a-root or reclassify, with the root set enumerated rather than assumed to be a pair.

The four premises, stated as premises:

0001 · Sole path. No fleet changes a governed repo except through this system.
0002 · Reviewable mutation. Every mutation lands as a PR, never as a push.
0003 · Declared estate. What is governed is enumerated in one declarative registry, and nothing else confers governance.
0004 · Free observation. Reading the estate costs nothing and grants nothing — no auth, no side effect.
0009 · Continuous conformance. Conformance is evaluated at read time, not at write time, so an unconformant repo is visible without anyone invoking anything.
0011 · Served law. Governance law is fetched from a versioned service, never carried as copies.

That is six roots by the numbering above; 0003 and 0004 and 0009 and 0011 are the four being added. Under this ruling every SR traces to a root and gate 4 of P1 passes on the tree as it stands, with no invented edges.

What this makes true: the SR series has an explicit premise set, and a new requirement’s intake question becomes which premise does this serve rather than can I find a path to one of these two. What it forecloses: the claim that PETROVA’s requirement tree has a single write-shaped origin. It does not; it has a write half and an observe half, and the observe half was always there unacknowledged — 0004, 0009, 0011 and 0013 are four of fourteen requirements.

Consequential edits, all append-only:

docs/PETROVA-SDD-BASELINE.md §3 gains a new subsection recording the amended root set and intake rule. §3’s existing rationale paragraph is not edited (MR-7); the subsection states that the paragraph is read subject to it.
No requirement text changes. No requirement is renumbered. No relation is added or removed — the tree’s edges are exactly as authored.
PTV-DR-3104’s missing trace (F-03) is unaffected by this ruling and is a separate one-edge fix; it was deferred pending this record only because the correct target could have moved.

Alternatives considered

Reclassify the four orphans to OR or DR, as §3’s rule instructs — rejected. 0003 would leave the SR series entirely, and it is the requirement 0006 (refuse anything absent from the registry) derives from and the one estate.yaml’s member validation enforces. A requirement that other requirements derive from is a premise by definition; calling it operator discipline would make the tree self-contradictory. 0004 and 0011 are load-bearing on the consumer contract, and 0009 is what the entire console exists to render. This is the option the letter of §3 demands and it is the one that damages the baseline most.
Add trace edges from the four orphans up to 0001 or 0002 — rejected, and this is the option to name explicitly because it is the cheap one. Each edge would be invented to satisfy a gate rather than because the relationship holds. “Reads are unauthenticated” is not contained by “the system is the sole path for fleet change” in any sense that survives being read aloud, and a trace graph with four ceremonial edges is worse than one with four honest orphans — the orphans are visible, the ceremony is not.
Admit only 0003 as a third root, and reclassify 0004, 0009, 0011 — rejected as a half-measure. It fixes the most obvious orphan and leaves the observe half of the system unrepresented in the premise set, which reproduces the same defect at smaller scale. If the tree needs a third root it needs the reason for the third root, and that reason applies to all four.
Weaken or drop P1’s trace-to-root gate — rejected. The gate did its job: it found a real defect in the baseline on its first honest evaluation. Removing a gate because it failed is the failure PTV-SCF-0001’s termination conditions name by hand.
Defer the ruling and close P1 with gate 4 waived — rejected as the primary route. A waiver is legitimate governance, but a waiver on the shape of the requirement tree would be waived into every phase that cites a requirement, which is all of them. Kept as the fallback if FLIGHT wants P2 to start before ruling: waive gate 4 for P1 explicitly, with this record as the named open item.

Consequences

For code:

None. No generator, test or schema reads the SR relation set today. The trace graph lives in a mermaid block in the SDD and is evaluated by reading it.
That is itself a finding worth naming: gate G4 (“every new DR traces to at least one SR; every SR traces to root”) is asserted by CI in the SDD’s own mutation protocol and has no implementation. host/tests/estate.test.ts checks the shape of traces fields and cannot check reachability, because estate.yaml does not carry the SR graph. Recorded as a follow-up, not fixed here.

For docs:

SDD §3 gains an appended subsection; nothing above it is edited.
P1’s gate 4 becomes evaluable as PASS once this record is countersigned. The verification round’s verdict is not retroactively amended — it recorded a FAIL against the tree as it stood, and that was correct at the time.

For phases:

P1 closes on this record plus F-03’s single trace edge, via G-03.
P2 is unblocked by the same act.

For invariants:

No MR added, modified or repealed.

References

docs/PETROVA-SDD-BASELINE.md §3 — the SR catalogue, the relation set, and the intake rule this record amends.
docs/decisions/2026-08-12-ptv-scf-0001-p1-verification-round.md — F-02 as raised, and Part A’s detail on which requirements reach a root.
docs/specs/2026-08-12-ptv-scf-0001-scaffold-rev-a.xml — P1’s exit gate, and the termination condition on weakening a gate to pass it.

Sign-off

Subagent: PTV-SCF-0001 P1 (session 2026-08-12)
Human: Alex Devarno (alex@devarno.com) — countersigned 2026-08-12, instructed in session; transcribed by the agent on explicit direction, not ticked on its own authority. Ratifies the root set as PTV-SR-0001, 0002, 0003, 0004, 0009 and 0011, and the intake rule as trace-to-a-root or reclassify.