Under-modeled requirements

The check is under_modeled_requirements_clean. It is VERIFY-stage plus audit. Severity is warning. The hop reads indexed traces and cached derived modeling metrics. It does not rewrite the YAML. It does not call Z3. It does not call Kind2.

It fires when the observed review evidence looks richer than the requirement itself. Typical signals: several verifying tests but only one meaningful spec-side variable; witness-bearing tests denser than the current rows explain; matched implementation fan-out much larger than the variable set; persisted code-side decisions richer than the requirement-level MC/DC rows; sibling requirements sharing one implementation without enough family-level behavior coverage.

The hop prefers cheap requirement-scoped structure over loose fan-out guesses: spec-side meaningful variable count, matched persisted code-level MC/DC decisions and conditions, and explicit witness-bearing test density. Thresholds live under project.checks.under_modeled_requirements. A code-rich warning needs a small variable set, a decision multiplier, and a decision floor. A witness-rich warning needs a small variable set plus a test or line threshold.

For code-rich findings the hop groups siblings that share an implemented_by target before it warns on each one. A family that already covers enough obligation classes, enough collective variables, or further decomposition suppresses the individual warnings. A weak family emits one family_under_modeled finding instead of repeating the same line on every sibling. implementation_shape_complex is advisory only, and it stays off unless you turn it on.

This is not a contradiction finding. A parseable, satisfiable, fully traced shall can still be too coarse for the verification story attached to it. The help file teaches that first.

# SYS-REQ-410 description:
# The store shall authorize the mutation.
# authorized is a boolean. One meaningful variable.

# proof audit --check under_modeled_requirements_clean
# [VERIFY] under_modeled_requirements_clean
# 1 requirement likely under-modeled
# SYS-REQ-410: requirement_under_modeled
# 1 meaningful var, 8 matched code-side decisions,
# 12 witness-bearing tests
# silent shall: last VALID still on one boolean

The fix is on the model, not on another test. Decompose the summary shall. Split a shared implementation into siblings with distinct obligation classes. Replace a summary boolean with explicit causal variables. Narrow an over-broad implemented_by or verified_by. Move a generic test off the requirement if it does not support it.

proof audit --check under_modeled_requirements_clean --verbose
proof review req SYS-REQ-410
proof mcdc compare SYS-REQ-410

The teaching graph is still one authorize shall whose one boolean sat on eight matched code-side decisions and twelve witness-bearing tests. Close it by decomposing the shall, or by putting the missing causal variables on requirements that already trace to that Go. Do not add a spare test to look covered. Do not waive the hop with a one-word reason. With one boolean the hop still fires, and the eight decisions did not go anywhere. They just stayed in the Go.

# SYS-REQ-410 split into causal siblings
#   authorized_owner, authorized_admin, authorized_staff
#   obligation_checklist names distinct classes
#
# proof audit --check under_modeled_requirements_clean
# 0 requirements likely under-modeled. this hop is quiet

A missing covering SYS-REQ for a listed class stays on obligation completeness. A last SAT that never binds stays on vacuous requirements. A description that named a domain no variable models stays on solver modeling opportunity. Jama still authors. Proof vs Jama.

Warning, not fail on its own. Family grouping can suppress an individual code-rich line. implementation_shape_complex is advisory only and defaults off. The hop does not rewrite the YAML. It does not add a variable. It does not prove the Go. It does not fill a Jama cell. A parseable, satisfiable, fully traced shall can still be too coarse; a quiet hop is not a proof that the model is enough, only that the current thresholds did not fire. We have not scored this floor against a frozen Jama pack or a ReqIF export. The loss is named, not scored. Adjacent Ads volume on modeling quality is a CAD SERP, not this hop.

The spec-stage checklist hop stays on obligation completeness. The vacuity hop stays on vacuous requirements. The description-domain hop stays on solver modeling opportunity. The implements-compare hop stays on code predicates modeled. The engagement stays on software correctness audit. Jama still authors.

What is under modeled requirements? Same question. Same URL.

Is this obligation completeness? No. That hop is spec-stage: whether each listed class has a covering SYS-REQ. This hop is verify-stage: whether the traces that already exist still look richer than that SYS-REQ. See obligation completeness.

Is this vacuous requirements? No. That hop is a SAT that never binds. This hop is a binding shall that is still too coarse. See vacuous requirements.

Is this solver modeling? No. That hop is a description that named a domain no variable models. This hop is variables you did model, against Go that still looks richer. See solver modeling opportunity.

Is this code predicates modeled? No. That hop is spec-stage: whether a load-bearing numeric compare on the implements function appears in FRETish or not_modeled. This hop is verify-stage traces against variables. See code predicates modeled.

Is this gaps clean? No. That hop is an unconstrained output while Kind2 still printed realisable. See gaps clean.

Is this a modeling quality page? No. Ads volume on that string is CAD and data-modeling glossaries. This hop is one shall's traces.

Does a quiet hop prove the code matches the shall? No. The hop observes traces against variables. It does not prove the Go.

Does a family suppress mean the model is enough? No. It means the siblings already explained that shared target under the current thresholds.

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