Words Define Systems: The Semantics of Planning in FABRIC

I recently published a piece on david-rush.com about the semantics of planning language — the confusion between Features, Capabilities, and Functions in product decomposition, and between Stories, Epics, and Sagas in work management. The response confirmed what I suspected: this is a pain point that cuts across every kind of engineering organization, from consumer software to regulated product development.

That article made the professional case for precision. This one makes the practitioner case — and goes into exactly how FABRIC resolves these ambiguities in the operating model.

Because the confusion isn’t just terminological noise. It produces planning systems that collapse under their own imprecision. Teams spend half of PI planning debating which level something belongs at instead of reasoning about whether it is correctly decomposed. Programs slip not because the work is too hard but because nobody agreed on what “done” meant at each level. Scaling breaks down because the words mean different things to different teams, so the coordination layer has nothing stable to coordinate against.

Language is architecture. Get it wrong and everything built on top of it is unstable.

The Two Stacks and Why They Stay Separate

FABRIC works with two parallel decomposition stacks that serve fundamentally different purposes.

The product decomposition stack answers the question: what are we building, and why? It is anchored in customer value and system engineering. The work decomposition stack answers the question: how do we organize people and time to build it? It is anchored in team capacity and delivery cadence.

These stacks need to stay conceptually separate because they have different owners, different cadences, and different failure modes. Collapsing them — which most frameworks do by letting Epic sit ambiguously across both — is where the confusion originates.

The Capability Package is the bridge between them. Above it, you are doing product thinking. Below it, you are doing delivery planning. That boundary deserves a name and a clear definition. FABRIC gives it one.

The Product Stack: Feature, Capability, Function

Features are promises made to customers. They live in the market — in option lists, pricing sheets, and competitive differentiators. “Adaptive cruise control with stop-and-go functionality” is a feature. The customer evaluates it, pays for it, and experiences it. The feature says nothing about how the system achieves it. That is intentional. Features belong to the product owner and the market-facing side of the organization.

Capabilities are the system competencies that make features deliverable. “Longitudinal motion control with sub-200ms response to lead vehicle deceleration” is a capability. It describes what the system must be able to do — precisely, verifiably, and traceably to a feature. A capability is either present or absent. You can write a test for it. The systems engineer owns the capability definition.

Functions are the atomic behaviors the system performs in order to realize a capability. “Apply braking torque of X Nm within Y milliseconds upon detection of lead vehicle deceleration exceeding Z m/s²” is a function. It is the unit of design, implementation, and verification. Functions are where ASPICE work products, ISO 26262 safety requirements, and test cases live. The design engineer owns functions.

The traceability chain — Feature → Capability → Function — is not a bureaucratic artifact. It is the mechanism by which a customer promise becomes a verified system behavior. Every link in that chain is a gate against drift: drift between what was sold and what was designed, and drift between what was designed and what was built.

SAFe inverts this by placing Capability above Feature in its planning hierarchy — treating Capability as a large program-level container and Feature as a smaller team-level deliverable. That inversion is coherent within SAFe’s own logic, but it means that “Capability” in a SAFe program and “Capability” in systems engineering are pointing at entirely different things. When your systems engineers and your program managers are using the same word to mean opposite things, your traceability breaks before you have even started.

FABRIC holds the outside-in order. Features face the customer. Capabilities face the system. Functions face the verifier.

The Work Stack: Story, Work Package, Capability Package, Initiative

Stories are sprint-bounded. One team, one sprint, one clear done condition. The done condition is not “code written” or “reviewed” — it is “the behavior this story was supposed to produce is demonstrably present.” If a story cannot close within the sprint, it is not a story. It is a failure of decomposition, and the right response is to decompose it, not to extend the sprint.

The discipline here matters more in regulated development than anywhere else. When your evidence of process capability is built from completed work products, an incomplete story is a gap in your evidence chain. ASPICE and DO-178C do not have a “mostly done” category.

Work Packages — which most practitioners know as Epics — are the quartile container. One team, one quarter. The natural shape is one enabling sprint establishing the technical foundation followed by five delivery sprints, giving a six-sprint cycle that aligns with the business quarter. This is not arbitrary. A quarter is the shortest cadence at which investment decisions, capacity commitments, and program reviews can meaningfully occur. The Work Package resolves at the quarter boundary — a decision point, not just a calendar date.

The literary borrowing is actually apt here. An Epic in the classical sense is a long narrative that reaches genuine resolution. A quarterly work cycle should do the same. You should be able to point to a Work Package at quarter close and say: this team, this quarter, this outcome — complete.

Capability Packages are where the model adds something that most frameworks either omit or handle badly. They exist to handle two specific conditions that break the single-team/single-quarter assumption:

