Cross level complete

The check is cross_level_complete. It is DOCUMENT-stage. Default severity is warning. It loads every active stakeholder requirement. Terminal and rejected tombstones are out of the denominator. For each remaining STK-REQ it asks whether at least one active system requirement lists that id in traces.satisfies. A superseded SYS-REQ does not count. It does not rewrite the YAML. It does not call Z3. It does not call Kind2.

The upward hop from each SYS-REQ stays on system requirements linked. That hop is error when a SYS-REQ has no live STK parent. This hop is the reverse: whether each active STK-REQ has at least one live SYS child. The graph of declared levels stays on levels connected. The L1 body hop stays on L1 system complete. L0 file existence stays on stakeholder requirements.

Each SYS-REQ can look fine on its own. The Jama cell still names a parent. Reviewers signed the English in another tool. A presence-only check is green because a satisfies id is present. That id can already be a different STK-REQ. Other DOCUMENT hops miss this because they never walk parent to child.

The expensive miss is a programme that treats the SYS layer as the need. The stakeholder requirement stayed active. No live system child names it. This hop is the gate that prints the coverage fraction and the STK ids that still have no child.

# STK-REQ-040
# status: approved
# SYS-REQ-210 traces.satisfies: [STK-REQ-999]
# a presence-only hop
# pass. the SYS has a satisfies id
# proof audit --check cross_level_complete
# [DOCUMENT] cross_level_complete
# 0% cross-level coverage (0/1 stakeholder reqs satisfied)
# STK-REQ-040
# WARNING
# proof req derive STK-REQ-040

The fix is a human authorization, not a rewrite of Go. Derive a live SYS-REQ that satisfies STK-REQ-040. Point an existing SYS at that id. Do not delete the STK-REQ to silence the checker. A second live SYS next to a historical tombstone still passes: one live child is enough. Then re-run DOCUMENT.

proof audit --check cross_level_complete --verbose
proof workflow check --stage document --only cross_level_complete
proof help cross_level_complete

The teaching graph is still one active STK-REQ that no live SYS-REQ satisfies. Close it by deriving a live child, or pointing an existing SYS at that id. Do not delete the YAML. Do not invent a second STK-REQ. A satisfies list that only names a superseded SYS does not count. Zero STK-REQs is a pass, not completeness. Rejected and terminal tombstones are out of the count. One live SYS among extra historical links is enough.

# STK-REQ-040 kept. SYS-REQ-220 satisfies STK-REQ-040 (live)
# proof audit --check cross_level_complete
# 100% cross-level coverage (1/1)
# DOCUMENT may move on. pass sits on a live child

The upward hop stays on system requirements linked. The graph hop stays on levels connected. The L1 hop stays on L1 system complete. The rewrite hop stays on characterization testing and mirrors. Jama still authors. Proof vs Jama.

Warning when an active STK-REQ lacks a live SYS child. Default severity does not fail the merge. You can still advance. Zero stakeholder requirements is a pass, not a complete L0-to-L1 chain. The hop does not write the satisfies list. It does not add a shall. It does not write a description. It does not prove the Go. It does not run Kind2. It does not measure independence. It does not say every SYS-REQ has a live STK parent. That hop is system requirements linked, and that hop is error. A quiet hop is not a proof that Jama's shall matches the Go, only that every in-scope STK-REQ currently has a live system child. We have not scored this floor against a frozen Jama pack or a VectorCAST corpus. The loss is named, not scored.

The L1 hop stays on L1 system complete. The rewrite hop stays on characterization testing and mirrors. The engagement stays on software correctness audit. Jama still authors.

What is cross level complete? Same question. Same URL.

Is this system requirements linked? No. That hop is whether each SYS-REQ has a live STK parent, and it is error. This hop is whether each STK-REQ has a live SYS child, and it is warning. See system requirements linked.

Is this levels connected? No. That hop is whether declared L0, L1, and L2 join as one graph. This hop is whether each active STK-REQ is itself satisfied. See levels connected.

Is this L1 system complete? No. That hop is whether each active SYS-REQ has a description and an upward edge. This hop is whether each active STK-REQ still has a live SYS child. See L1 system complete.

Is this L2 software complete? No. That hop is whether each active SW-REQ or INT-REQ still has a live SYS parent. This hop is the STK-to-SYS child. See L2 software complete.

Is this stakeholder requirements? No. That hop is L0 file existence. This hop is whether each of those files still has a live SYS child. See stakeholder requirements.

Does a historical tombstone next to a live SYS fail this hop? No. One live system child is enough. Extra retired ids do not fail the row.

Does a superseded SYS count as the child? No. Terminal and rejected tombstones are out of both sides of the count.

Does a quiet hop prove the named SYS-REQ is the right child? No. The hop observes that a live system id is present. It does not score the sentence.

Does a quiet hop prove the Go matches the shall? No. The hop observes links. It does not prove the Go.

Does an unsatisfied STK-REQ fail the merge? No by default. The check keeps warning severity. You can still advance.

Is zero STK-REQs a complete chain? No. Zero rows is a pass of this hop, not a stakeholder-to-system chain.

Is this characterization testing? No. That page is rewrite-with-a-ledger. This hop is a STK-REQ with no live SYS child. See characterization testing and mirrors.

Is Proof an LDRA alternative for the instrument? No. LDRA still owns the avionics toolchain. Proof vs LDRA.

Is Proof a Jama alternative for the shall? No. Jama still authors. Proof vs Jama.