Data constraint Z3 coverage

The check is data_constraint_z3_coverage. It is VERIFY-stage. Default severity is warning. The hop counts authored data_constraint variables by logical key (component:name) against the count Z3 actually proved (data_completeness, data_exclusivity, behavioral_implication, or data_constraint_postcondition). It does not rewrite the YAML. It does not inspect the Go. It does not run Kind2 on a helper.

It fires on a skip, not on a failed proof. An empty condition: is empty_condition. direction: internal, mode, or state is direction_not_input. No parameters: and no depends_on: is no_parameters. No FRETish guarantee in that component that names the variable is orphan_no_requirement. An assumption-type FRETish that names it does not close that last filter. Duplicate rows of the same logical key collapse to one variable and print as a diagnostic, not as an extra unproved row.

The expensive miss is a direction: internal boolean whose consumers still look proven because the antecedent was never constrained. The audit then reports that every data constraint was proven, because it only counted the ones the encoder kept. This hop lists the skipped names so they can be fixed or marked proof_auxiliary: true.

This is not the partition of the cases you already named. That hop is data constraints complete. A gap or overlap among lowered cases is exclusivity. A case the encoder never kept is this hop. The help file teaches that first.

# quota_exceeded next to its consumers, never lowered
- name: quota_exceeded
  type: bool
  direction: internal
  data_constraint:
    domain: bool
    condition: quota_used >= quota_max

# proof audit --check data_constraint_z3_coverage
# [VERIFICATION] data_constraint_z3_coverage
# quota_exceeded: skipped (direction_not_input)
# silent pass: last stamp still on the checked set

The fix is on the row, not on another test. Flip direction: to input only after you author the complement and a req_type: guarantee that names both halves. Or mark the row proof_auxiliary: true when it is a helper partition. Then re-run the VERIFY stage. Do not jump to realize to hide a skip.

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

The teaching graph is still one boolean whose condition looked like a quota check while direction: stayed internal. Close it by flipping direction only after you author the complement and a req_type: guarantee that names both halves, or by marking the row proof_auxiliary: true when it is a helper partition. Do not flip direction alone on a half partition. Completeness then fires on the new input, and the orphan filter still waits for a guarantee.

# quota_exceeded now has shape Z3 can lower
- name: quota_exceeded
  type: bool
  direction: input
  data_constraint:
    domain: bool
    depends_on: [quota_used, quota_max]
    condition: quota_used >= quota_max
    parameters:
      - name: quota_used
        type: int
        constraint: ">= 0"
      - name: quota_max
        type: int
        constraint: ">= 1"

# proof audit --check data_constraint_z3_coverage
# authored == checked. skip list empty
#
# VERIFY may still warn. a pass now sits on a lowered row

The partition hop stays on data constraints complete. Leftover inventory stays on variable orphans clean. The helper lemma stays on Z3/Kind2 on one function. Jama still authors. Proof vs Jama.

Warning, not fail, on the default. Strict mode in proof.yaml can raise it to error. proof_auxiliary: true is silence with a reason, not a proof that the row was unused on purpose. Duplicate logical rows are a diagnostic, not a fail. 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 collected non-auxiliary data_constraint entered a Z3 check. We have not scored this floor against a frozen Jama pack or a ReqIF export. The loss is named, not scored.

The partition hop stays on data constraints complete. Leftover inventory stays on variable orphans clean. 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 data constraint Z3 coverage? Same question. Same URL.

Is this data constraints complete? No. That hop is completeness and exclusivity of the cases you already named. This hop is whether those cases were even lowered. See data constraints complete.

Is this behavioral implications verified? No. That hop is whether a lowered implication holds for all inputs. This hop is whether the case was even lowered. See behavioral implications verified.

Is this variable orphans? No. That hop is leftover inventory. This hop is a consumed name the encoder still dropped. See variable orphans clean.

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 flipping direction to input close the hop? Not alone. Author the complement and a guarantee that names both halves, or mark the row auxiliary.

Does an assumption-type FRETish close orphan_no_requirement? No. Only a req_type: guarantee generates the behavioral implication the filter measures.

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

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