Probe the solution against edge cases and failure conditions
Generates and tests the solution against a set of adversarial edge cases — unusual inputs, boundary conditions, and failure scenarios — to expose fragility before client delivery.
In / outSolution specification + constraint boundaries → edge case test log (scenarios tested, behaviours observed, failure modes, recommended fixes)
You might say…
“Our solution worked beautifully for the 80% case and fell apart on the first exception the client tried — probing edge cases is what separates a demo from a real solution.”
What it does
Single-judgement skill: the consultant points it at the built solution and it generates the hard cases — boundary conditions, adverse scenarios, and assumptions most likely to break — then reasons through whether the solution survives each, naming where it degrades or fails and how exposed that failure is. Used during internal validation to stress the design beyond the happy path before the client relies on it, with the consultant judging which exposures matter; distinct from the general quality review by its scenario-driven, breaking-it focus.
Trigger: Use after the internal QA review, before the client receives the solution; provide the solution specification and any known constraint boundaries.
Recognise the problem?
The primitives are the commodity part. The fastest next step is a conversation about composing them into something that works for you.
Start a conversation