What are derived requirements, and how do I keep them true in CI?

NIST calls a derived requirement one that is implied or transformed from a higher-level requirement, and that must trace back. NASA's handbook treats some of those as local design decisions. AcqNotes treats them as shalls that were never written in the stakeholder set, yet are required to satisfy it. Jama stores the link. This page is the file: one testable criterion, one SYS-REQ YAML, a satisfies edge that the audit can re-read.

The matrix H1 lives on requirements traceability matrix. The artefact H1 lives on software requirements specification. The writing-rules H1 lives on the INCOSE Guide for Writing Requirements. This command only accepts a stakeholder requirement ID. Unknown IDs, missing IDs, and IDs that resolve to a system requirement are rejected before any file is written. Empty or non-testable criteria are reported as skipped. FRETish is compiled before YAML is written; a compile failure skips that criterion instead of creating an invalid file.

proof req derive STK-REQ-001 --auto
proof req derive STK-REQ-001 --auto --component policy
proof req derive STK-REQ-001 --auto --format json

On this install the teaching criterion is key revocation: the stakeholder shall says a revoked key is denied everywhere. The miss is the criterion that never became a SYS-REQ, so nothing in CI could fail when the five-second bound drifted.

The teaching stakeholder file is STK-REQ-001 with three acceptance criteria. AC-3 is testable: a revoked key is denied everywhere within five seconds. Until derive runs, there is no system shall for that bound.

id: STK-REQ-001
shall: revoked keys are denied
acceptance_criteria:
  - id: AC-1
    text: a revoked key is rejected at the next request
    testable: true
  - id: AC-2
    text: the audit log records the revocation
    testable: true
  - id: AC-3
    text: the key is denied everywhere within 5 seconds
    testable: true

proof req derive STK-REQ-001 --auto --component policy

A successful run writes the next available SYS-REQ ID in the target spec, sets traces.satisfies to STK-REQ-001, and appends that ID to the criterion's derived_reqs list. --auto takes the first FRETish suggestion. --llm is an optional Gemini path, not the default. We have not run this against a frozen Jama or Sparx corpus, and we have not claimed the child is proved consistent with the parent. The loss is named, not scored.

The command only starts from stakeholder acceptance criteria. It does not invent shalls from a design decision, a hardware constraint, or an interface budget. That is the NASA self-derived case, and it is still a human write. Empty and non-testable criteria are skipped, not guessed. A FRETish compile failure skips that criterion. --auto is the first template, not a review. A unit test of the child is not acceptance evidence for the stakeholder shall. Object-code coverage on C still wants the qualified toolchain. That H1 lives on MC/DC for Go and on Proof vs LDRA.

The matrix H1 stays on requirements traceability matrix. The SRS H1 stays on software requirements specification. Jama still authors.

What is a decomposed requirement? The same shall split into owned children. proof req decompose is that command. Not a twin of this H1.

What is a requirements traceability matrix? The table of links, re-derived from the graph. RTM.

What is a software requirements specification? The artefact that lists the shalls. SRS as proof doc generate npr7150-srs.

What is FRETish? The structured English the derive flow compiles before it writes YAML. FRETish.

Is Proof a Jama alternative for derivation? No. Jama still authors. Proof writes the child file so CI can fail when the criterion has no SYS-REQ.