The first condition is multi-quarter scope. Some capabilities simply cannot be delivered in a single quarter. A new propulsion control architecture. A complete cybersecurity hardening program across a vehicle platform. A migration from a legacy ALM to a model-based toolchain. These take multiple consecutive Work Packages before the capability is verifiable. You need a container that owns the capability definition across those quarters and maintains the done condition at the capability level, not just the Work Package level.

The second condition is multi-team scope. Some capabilities require parallel or sequential contribution from multiple teams before they are verifiable. The software team delivers the control algorithm. The hardware integration team validates it on target. The safety team produces the functional safety argument. None of these teams individually owns “capability delivered” — the Capability Package does.

This is the key semantic point: the Capability Package has a different done condition than the Work Packages beneath it. The Work Package asks “did this team complete their quarter’s work?” The Capability Package asks “can the system now do this thing?” These are different questions. That is not a size distinction. It is a nature distinction.

Saga, as a term, can live here legitimately. The Norse sagas were multi-generational narratives spanning many actors across many seasons before resolving. That maps honestly to a multi-team, multi-quarter delivery arc. The problem with Saga in most frameworks is not the word — it is that it floats without anchor conditions. In FABRIC, the trigger conditions are explicit and testable: if the delivery requires more than one quarter or more than one team, you are in Capability Package territory.

Initiatives are the strategic horizon — the multi-year investment arc within which Features and their associated Capability Packages are authorized and funded. An Initiative is not a delivery unit. It is a commitment to a direction.

The DRIPS View Across the Stack

FABRIC uses DRIPS — Decides, Responsible, Informed, Provides, Safeguards — rather than RACI, because RACI conflates accountability and execution and produces committees where there should be individuals. The responsibility pattern across the work stack is worth stating explicitly.

At the Capability Package level, the Systems Architect Decides the capability definition and done condition. The Program Lead is Responsible for coordination across teams and quarters. The Product Owner is Informed of progress against the capability arc. The individual Work Package owners Provide their quartile deliverables. The Safety or Compliance Lead Safeguards the evidence integrity.

At the Work Package level, the Team Lead Decides the sprint plan. The team collectively is Responsible for delivery. The Systems Architect is Informed of progress. Individual engineers Provide story-level deliverables. The quality function Safeguards the done condition.

At the Story level, the engineer assigned is both Decides and Responsible. The team is Informed via the board. No safeguard is required at story level — the Work Package done condition gates the aggregate.

The reason this matters: when RACI puts multiple people as Accountable, decisions slow down. When DRIPS puts exactly one person as Decides at each level, the hierarchy has a spine. You can trace a decision about capability definition all the way down to the story that implements a function, and know who made each call and why.

Why This Resolves the Saga Problem

Most frameworks introduce Saga when they run out of hierarchy. They have Stories, Epics, and Features, and then they discover that some Features are too large for a single program increment, so they invent a container above Feature and call it a Saga. The problem is that Saga, defined this way, is just a bigger Feature. It has no distinct semantic identity. It is a size category, not a nature category.

FABRIC does not put Saga above Feature. Feature is already the multi-quarter market arc. What goes above the Work Package but below the Feature is the Capability Package — and its identity is not “bigger Epic” but “the unit at which system competency is verified across teams and time.”

If you want to use the word Saga for Capability Package, FABRIC does not object. Words are conventions. What matters is that the concept has:

• A clear trigger condition (multi-quarter or multi-team)
• A distinct done condition (capability verified, not stories closed)
• A named owner who carries accountability for the full arc
• Explicit traceability to the Feature above and the Work Packages below

Give it those four properties and you can call it whatever your organization’s conventions prefer. Strip any one of them and you are back to floating hierarchy.

The Practical Test

When you are in a planning session and someone asks “is this an Epic or a Capability Package?” — the answer comes from two questions, not from the size of the backlog.

First: does this delivery require more than one quarter, or more than one team? If either answer is yes, you are in Capability Package territory.

Second: when you write the done condition, does it read “team has completed their quarter’s work” or “system can now demonstrably do X”? If it reads the second way, you are in Capability Package territory regardless of how many sprints it spans.

The discipline of asking these questions explicitly — rather than defaulting to “it feels big so it must be a Saga” — is what keeps the planning hierarchy honest. And a planning hierarchy that is honest about the nature of work at each level is one that produces forecasts you can trust, evidence you can defend, and systems that actually do what the customer was promised.

That last sentence is the whole point. The semantics of planning are not a philosophical luxury. They are a quality system.

---

David Rush is the creator of the FLOWCraft methodology and the FABRIC operating model for regulated product development. He has spent 30+ years working at the intersection of systems engineering, process methodology, and flow-based thinking across automotive, aerospace, and critical infrastructure. This article is part of the FLOWCraft Series on flowcraft.blog.