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": "The policy is written as four sentences about four kinds of person, each sentence bundling employment type, clearance, hour and escort together. The reader actually turns on four separate facts - permanent employee or contractor, lab clearance held, inside core hours, escort present - giving 16 situations. Predicted baseline failure: the agent lifts the policy's own phrasing into its input list, producing rows such as 'contractor with lab clearance' or 'employee outside core hours', which are two facts glued together. Once the inputs are compound, the situations stop being enumerable: the document ends up with four or five scenarios mirroring the four policy sentences, every one of them accurate, and the escorted out-of-hours cleared contractor - the situation the policy never covers - has nowhere to appear. Nothing on the page looks wrong, because everything on the page is a faithful restatement of a sentence that exists.",
"type": "weighted_checklist",
"checklist": [
{
"name": "Deliverable exists",
"description": "A file named door-access-analysis.md exists and contains a per-situation table. Scores zero if absent or if the content is a restatement of the policy in bullet form.",
"max_score": 5
},
{
"name": "MUST NOT list compound facts as inputs",
"description": "Anti-pattern guard. Each listed input is a single yes/no question the reader can evaluate on its own: permanent employee, holds lab clearance, inside core hours, escort present. Scores zero if any input row bundles two of these - 'contractor with clearance', 'employee outside core hours', 'unescorted contractor' - because a bundled row makes the situations impossible to enumerate. Scores at most half if the four atomic facts are named but the table's rows are still keyed by the policy's four sentences rather than by the facts.",
"max_score": 28
},
{
"name": "All sixteen situations accounted for",
"description": "All 16 combinations of the four facts are traceable in the table, each with a stated result or an explicit note that the policy does not settle it. Situations may be merged where a fact provably makes no difference, provided the merge names that fact. Scores zero if fewer than 16 can be traced, or if the table has one row per policy sentence. Scores at most half if 16 appear with several carrying no result.",
"max_score": 27
},
{
"name": "The escorted out-of-hours cleared contractor is raised",
"description": "The document identifies that a contractor who holds clearance, arriving outside core hours, accompanied by an escort, is not settled by the policy: the escort sentence is written for contractors without clearance, and the clearance sentence is limited to core hours. Scores zero if that situation is given a confident result - granted or refused - with no note. Scores at most half if raised only as a general remark that the policy has gaps, without pinning it to that situation.",
"max_score": 22
},
{
"name": "Refusal is a result in its own right",
"description": "The reader's refusal, with the 'contact your site manager' display, appears as a distinct result alongside entry, and refused situations are present in the table. Scores zero if the table lists only the situations where the door opens.",
"max_score": 12
},
{
"name": "Escort not marked as irrelevant where it changes the log",
"description": "Because every escorted entry is written to the review log, the escort fact changes the result in every situation where entry is granted - a cleared permanent employee badging in alone and badging in escorted are two different results. The document must not merge those. Scores zero if escort is marked as making no difference for cleared employees. Merging escort in situations where entry is refused for another reason is correct and is not penalised.",
"max_score": 14
},
{
"name": "Core hours identified as irrelevant for permanent employees",
"description": "The document states that the hour makes no difference to any permanent employee's result - cleared or not, escorted or not - and merges or annotates accordingly. Scores zero if the document schedules separate in-hours and out-of-hours checks for permanent employees as though the policy distinguished them.",
"max_score": 12
},
{
"name": "Badge-in attempts tie back to situations",
"description": "Each proposed physical badge-in names the situation it exercises and what result is expected. Scores zero if the attempts are listed with no mapping back to the table, or if only the granted situations are scheduled to be tried.",
"max_score": 10
}
]
}