Skip to content

Constraint and Invariant Checker

Checking tool — instantiates Generate-and-Verify Separation

Evaluates every candidate against a fixed, explicit set of constraints and invariants the checker itself holds, accepting only those that violate none — regardless of how the candidate was produced.

Constraint and Invariant Checker is the archetype's explicit-predicate verifier: it carries a standing library of rules — invariants, constraints, assertions — and evaluates each incoming candidate against them, admitting only the violation-free ones. The idea that distinguishes it from its siblings is where the acceptance criterion lives. It does not consume a certificate the generator hands over, and it does not compare against a reference run; the predicate is inside the checker, authored once, and applied uniformly to every candidate whatever its source. That makes it the natural gatekeeper at a boundary many untrusted generators write into: the rule set is the contract, and provenance is irrelevant to the verdict.

Example

An order-management service ingests orders from a public web checkout, a dozen partner APIs, and nightly CSV imports — a set of generators no one fully trusts. At the write boundary sits a Constraint and Invariant Checker holding the business invariants: on-hand inventory never goes negative, reserved quantity never exceeds on-hand, every line references a real SKU and a price within the published band, and the ledger for each order balances to zero. Every proposed write, from any source, is evaluated against that predicate set before commit; a partner integration bug that tries to reserve stock it doesn't have is rejected at the door, not discovered later in a corrupted ledger. The checker's authority comes entirely from the explicitness of its rules — anyone can read exactly what "valid" means here, and the same rules bind the trusted internal path and the sketchy CSV alike.

How it works

  • A predicate the checker owns. The invariants are written down once, versioned, and evaluated on demand; the generator neither sees nor controls them.
  • Provenance-blind evaluation. A candidate is judged only on whether it violates a rule, never on who produced it — the property that lets untrusted sources share one gate.
  • A declared scope, and a declared stance. The checker states which properties are in scope (and, pointedly, which are not), and whether a "pass" means no violation exists or merely no violation was detected.

Tuning parameters

  • Predicate-set breadth — how many invariants are enforced. More rules catch more, but cost evaluation time and raise the false-rejection rate on legitimate edge cases.
  • Soundness-vs-completeness stance — tune toward never miss a violation (at the price of false alarms) or never false-alarm (at the price of missed violations). For rich semantic properties you cannot have both at once.
  • Hard vs. soft rules — which violations block the candidate and which merely warn or quarantine.
  • Evaluation point — ingest-time, pre-commit, or continuous re-checking of already-accepted state.
  • Scope explicitness — whether the in-scope/out-of-scope boundary is published as a contract or left implicit (and quietly over-trusted).

When it helps, and when it misleads

Its strength is a clear, source-independent contract: one readable rule set enforced identically across every generator, cheap to run and easy to audit. It scales openness — new and untrusted producers can be admitted the moment their output satisfies the predicate.

Its failure mode is that it only checks what is written. Any property no one encoded passes silently, so a green result means "no known violation," not "correct." And for nontrivial semantic properties, no checker can be simultaneously sound and complete — it must trade false alarms against missed violations, and the stance it picks is a real limitation, not a bug to be fixed away.[^rice] The classic misuse is treating "passed the checker" as "is valid" when the rule set is narrow — exactly the archetype's warning about a small technical predicate substituting for real-world validity. The discipline is to publish the scope statement so readers know what the pass does not cover, and to grow the invariant set deliberately rather than trusting its silence.

How it implements the components

The Constraint and Invariant Checker fills the explicit-predicate components — the parts a rule-holding checker owns:

  • checkable_acceptance_predicate — the invariant/constraint library is the decidable predicate every accepted candidate must satisfy.
  • verification_scope_statement — it documents precisely which properties fall inside the check and which are deliberately excluded.
  • soundness_boundary — it declares whether a pass guarantees the absence of a violation or only the absence of a detected one, fixing the meaning of "accepted."

It does not consume a generator-supplied witness — that is the Feasibility Certificate Check — nor derive correctness from a reference implementation, which is the Differential Checker or Reference Oracle.