Interpreting Guards and Heuristics

Reference for how to interpret confirmations, warnings, heuristics, and export blocks in the current release.

Guards and heuristics are decision-support signals. They are not identical to formal proof.

Confirmation required

This outcome means the workflow can continue, but the product expects an explicit researcher acknowledgment before a claim-bearing export should be treated as complete.

Read this as:

  • the system detected a decision point that still needs human confirmation
  • the situation is important enough to be surfaced explicitly
  • the product is not claiming that the analysis is invalid by default

Warning note only

This outcome means the product detected a lower-confidence or non-blocking signal.

Read this as:

  • the workflow can proceed
  • the warning is still part of the analysis context
  • the note may appear in audit-oriented metadata even when export is allowed

Export blocked

This outcome means the current workflow cannot be treated as ready for the relevant export surface until the flagged issue is addressed.

This does not automatically mean the result is numerically wrong. It means the product cannot confirm that a required condition for that export has been satisfied.

Why heuristics must be read conservatively

Some checks are heuristic because the underlying truth cannot be derived perfectly from the available structure.

That means:

  • a warning may reflect a real issue
  • a missing warning does not prove the issue is absent
  • a confirmation request marks an important decision point, not a mere UI decoration

Relationship to audit metadata

Warnings, notes, and related context may be preserved in audit-oriented metadata. That is useful for traceability, but it does not change the meaning of the signal itself.

Use Audit Log Schema for the metadata surface, and this page for interpretation.