This push
- yaml 38 obligation_classes
- catalog ~25 entries
- signals rules still name the rest
Topic · requirements completeness
What is requirements completeness, and how do I keep it true in CI?
Gist
Requirements completeness here is whether the classes you declared, the catalog you load, the signal rules you run, and the checklists on each shall still name the same ids. Proof fails the merge with proof audit --check catalog_completeness --verbose when any of those four disagree. IEEE papers still argue when the human set is done. Jama still authors.
proof audit --check catalog_completeness --verboseKeep Jama if you store the programme. Keep INCOSE if you write the shalls. A green catalog check is not a certificate that stakeholders approved every need.
01 · The class nobody cataloged
A filled checklist is not a loaded definition.
You can declare thirty-eight classes in proof.yaml, catalog twenty-five, and still merge. Signal rules that name the missing thirteen silently no-op.
IEEE and INCOSE treat completeness as whether the human set covers the need. Argon Digital treats it as stakeholder sign-off. The Reuse Company treats it as missing information between prose and a model. This page is the drift gate in the repo: every obligation_class in proof.yaml has a catalog entry, every signal-rule obligation resolves, every overlay class is declared, every checklist item is known. The check runs at --stage spec before signals collect, so the miss is a named finding instead of a silent skip.
The witness H1 lives on every requirement covered. The writing-rules H1 lives on INCOSE Guide for Writing Requirements. The matrix H1 lives on requirements traceability matrix.
proof catalog list --overlay
proof catalog show malformed_input
proof audit --check catalog_completeness --verboseOn this install the teaching miss is an undeclared checklist id. The merge stayed green because nothing asked whether the class existed yet.
02 · The exhibit
Same shall. An undeclared class, or a named invariant.
The checklist still names the class. The catalog does not load it. The gate will fail until a human defines the class or withdraws the reference. Click the tabs.
Finding
No invariant. The uncataloged class never entered the review. The rule silently no-ops.
Silent skipThis push
Still last week's shall. Still a checklist id. Still no catalog file until someone writes one or drops the reference.
Keep the SYS-REQProof
- Ask proof audit --check catalog_completeness
- Kind req_checklist_undeclared
Same shall. An undeclared class, or a named invariant. Click the tabs.
| Invariant | What they do | What Proof does |
|---|---|---|
| IEEE / INCOSE completeness | Argue when the human set covers the need, or when every stakeholder has approved it. | Not this check. Proof does not certify the human set. Keep the writing rules on INCOSE. |
| obligation_class_uncataloged | proof.yaml names a class the catalog does not define. | proof catalog new writes the overlay, or you delete the id from project.obligation_classes. |
| signal_rule_uncataloged | A signal rule names a class no catalog entry defines, so collect would silently no-op. | Repoint the rule, or create the missing entry. Do not rename to the nearest neighbour. |
| catalog_orphan | An overlay file defines a class no requirement can ever use. | Adopt it in proof.yaml, or delete the overlay file. |
| req_checklist_undeclared | A requirement checklist cites a class that is neither declared nor cataloged. | proof req edit --remove-obligation, or make the class real in both yaml and catalog. |
| Jama / DOORS | A completeness field on the requirement object in the ALM. | Jama still authors. IBM DOORS stays a mention on Proof vs Jama. |
Every finding kind admits two resolutions: supply the missing definition, or withdraw the reference. They are alternatives, not steps. If a class does not apply to one requirement, suppress it with a reason. Do not delete the class from the project to clear the check. Do not substitute a neighbouring cataloged class. That produces a checklist that passes while enforcing something nobody intended.
proof catalog new shared_connection_back_pressure_bounded --category domain --domain concurrency --summary "Back pressure on a shared connection stays bounded"
proof req edit SYS-REQ-001 --remove-obligation undeclared_class
proof audit --check catalog_completeness --verboseWe have not run Jama completeness scoring and Proof on the same frozen corpus, and we have not claimed the four invariants are IEEE completeness of the human set. The loss is named, not scored.
03 · The honest loss
A green catalog check is not a complete spec.
Proof fails when declared classes, catalog entries, signal rules, and checklists disagree. It does not invent the shall you never wrote. Jama still authors.
The check does not decide that stakeholders approved every need. It does not fill unconstrained outputs. That gate is
k-induction
and gaps_clean, not this URL. It does not prove each shall has a witness. That H1 lives on
every requirement covered.
Overlay files under proof/catalog/ still need a human to write the class. The shipped catalog cannot name every hazard a project will hit.
The writing-rules H1 stays on INCOSE Guide for Writing Requirements. Jama still authors.
04 · Nearby questions
What people type next.
What is a requirements catalog? University catalog-year pages and data-catalog buyers own that SERP. The command on this install is proof catalog, the obligation class list, not a course catalog.
How do I know every requirement is covered? A witness on this push, not a catalog id. every requirement covered.
What is the INCOSE Guide for Writing Requirements? The writing rules for the shalls. INCOSE.
What is an assurance case? NIST and NASA still want GSN or CAE. Proof does not ship that editor. Not this URL.
Is Proof a Jama alternative for completeness? No. Jama still authors. Proof fails the merge when the four ids disagree.