Check reference
Keep system requirements available to formal analysis
A system requirement with no formalization contributes no formula to solver analysis. system_formalization_complete identifies that missing foundation.
The current check is structural
For active system requirements, the implementation requires formalization_strategy: fretish and nonempty fretish text. Retired, superseded and rejected requirements are excluded. The check has error severity. A requirement-level informal strategy, a system spec-type informal strategy or a formalized: false field does not provide an informal escape from this system-level policy.
Illustrative example: an omitted rejection rule
A system requirement says requests above the configured size limit must be rejected before storage is modified. Its FRETish field is empty. The right repair starts by retaining both obligations, rather than replacing them with an uninformative success flag.
Required behavior:
trigger: request size exceeds the configured limit
response: rejection is reported
state constraint: storage remains unchanged
scope: the request-handling operation
This is a modeling sketch, not verified syntax. Define size, limit, rejection and state-change observations with their ownership before writing the formal sentence.
Compile and review the actual meaning
Add the FRETish strategy and a real formal sentence. Then preflight the component's declarations, review its temporal semantics and run the relevant analyses. Legacy exceptions need explicit reviewed waivers. Do not mark a row retired just because its behavior is difficult to express; retirement changes which intent remains active.
proof audit --check system_formalization_complete --verbose
proof validate --preflight specs/system upload
Nonempty is not semantically complete
The present system check enforces strategy and text presence. It does not prove that the text captures every bound in the description, that outputs are fully constrained, or that implementation code conforms. Other checks inspect missing domains, code predicates, gaps and vacuity. Keep a successful result described at that structural level, then collect the separate model and execution evidence needed for the actual system claim.
Follow the evidence
Start with one empty system formalization and preserve all of its meaningful outcomes.
Review one system formalization. Bring the requirement and component boundary so we can assess how to preserve its meaningful outcomes in a model that can be analyzed.