Check reference
Move decision domains out of prose
A requirement can describe ranges, roles or mutually exclusive states while exposing too little of that domain to analysis. solver_modeling_opportunity flags selected patterns worth reviewing.
A prose signal with a limited claim
This specification-stage warning looks at active FRETish-formalized requirements and the variables they reference. Description-anchored signals such as ranges, enumerations and mutex language can trigger a finding when none of those variables carries a recognized domain model. Rationale text helps contextualize detection but does not independently determine firing. Bool-only cases, performance wording and other recognized contexts reduce noise.
Illustrative example: three delivery tiers
The description distinguishes economy, standard and express delivery, but a declared enum input has no values or decision table. Reviewers can read the tier names; gap analysis cannot enumerate the choices from the declaration alone.
Prose: service is one of economy, standard, or express
Referenced input: delivery_tier
Missing domain fact: the allowed values and their outcomes
Add the relevant enum domain or table to the existing input. Then specify the promised outcome for each case, including unknown values if they can reach the interface. Merely adding an unrelated variable does not answer this finding.
Decide whether the signal denotes a real domain
Inspect the cited description and referenced variables together. A numeric range may describe a legal input, a measured performance result or explanatory background. Model the first; retain a reasoned narrow exception for a false positive. Keywords and the lexical layer are configurable under project.checks.solver_modeling_opportunity, while structural signals follow the implementation's matcher.
proof audit --check solver_modeling_opportunity --verbose
Detection does not assess model fidelity
A recognized range, constraint, table entry or mutex can satisfy the detector's modeling criterion without expressing every rule correctly. Its absence warning is useful; its presence is not a completeness theorem. Review the domain and run the appropriate table, partition or gap checks. Do not distort a performance requirement into a fake input range solely to silence the warning. The audit failure level determines whether warning findings fail the command.
Follow the evidence
Identify the concrete input choices described by the finding, then give those choices a reviewed model.
Review one domain hidden in prose. Bring the description and referenced variables so we can assess which choices need an explicit domain and which wording is only background.