Check reference
Give nonboolean inputs a domain the model can inspect
An integer named weight_g does not tell gap analysis which values matter. nonbool_inputs_constrained finds declared nonboolean inputs and modes that lack an accepted domain model.
What the current check requires
The specification-stage check examines components with at least one active FRETish-formalized requirement. A nonboolean input or mode needs a numeric range with both bounds, a supported same-component data constraint that names it, or declared enum values in a domain table. Auxiliary variables are exempt with a recorded reason. The current implementation has warning severity.
Illustrative example: a weight limit
variables:
- name: weight_g
type: int
direction: input
range: {min: 0, max: 10000}
If the pricing policy has bands through 1,000 and through 5,000, this domain keeps 5,001 visible as a legal value needing an outcome. Setting the maximum to 5,000 merely to remove that case would change the modeled interface. If larger inputs are rejected before this component, record and verify that boundary assumption.
Model the variables already used
Start with the named variable and the requirements that consume it. Add the real domain fact rather than unrelated variables. For enums, use supported data-constraint or table declarations; a plain enum type does not supply its own allowed-value list. If no requirement consumes the variable, resolve the orphan before designing a speculative domain.
proof var diagnose shipping
proof audit --check nonbool_inputs_constrained --verbose
proof gaps specs/system shipping
A declared domain is not exhaustive execution
Gap analysis uses enum values and numeric boundary samples. The combined determinism state space is capped, by default at 4,096 states, with explicit truncation notices. Modeling the domain enables analysis; it does not establish that every integer or execution path was explored. Audit defaults can fail on warnings, while enforced merge blocking additionally needs the CI result wired into repository policy.
Follow the evidence
Check that the domain includes the values whose rejection or special handling matters.
Review one missing input domain. Bring the variable and its consuming requirements so we can assess the real bounds, rejected values and analysis scope.