Give system requirements an upward trace

What the check observes

The current implementation reads active system requirement records and checks whether each has a satisfies entry. Retired, superseded, and rejected records are excluded. Its result wording refers to stakeholder linkage, but this particular predicate is presence-based: it does not independently prove that every target exists, is at the correct level, or is the right stakeholder need.

Example: a system rule has no recorded purpose

# Requirement excerpt after reviewing the relationship
id: SYS-REQ-042
description: "A repeated transaction ID does not create a second charge."
traces:
  satisfies: [STK-REQ-007]

Resolve the finding

1. Read the system behavior and identify the stakeholder outcome or constraint it serves.
2. Inspect the proposed parent's actual content and current lifecycle state before adding the upward relationship.
3. If no accepted parent exists, recover or author a candidate statement of intent and review it under project policy. Do not select an arbitrary existing ID just to populate the field.

Run and interpret

proof audit --check system_requirements_linked --verbose

This is a specification-stage error check. The workflow respects an explicit L1 skip. With no active system requirements, there is no system population for this predicate to assess.

A clean result is an initial structural condition, not validated stakeholder provenance or proof of correct refinement. Pair it with reference validation, downward obligation coverage, and substantive review. The parent requirement retains authority across implementation tasks; an added link cannot silently authorize changing its promise.

Continue from here

State the governing stakeholder need. Check the rest of the system record.

Bring a system requirement whose reason for existing is unclear. Bring a change to Proof.