The Impact Read
Catching the missing scenario before the sprint, not after it.
A single user story, written the way stories are normally written.
Modules, endpoints and schema relations — and the three nobody wrote down.
A manifest the owner takes into refinement, before anyone writes code.
A product owner brings one change. The kit reads the codebase and the schema around it and returns the surface that change actually touches — including the categories that historically surfaced only after delivery, at three to four per feature.
A defect here is not a bug. It's an invoice a customer can see.
A global leader in bulk liquid logistics, chemical tankers and terminal infrastructure. The customer portal at the centre of the engagement is used by 90% of their corporate clients worldwide.
The pattern repeated every release. Three to four edge scenarios per feature went undiscovered until after development had delivered: an invoicing rule that excluded a trade lane, an order state transition nobody had validated, an upstream record that updated hours after the portal expected it. Each one reopened a closed sprint story and pushed two to eight weeks of cascading delay into the roadmap.
And the governance was strict. No third-party cloud. No external crawlers against production databases. No enterprise IP leaving the building. Whatever solved this had to run locally, inside the workflow developers already used.
Eight of the nine candidate initiatives were dropped.
The engagement started with nine candidate initiatives on the table. Most were the automations that get proposed everywhere — reporting, ticket triage, onboarding.
Reading the history of actual production defects pointed somewhere else. The failures weren't happening in QA. They were happening upstream: specifications were checked against the business request, but never against the database schemas and legacy dependencies they would land on. Nobody read the code against the requirement before the requirement became code — because by hand, across a dependency graph and multi-tier schemas, that costs more than the bug.
That is the specific shape of work a model does well: read a lot, cross-reference exhaustively, never get bored.
Two passes over a local snapshot. No servers.
Pass one — impact inventory. Reads the incoming user story against the codebase dependency graph, the API surface and the schema definitions, and produces a structural manifest of everything the change will touch.
Pass two — domain cross-examination. Tests that manifest against a two-tier checklist: tier one is verified historical misses, drawn from real production defects; tier two is predictive edge scenarios. It flags the logic blind spots before a developer writes a line.
No data leaves the machine. It installs in five steps and lives where the developers already are — which is the only reason it stood a chance of being used.
What the Product Owner receives before the sprint.
Illustration only. This is how one run's output reads — a report the engine writes each time, not a platform or a live screen. Figures are sample data.
The surface a story touches, and the scenarios nobody wrote down. Every finding carries its citation back to the source.
Evidence
Separated by how it is known. Nothing here is a projection presented as a result.- 7 of 7 technical verification gates passed against a synthetic environment mirroring real production invoicing defects, with 47 code citations verified against source and no unsupported findings.
- The Product Owner put the kit into use on the portal's development cycle, and reported fewer defects reaching delivery and less reopened sprint work.
- Payback threshold: a single prevented missing scenario repays 100% of the setup effort (40–80 developer hours; 34 measured in executable dry-runs) by avoiding one reopened sprint story.
- Five-page implementation plan, six-slide executive deck for IT sponsorship, and the autonomous developer kit: installation guide, technical brief, both pass prompts, the domain checklist and reference test cases.