The Stefel Method
From business intent to working code —
with nothing lost in translation.
Four levels. One source of truth for every acceptance criterion. A generator that compiles instead of guessing. This is the requirement architecture Craftingtable is built around.
Why a method, not just a tool
Specs drift from code. Business intent gets paraphrased on the way to a ticket, and paraphrased again on the way to a pull request — by the time an AI agent sees the task, it's working from a summary of a summary, and it hallucinates to fill the gaps.
The Stefel Method closes that gap by making one rule non-negotiable: a Gherkin acceptance criterion is written exactly once, on the Business Case, and every level below it — the story, the screen, the component, the generated work package — references that same criterion instead of restating it. Nothing downstream can drift from intent, because nothing downstream owns its own copy of it.
The path, end to end
Six stops. Each one is a module you can open in Craftingtable right now.
L1
Business Case
Gherkin intent
L2
User Story
Dev-ready scope
L3
Screen & Path
Flow & structure
L4
Technical Spec
Schema, design, skills
⚙
Generate
Deterministic work package
↗
Export
Human-readable handoff
The four levels
Each level is a different abstraction, with its own format and its own audience — a ladder from boardroom to codebase.
L1
Business Case
Captures why a feature matters, in a form that's testable from day one. Every acceptance criterion in the project lives here, and only here.
- Format
- Gherkin — Given / When / Then
- Speaks to
- Decision-maker, product owner
L2
User Story & Epic
Turns intent into a dev-ready story without rewriting the Gherkin. It references the Business Case's criteria and decides which ones generate real work.
- Format
- As / Want / So + referenced AC
- Speaks to
- Business analyst, architect
L3
Screen & Path
Maps the user's journey and the system's logic — navigation, decisions, C4 views — before a single component gets built.
- Format
- Flow graph — screens, routes, logic
- Speaks to
- Architect, UI/UX
L4
Technical Spec
The exact, unambiguous ingredients the generator needs: data models, design tokens, file paths, and technology-specific standards.
- Format
- Components, schemas, tokens, skills
- Speaks to
- Developer, AI agent
One AC. One task. One test.
An acceptance criterion's When / Then / And steps carry a double life — they define the task and the test for it, at the same time.
AC-1 · on Business Case BC-004
Given a visitor opens the pricing page
When they select the "Team" plan
Then checkout starts with the Team price pre-filled
User Story DEV-004 references AC-1 and marks it generatesTask: true.
Who sees what
The four levels double as a role filter. Everyone gets the altitude they need, never the whole mountain.
| Role | Sees | Edits |
|---|---|---|
| Business side — BA, PO, CTO | L1 + L2 | L1 – L2 |
| Analyst / architect | L2 + L3 | L2 – L3 |
| Developer, AI agent | L3 + L4 | L3 – L4, generated Work Package |
Beyond the four levels
The levels define the specification. Three more modules carry it into daily work and back out to the people who need to read it.
Blueprints — a living board, not a snapshot
Flow nodes and User Story steps are continuously turned into Parts, organized into Blocks by tech area. Unlike a Work Package, a Blueprint is long-lived and freely editable — rename, re-prioritize, or drag a Part into another Block without losing its source.
Generate — the deterministic heart
No AI runs during generation. The engine walks the traceability graph and compiles each task-generating acceptance criterion into one atomic, self-contained Markdown brief. The same project state always produces the same bundle hash — reproducible, not guessed.
Export & Handoff — built for humans too
Not every stakeholder reads JSON. Export the full specification, a sprint's worth of work packages, versioned Docusaurus docs, a print-ready HTML page, or a changelog between two Git revisions — assembled, never regenerated.
See it module by module
Every level and every supporting module has its own breakdown — what it stores, who creates it, and exactly how it connects to the rest of the graph.