Check reference

Formalize behavior at component boundaries

An interface can list fields and still omit what a receiver must do. interface_formalization_complete checks the formal behavior required by configured cross-component specifications.

Which contracts are in scope

The current implementation selects specs marked cross_component: true whose spec type requires FRETish. Within them it examines guarantees in review or approved status that require FRETish formalization. A missing requirement type is treated as a guarantee. Empty formalizations and recognized incomplete two-boolean envelopes are findings. This specification-stage check has warning severity.

Illustrative example: an acknowledgement contract

A producer sends a batch to storage. The interface description promises that an acknowledgement means the batch was durably recorded, but its model says only “request implies response.” That formula does not distinguish durable success from rejection or temporary failure.

Interface decision to model:
  accepted batch + durable write -> success acknowledgement
  rejected batch                -> rejection acknowledgement
  write failure                 -> failure acknowledgement

This is a behavior sketch, not executable FRETish. The actual contract needs declared signals, timing semantics and ownership: the producer supplies the request; storage controls the acknowledgement.

Repair the boundary, then preflight it

Write formal rules for the agreed outcomes and tie them to the relevant interface requirements. A boolean envelope is appropriate for a genuinely simple boolean contract; it is inadequate when the description contains an omitted bound or extra behavior. A genuinely prose-only lower layer can use the configured informal strategy, but that choice removes solver coverage for that content and deserves explicit review.

proof audit --check interface_formalization_complete --verbose
proof validate --preflight specs/integration storage

Formalized does not mean implemented

This check establishes that eligible contracts have usable formalization content. It does not prove the contract realizable, verify that the producer and receiver obey it, or refresh interface implementation fingerprints. Use those analyses and executed integration tests separately. The example spec path is illustrative; use the cross-component layer configured in your project.

Follow the evidence

Choose one interface response and make its meaning explicit before adding more fields or trace links.

Review one component contract. Bring the producer and receiver requirements so we can assess response meaning, ownership and the behavior that needs formalization.

Formalize lower layers · Check variable ownership