Behavioral implications verified

The check is behavioral_implications_verified. It is VERIFY-stage. Default severity is warning. The hop asks whether a supported requirement implication holds for every input in the concrete domains declared on the data_constraint variables. It does not rewrite the YAML. It does not inspect the Go. It does not run Kind2 on a helper.

It fires on a class, not on a skip. [disproved] is a counterexample: fail at warning. [not-parsed] is a formula Proof could not read, so no proof was attempted: warn, not an unproven shall. [inconclusive] is a timeout or resource limit: warn. [unclassified] is a solver token Proof does not name: warn, and the raw token prints. Do not treat those four as one bucket. The owner and the repair differ.

The expensive miss is a FRETish implication that is realizable as booleans while the authored data-domain meaning is false for some legal input. Kind2 never saw quota_used. Completeness can still print clean on the cases you named. Coverage can still print that every non-auxiliary row reached Z3. This hop is the proof after that skip list.

This is not whether the encoder kept the row. That hop is data constraint Z3 coverage. A skip is not a counterexample. A counterexample is this hop. The help file teaches that first.

# quota_ok ⇒ allow_request is realizable as booleans
# Kind2 never saw quota_used
- name: quota_ok
  type: bool
  direction: input
  data_constraint:
    domain: integer
    condition: quota_used < quota_max
    parameters:
      - name: quota_used
        type: int
        constraint: ">= 0"
      - name: quota_max
        type: int
        constraint: ">= 1"
- name: allow_request
  type: bool
  direction: output
  data_constraint:
    domain: integer
    condition: request_bytes <= 1024
    parameters:
      - name: request_bytes
        type: int
        constraint: ">= 0"

# proof audit --check behavioral_implications_verified
# [VERIFICATION] behavioral_implications_verified
# quota_ok ⇒ allow_request [disproved]
# quota_used=0 quota_max=100 request_bytes=4096
# silent pass: last stamp still on Kind2 realizability

The fix is on the implication or on the supporting data_constraint, not on another test. Tighten the consequent, or stop claiming the antecedent implies a bound Kind2 never saw. Then re-run the VERIFY stage. Do not jump to realize to hide a counterexample. Route [not-parsed] to the spelling the diagnostic names, not to a new shall.

proof audit --check behavioral_implications_verified --verbose
proof verify-properties specs/system
proof help behavioral_implications_verified

The teaching graph is still one implication whose boolean half looked proven while the data half named a bound Kind2 never saw. Close it by fixing the requirement logic or the supporting data_constraint model. Prefer a simple, explicit implication when you want a universal Z3 proof. Do not treat [not-parsed] as a missing shall. Do not treat [inconclusive] as a pass.

# the implication now names the bound Kind2 could not see
# quota_ok ∧ small_request ⇒ allow_request
- name: small_request
  type: bool
  direction: input
  data_constraint:
    domain: integer
    condition: request_bytes <= 1024
    parameters:
      - name: request_bytes
        type: int
        constraint: ">= 0"

# proof audit --check behavioral_implications_verified
# no [disproved] on this implication
#
# VERIFY may still warn. a pass now sits on a domain Kind2 did not prove

The skip-list hop stays on data constraint Z3 coverage. The partition hop stays on data constraints complete. The helper lemma stays on Z3/Kind2 on one function. Jama still authors. Proof vs Jama.

Warning, not fail, on the default. A counterexample reports fail at warning; a parse gap or a timeout reports warn. Neither class blocks advancement unless you raise it in proof.yaml. An unsupported requirement shape is silence, not a proof that the shall is true. [not-parsed] is not an unproven requirement. [inconclusive] is not a pass. The hop does not rewrite the YAML. It does not add a shall. It does not prove the Go. It does not run Kind2. A quiet hop is not a proof that the lowered model is the one you meant, only that every supported implication the translator accepted closed without a counterexample. We have not scored this floor against a frozen Jama pack or a ReqIF export. The loss is named, not scored.

The skip-list hop stays on data constraint Z3 coverage. The partition hop stays on data constraints complete. The silent-domain hop stays on non-boolean inputs constrained. The helper lemma stays on Z3/Kind2 on one function. The engagement stays on software correctness audit. Jama still authors.

What is behavioral implications verified? Same question. Same URL.

Is this data constraint Z3 coverage? No. That hop is whether an authored case was even lowered. This hop is whether a lowered implication holds for all inputs. See data constraint Z3 coverage.

Is this data constraints complete? No. That hop is completeness and exclusivity of the cases you already named. This hop is the implication over those cases. See data constraints complete.

Is this Z3 on one function? No. That hop is a lemma on a helper. See Z3/Kind2 on one function.

Is this a SQL CHECK constraint? No. Ads 140 on data constraint is a column the database enforces at write. The H1 stays this check.

Does [not-parsed] mean the shall is unproven? No. Proof could not read the formula, so no proof was attempted. Route it to proof help spec_lint_data_constraint_parseable.

Does [inconclusive] mean the implication holds? No. The solver ran and gave up. Raise the timeout or simplify the implication.

Does a quiet hop prove the lowered model is the right domain? No. The hop observes supported implications. It does not score the sentence.

Is Proof a Jama alternative for the domain? No. Jama still authors. Proof vs Jama.