Glossary¶
You do not need to memorize these terms before trying ToppleCat. Use this page when a report, developer, or AI needs the exact project meaning. The plain explanation comes first; capitalization marks a formal ToppleCat term.
Executable Contract¶
The public Acceptance Methods and public and reviewer-controlled Typed Case Rows that define what ToppleCat will mechanically check. People remain responsible for whether the rules and examples are correct and complete.
Acceptance Condition¶
One externally chosen rule with a stable AC-... ID. ToppleCat binds the rule
to executable acceptance work but never invents a missing rule.
Acceptance Method¶
The one public Java/JUnit method that tells the Scenario for an Acceptance Condition. Both public and reviewer-controlled examples run this same method.
Typed Case Row¶
One authored JSON or YAML example with an AC ID, inputs, and expected results. A value generated during Property-Based Testing is evidence from that run, not a Typed Case Row.
Scenario, Stage, and Step¶
A Scenario is one ordered Given, When, Then, and And execution for one case row. A Stage groups related business actions and holds ordinary state during that Scenario. A Step is one selected action or observation within it.
Reviewer and Implementation Agent¶
The Reviewer is the person who reads the prepared contract and current Verification Report, then decides what to do with the delivery. The Implementation Agent is the AI coding agent that receives the public contract and safe feedback. It does not receive private reviewer material.
Independent Safeguard¶
A check whose current-run evidence answers only its own question. Reviewer examples, Property-Based Testing, and Mutation Testing stay separate; one passing result cannot fill a gap in another.
Hidden Tests¶
Reviewer-controlled Typed Case Rows that run an existing public Acceptance Method with independently chosen examples. They test the same rule and do not create secret requirements.
Property-Based Testing¶
A check that exercises a human-approved invariant over bounded generated inputs. It can find a counterexample, but it is testing evidence rather than mathematical proof.
Mutation Testing and Mutation Attribution¶
Mutation Testing temporarily changes production behaviour and asks whether the unchanged public Acceptance Method notices. Mutation Attribution connects a PIT observation to the exact public method and Acceptance Condition responsible for detecting it.
Mechanical Seal¶
A content-based integrity record over the complete executable contract and verification policy. It can show that the agreement changed after review. It is not human approval, encryption, or a security sandbox.
Current-run Evidence and Aggregate Verdict¶
Current-run Evidence is produced by the active formal Verify run. The
Aggregate Verdict is PASS, FAIL, or INCOMPLETE for that run's delivery
scope. PASS means every required Gate passed; it is not proof that every
business rule was written down.
Spec Review and Verification Report¶
Spec Review is the private page used before the AI starts, so a person can confirm the selected Spec and prepared checks. Verification Report is the private page used after the AI says done; it explains the current verification result and the problems that need investigation.
For the complete canonical vocabulary, see CONTEXT.md. For the information flow behind these terms, read From rules to results.