What are decision tables, and how do I keep the cells true in CI?

The vectors-from-the-shall H1 lives on requirements based testing. The condition-independence H1 lives on MC/DC for Go. This page is the lookup surface: finite inputs, one output per cell, every cell decided or named.

Declare the table in the component .vars.yaml. Inputs are enum or bool. Completeness without a default: is one bounded Z3 query. A sat model decodes to named input=value pairs. Consistency is validation-derived: two rows on the same cell fail proof validate, and the check does not pretend that is SMT. Equivalence is one query per equivalent_to link.

proof check tables specs/system requirement_state
proof audit --check table_complete --verbose
proof var table show

On this install the 144-cell verification_state_derivation table is the tripwire for the derivation switch. A table that only transcribes the source document's listed rows will never find the silent cell.

The teaching table in the public check docs is a lifecycle matrix: status × action → allowed. Completeness without a default is total. Do not add default: false to hide (published, delete). That converts a finding into an invented decision.

domain:
  tables:
    - name: theme_lifecycle
      inputs:
        - {name: status, type: enum, values: [published, draft]}
        - {name: action, type: enum, values: [publish, customize, delete]}
      output: {name: allowed, type: bool}
      rows:
        - {status: draft, action: publish, allowed: true}
        - {status: draft, action: customize, allowed: true}
        - {status: draft, action: delete, allowed: true}
        - {status: published, action: publish, allowed: true}
        - {status: published, action: customize, allowed: true}

proof check tables specs/system requirement_state
proof audit --check table_complete --verbose
proof var table show

Five listed rows. Six cells in the product. The sixth is the finding. Equivalence is a different ask: two documents, one permission matrix, equivalent_to, a drift cell with both outputs. We have not run this against a frozen Camunda / IBM ODM corpus, and we have not claimed the check executes DMN. The loss is named, not scored.

Consistency is validation-derived. Two concrete enum/bool rows on the same cell fail proof validate. No SMT query runs for that verdict, and none is pretended. Int-range row conditions are deferred. Cell spaces larger than 65536 must be partitioned. FRETish cannot compare an enum to a value literal; the requirement references the table's output boolean. A table no requirement consumes is an orphan. Object-code coverage on C still wants the qualified toolchain. That H1 lives on MC/DC for Go and on Proof vs LDRA.

The vectors-from-the-shall H1 stays on requirements based testing. Jama still authors.

What is decision table testing? Same cluster, shorter head. Same command. Not a twin. ISTQB cases from listed combinations are not completeness of the product.

What is requirements based testing? Vectors from the compiled shall, one program. requirements based testing.

How do I measure MC/DC coverage for my Go code? Independence of conditions, not cells in a lookup. MC/DC for Go.

How do I write machine-checkable requirements? FRETish compiles the shall. The table is the enum lookup FRETish cannot write as status = published. FRETish.

How do I know every requirement is actually covered by code and a test? Traceability is a different H1. every requirement covered.

Is Proof a Camunda alternative? No. Camunda executes DMN. Proof names a silent cell in git.