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.

Generate compiles WP-DEV-004-01.md — the Gherkin, the pricing screen, the plan schema, the exact file path. Nothing guessed.

Who sees what

The four levels double as a role filter. Everyone gets the altitude they need, never the whole mountain.

RoleSeesEdits
Business side — BA, PO, CTOL1 + L2L1 – L2
Analyst / architectL2 + L3L2 – L3
Developer, AI agentL3 + L4L3 – 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.