Standard 04 · Authority chain

Traceability

Every UI decision, every spec edit, every status row links back to a named authority. No silent changes. No ambiguous ownership. The next reviewer can always reconstruct why something is the way it is.

Authority

Binding markdown

Binding source: 01-STANDARDS/Traceability-Standard.md.

The four traceability surfaces

Where every change leaves a trail

01

Authority chain block

  • Top of every binding doc
  • Lists higher-authority sources in order
  • Reviewer reads it before reading the body
  • Conflicts: higher row wins
02

Author history table

  • Version, date, author, role, change type, summary
  • Every spec/STATUS/report carries one
  • Append-only — corrections become new rows
03

Validation matrix

  • Each invariant tied to its asserting test or doc
  • Lives in the completion report
  • Updated every pass; stale = block release
04

STATUS roll-forward

  • STATUS.md always reflects the latest pass
  • Versioned; never overwritten silently
  • Older rows kept as historical context
No-silent-change rule

The rule that makes the rest possible

Rule: if the implementation diverges from the spec, the spec is updated first. Code-only changes that contradict the binding doc are drift, not progress, and reviewers must reject them.
Why this matters: a future reviewer comes back months later and asks "why is this like this?" The answer must be in the doc, dated, attributed, and tied to an invariant — not a tribal-knowledge guess.
Path doctrine

No local paths in artifacts

Every authored file (markdown, TSX, HTML, MJS) carries a standardized header with Module, File, Authority Level, Status, and a Repo / GitHub Source block. Local absolute paths (/Users/…, ~/…, <HOME>/…) are forbidden — they leak machine state into shared artifacts.

A forbidden-prefix grep is part of the publish gate. Authority: unit-lab/_standards/global-header-path-doctrine.md.