Derives human-readable manual test cases from a business-rule spec via a decision table: identify conditions and actions, build the full 2^n-column matrix, collapse columns with irrelevant entries, strike infeasible combinations, then emit one test case per remaining column (each feasible column is one coverage item per ISTQB CTFL v4.0 section 4.2.3). A deep single-technique walkthrough rather than a broad multi-lens case matrix; the output is manual step/expected cases rather than parameterized test code, and it covers how cases are derived rather than how a case record is structured. Use when a spec's outcome depends on interacting conditions (pricing, eligibility, discounts, routing rules) rather than the boundaries of a single input.
93
93%
Does it follow best practices?
Impact
94%
1.02xAverage score across 10 eval scenarios
Passed
No findings from the security scan
{
"context": "Taken literally the card has five yes/no facts, so 32 applications - but 'score 780 or above' cannot hold while 'score 700 or above' is false, which makes 8 of the 32 impossible, and the large-loan discount does nothing below 700, which makes the loan-size fact irrelevant across another 8. Predicted baseline failure: the agent writes one section per line of the card, restates each adjustment correctly, and produces a test list of six or seven illustrative applications with no statement of how many distinct applications exist or how the list was cut down from them. Where it does build a table, it treats the two score facts as independent and prices rows such as 'score below 700 but 780 or above', which no applicant can be. The output looks disciplined - correct arithmetic, tidy sections - and its coverage is unmeasurable, which is exactly the failure the previous attempt shipped.",
"type": "weighted_checklist",
"checklist": [
{
"name": "Deliverable exists",
"description": "A file named loan-rate-card-analysis.md exists and contains a table of application kinds with rates. Scores zero if absent or if it contains only per-adjustment prose.",
"max_score": 5
},
{
"name": "Full size of the problem stated before reduction",
"description": "The document states how many applications the five facts describe in principle - 32 - before narrowing, and shows that number rather than starting from an already-shortened list. An equivalent statement is acceptable if the score facts are restructured first, provided the document says what the restructure removed. Scores zero if no count of the whole space appears anywhere. Scores at most half if a count appears but is wrong and unexplained.",
"max_score": 22
},
{
"name": "The two score facts handled as one number",
"description": "The document recognises that 'score 780 or above' entails 'score 700 or above', and either marks the 8 applications where the first is true and the second false as impossible, or restructures the two facts into a single input with three bands (below 700, 700 to 779, 780 or above). Scores zero if the two are priced as independent yes/no facts anywhere in the table, since that produces rows for applicants who cannot exist. Scores at most half if the entailment is mentioned in prose but the table still carries independent rows for both.",
"max_score": 28
},
{
"name": "Reachable count reconciled",
"description": "The document lands on 24 genuinely possible applications (three score bands times the other three facts) and says how it got there from 32. Scores zero if no reconciliation between the starting number and the final table size appears. Scores at most half if the arithmetic is stated but does not add up.",
"max_score": 18
},
{
"name": "Large-loan discount identified as inert below 700",
"description": "The document states that loan size changes nothing for applicants scoring below 700 - a EUR 30,000 loan and a EUR 5,000 loan both price at the base rate plus or minus the other adjustments - and merges or annotates those applications instead of listing each loan size separately. Scores zero if the document prices a large-loan discount for a sub-700 applicant anywhere.",
"max_score": 16
},
{
"name": "MUST NOT hand over the unreduced set as the test list",
"description": "Anti-pattern guard. The proposed test list is a reduced set derived from the table - roughly 20 applications once the impossible score pairs are removed and loan size is dropped below 700 - not 32 individually written cases, and not a handful of illustrative examples with no stated relationship to the table. Scores zero if 32 cases are enumerated one per combination with no reduction, and scores zero if the list is a short sample with no statement of what it leaves uncovered.",
"max_score": 20
},
{
"name": "Referred-versus-priced ambiguity raised",
"description": "The document flags that the card both refers sub-700 long-term applications to underwriting and prints a price for them, and asks which the system should do rather than deciding. Scores zero if a rate is stated for those applications with no note, and scores zero if they are silently dropped from the table.",
"max_score": 14
},
{
"name": "Rates are computed, not described",
"description": "Each row carries a numeric APR - for example a 780-plus applicant with a current account, a 72-month term and a EUR 30,000 loan prices at 7.5. Scores zero if rows carry adjustment names rather than resulting rates. Scores at most half if rates are present but more than two are arithmetically wrong.",
"max_score": 10
}
]
}