Home Features Traceability & standards

One chain, from the user need to the executed test

Every link is stored once, by a stable identifier, and every roll-up is computed on read. Nothing in the chain is maintained twice, so nothing in it can disagree with itself.

The chain

product need  →  requirement  →  design section  →  verification test  →  captured run
                       ↑
        risk control · threat control

A requirement is the hub. It satisfies a product need, is implemented by one or more design sections, and is verified by tests. It may also exist because a risk or a threat needed controlling — and that edge is stored on the risk and the threat, never on the requirement.

Which means it is resolved backwards when the matrix is built. A requirement does not know it is load-bearing. A reviewer needs to be told, and the person editing the requirement needs to be told before they weaken it.

Why identifiers, not names

Every item carries an immutable identifier — r_7f3a9c, d_a12b4c — generated once. Every reference targets that identifier. The human-readable code beside it (AUTH-5, SDD-12) is a label you can rename at will, because nothing points at it.

This is the difference between a trace matrix that survives a reorganisation and one that quietly breaks during it.

Depth, reported apart from breadth

Coverage is the number that flatters. A register can report every requirement verified and still be shallow: nothing recorded as integration testing, no requirement saying which kind of requirement it is, half the units with no acceptance criteria.

So the Traceability view reports the two separately — how many requirements are verified, and then how many reach a design, declare a content category, control a risk or threat, and how many tests exist at each verification level.

Governance is the contract

27 rules, run identically by the editor, the skill and the server, from one implementation — so the three cannot disagree about whether a project is clean. 19 block; 8 report without failing.

The advisory tier exists because a rule that fires on every document in an established register the day it ships teaches people to ignore governance. A project adopts one by naming it in its index, at which point it blocks.

Rule	What it holds	Tier
`traceability`	Every requirement is verified	blocking
`referential-integrity`	References resolve	blocking
`missing-expected`	Tests declare an expected result	blocking
`active-job-open`	Active jobs are open	blocking
`active-job-known`	Active jobs exist in the register	blocking
`prd-referential-integrity`	PRD references resolve	blocking
`prd-coverage`	Every implemented product requirement is satisfied	blocking
`sdd-referential-integrity`	Design references resolve	blocking
`sdd-coverage`	Every requirement reaches the design	blocking
`risk-referential-integrity`	Risk references resolve	blocking
`risk-cause`	Every risk names a contributing software item	blocking
`risk-controlled`	Every risk is controlled or justified	blocking
`soup-identity`	Every component is exactly identified	blocking
`soup-requirements`	Every component has requirements placed on it	blocking
`soup-referential-integrity`	Component references resolve	blocking
`threat-referential-integrity`	Threat references resolve	blocking
`threat-assessed`	Every threat is assessed	blocking
`threat-controlled`	Every threat is controlled or accepted	blocking
`sdd-segregation`	Segregation says why it holds	blocking
`vtp-negative-path`	Requirements are attacked, not only demonstrated	advisory
`sdd-unit-trace`	Requirements reach a unit, not only a view	advisory
`sdd-acceptance`	Units say what verified means	advisory
`risk-sequence`	Risks state the sequence of events	advisory
`srs-category`	Requirements declare their content category	advisory
`srs-security-control`	Security controls say which control they are	advisory
`srs-cites`	Requirements say what they rest on	advisory
`vtp-verification-level`	Tests declare their verification level	advisory

9 document types, one registry

Each is described once. Validation, the schema reference, release snapshots, per-job diffs and the change views all derive from that description, so adding a pillar is a registration rather than a migration.

Type	Document	Shape
`prd`	Product Requirements	register	optional
`srs`	Software Requirements	register	required
`vtp`	Verification Tests	register	required
`sad`	Architecture	prose	optional
`sdd`	Detailed Design	register	optional
`risk`	Risk	register	optional
`soup`	SOUP	register	optional
`threat`	Threats	register	optional
`sec`	Security	prose	optional