Solver modeling opportunity

The check is solver_modeling_opportunity. It is SPEC-stage plus audit. Severity is warning. Under the default fail_level: warn that warning still blocks. The hop reads description prose on an active FRETish-formalized requirement. It does not read the Go. It does not call Z3. It does not call Kind2.

It fires when the description carries an enumerable-domain signal and none of the referenced variables carries a model. A variable counts as modeled when its range has both min and max, when a data_constraint names it, when it appears on a domain.tables table, or when it sits in a domain.mutex group. That is the same extraction gaps_clean and the non-boolean constraint hop consume. Declaring one domain fact satisfies all of them.

Rationale prose does not decide firing. Obligation-class lists and citations live there. They are majority noise. Description-anchored signals decide. Bool-only requirements stay quiet: every referenced variable is a boolean without a data constraint, so there is no enumerable domain to model. Perf-prose markers demote numeric bounds to weak. A leftover budget sentence still needs audit_ignore with a reason of at least 16 characters.

The help file teaches the silent prose first. One shall still prints valid. Nothing in the suite asked whether owner, admin, or staff is a domain you meant to keep as English.

# SYS-REQ-403 description:
# The store shall allow exactly one of: owner, admin, or staff
# to mutate settings. role, mutate_settings, and settings_view
# are booleans.

# proof audit --check solver_modeling_opportunity
# [SPEC] solver_modeling_opportunity
# 1 FRETish requirement names an enumerable domain
# SYS-REQ-403: one-of-list + lexical mutex, no modeled variable
# silent prose: last VALID still on bare booleans

The fix is always on a variable that requirement already names. Declaring a new variable does not clear the signal. It creates a variable_orphans_clean finding. Read the hop as "these variables are too coarse for the domain the description states", not as "this component needs more variables".

proof audit --check solver_modeling_opportunity --verbose

The teaching graph is still one auth shall whose description named three roles while every variable stayed a boolean. Close it by putting the domain on a variable that requirement already references: a range, a data constraint, a table, or a mutex group. Do not add a spare variable to look modeled. Do not waive the hop with a one-word reason. With no modeled variable the hop still fires, and the three-role matrix did not go anywhere. It just stayed English.

# role now carries the domain the description already stated
#   data_constraint:
#     domain: enum
#     variable: role
#     values: [owner, admin, staff]

# proof audit --check solver_modeling_opportunity
# 0 FRETish requirements with an unmodeled enumerable domain. this hop is quiet

An unconstrained output while Kind2 still prints realisable stays on gaps clean. A last VALID that crossed one minute stays on solver latency clean. Jama still authors. Proof vs Jama.

Warning, not fail on its own. Blocking under the default fail_level: warn. Description-anchored only. Rationale is ignored. Bool-only requirements are a pass, not a model. Weak signals need two distinct patterns. Lexical mutex phrases and keywords are English-first; a non-English project supplies its own list or turns the layer off. The hop does not write the YAML. It does not add a variable. It does not prove the Go. It does not fill a Jama cell. A perf budget without a marker still needs audit_ignore. 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 permission matrix is an IAM SERP, not this hop.

The unconstrained-output hop stays on gaps clean. The duration hop stays on solver latency clean. The engagement stays on software correctness audit. Jama still authors.

What is solver modeling? Same question. Same URL.

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

Is this code predicates modeled? No. That hop is a load-bearing compare on the implements function. This hop is English that named a domain no variable models. See code predicates modeled.

Is this gaps clean? No. That hop is an unconstrained output while Kind2 still printed realisable. This hop is whether the English already described a domain no variable models. See gaps clean.

Is this non-boolean inputs constrained? No. That hop is a variable you already declared with no domain. This hop is English that named a domain no variable models. See non-boolean inputs constrained.

Is this solver latency? No. That hop is wall-clock after the solver ran. This hop is missing models before it ran. See solver latency clean.

Is this a permission matrix page? No. Ads volume on that string is cloud IAM. This hop is one shall's description.

Does a bool-only suppression prove the domain is modeled? No. There was no enumerable domain to model. The hop stayed quiet on purpose.

Does a green hop prove the code matches the shall? No. The hop observes prose against variable files. It does not prove the Go.

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