Stable Use Cases

Product Intent records why a product exists and which outcomes and priorities guide product decisions. Personas and Actors records the people, roles, goals, responsibilities, authority, and operating conditions that materially affect product reasoning. A delivery team also needs a durable statement of the recurring purposes those people expect the product to support; a Stable Use Case records one of those purposes. It states what a recognizable class of product use should continue to achieve as the product evolves. Within Specification-First Delivery, that record remains stable enough to guide many delivery increments while later specifications define the detailed behavior and acceptance conditions of a particular change.

Back to top

1. Definition and Knowledge Responsibility

A Stable Use Case is durable product knowledge that states a recurring product-facing purpose of one or more personas, the recognizable outcome the product should continue to support, and any product-level conditions needed to preserve the meaning of that outcome.

Three defining elements establish what the record contains.

Recurring product-facing purpose identifies something a persona repeatedly needs the product to help accomplish. Cockburn's user-goal level is a useful reference point: it focuses on the goal the primary actor is trying to accomplish through the system, and Cockburn argues that the supported user goals provide a compact summary of system function.¹ That level is high enough to express meaningful product value while keeping lower-level steps and technical subfunctions subordinate to the goal.

Recognizable outcome states what successful use should continue to achieve. The outcome remains understandable to the affected personas when the interface, workflow implementation, service decomposition, or underlying technology changes.

Product-level invariants preserve conditions whose loss would materially change the meaning of the purpose or outcome. They are included when the outcome alone would permit materially different product interpretations. Increment-specific specifications make the applicable behavior precise enough for implementation, verification, and acceptance.

Two qualifications determine whether those elements sit at the stable use-case level.

Implementation independence means that the recurring purpose, recognizable outcome, and product-level invariants remain meaningful after substantial interface and implementation replacement. Constantine and Lockwood describe essential use cases as abstract, generalized, technology-free narratives centered on user intention and system responsibility, explicitly separating that level of description from concrete user-interface design.² Stable Use Cases apply the same discipline: current controls, API calls, screen sequences, and implementation modules remain outside the record unless they express a product-level invariant that must survive redesign.

Lifecycle durability means that the record normally remains useful across several delivery increments. Revision becomes appropriate when product strategy, a durable persona goal, the represented operating model, an applicable invariant, or another product-level decision changes its meaning. The word stable names the combined quality produced by implementation independence and this product-level revision threshold.

Back to top

2. Relationship to Product Intent, Personas, and Actors

Product Intent, Personas and Actors, and Stable Use Cases answer connected questions at different levels of durable product knowledge.

A Stable Use Case materializes relevant persona goals into durable product knowledge. A persona also contains expertise, authority, workload, constraints, pain points, dependencies, and other operating context that can affect delivery without becoming a separate recurring product purpose.

The persona-to-scenario lineage in Goal-Directed Design helps clarify this relationship. Cooper, Reimann, Cronin, and Noessel describe context scenarios as broad, relatively shallow stories of a persona using a future product to pursue goals, including environmental and organizational conditions before detailed interaction design is introduced.³ The emphasis is on what the persona is trying to accomplish and the context that shapes that attempt. Requirements-engineering research has used personas more broadly as well: a 2023 systematic mapping study selected 78 relevant studies and found personas used to support stakeholder understanding, human-centered requirements work, and requirements-engineering activities, while also identifying challenges in persona creation, validation, and incorporation.⁴

Stable Use Cases preserve the recurring purposes discovered through that human context without copying the complete persona into every use case. The result is a connected model in which Product Intent supplies product direction, personas supply operating reality, and Stable Use Cases preserve the recurring product outcomes that later delivery should continue to recognize.

Zoom out

100%

Zoom inReset zoom and position

A later increment can load the relevant use case together with the personas that give it operating context. The participant then knows both the outcome that should remain recognizable and the human conditions that may change how the current requirement should be interpreted.

Back to top

3. Persona Traceability and Knowledge Consistency

Stable Use Cases and operational personas have a many-to-many relationship. One persona may participate in several Stable Use Cases, and one Stable Use Case may serve several personas whose operating contexts differ materially.

Specification-First Delivery applies one explicit consistency requirement:

Every Stable Use Case must trace to at least one operational persona.

A recurring user purpose needs at least one represented class of people who has that purpose. When a proposed Stable Use Case has no applicable persona, Structured Discussion should determine which product knowledge is incomplete. The use case may expose a genuine user or operating context missing from the persona library. It may instead be a proposed feature, implementation convenience, or obsolete assumption without a durable represented user purpose.

The reverse review exposes a different class of question. A persona can contain material product-facing goals for which no Stable Use Case exists. Some goals may sit outside current Product Intent or be satisfied outside the product. Others may reveal a recurring purpose that the Knowledge System has never recorded.

This use of relationships as an analytical tool has precedent. Sim and Brouse integrate personas with viewpoints, scenarios, tasks, goals, and requirements in a Concept Development Process intended to improve understanding of users and identify missing requirements early.⁵ Their work makes the relationships themselves inspectable rather than treating persona documents as isolated descriptions. For Stable Use Cases, the maintained persona-to-use-case relationship serves a similar diagnostic purpose: a missing link creates a concrete product question that can be routed to the appropriate authority.

Zoom out

100%

Zoom inReset zoom and position

The implementation remains proportionate. Simple links or identifiers may be enough for a small product; a larger platform may use a directory, routing Skill, knowledge graph, requirements tool, or governed document relationships. The framework requirement is inspectable traceability under clear authority.

Back to top

4. Representative Scenarios and Recognizable Outcomes

Teams usually discover use cases through concrete situations in research, support, operations, existing workflows, requirements, and domain knowledge. Those situations help establish and test a Stable Use Case; they can remain representative scenarios under one record when they express the same recurring purpose, recognizable outcome, and product-level invariants.

Scenario-based requirements engineering provides a useful model for that supporting role. Sutcliffe, Maiden, Minocha, and Manuel describe scenarios as paths of possible behavior through a use case, then investigate those paths to elaborate requirements.⁶ A concrete scenario can therefore reveal missing conditions, exceptions, assumptions, or differences without changing the level at which the durable use case is recorded.

Consider an AI Travel Planner. Research and operations may surface weather disruption, transport cancellation, venue closure, fixed events, staggered arrivals, or subgroup travel. The product should first ask which recurring purposes these situations represent, then keep the concrete situations as representative scenarios under the appropriate Stable Use Case.

These records preserve what should remain recognizable without deciding how alternatives are searched, conflicts are displayed, cancellation costs are calculated, or confirmation works. Those decisions belong in the applicable Functional Specification, architecture, specialist specification, technical specification, or test specification when an increment needs them.

The implementation-independence test imagines a substantial interface and implementation replacement. A record sits at the stable use-case level when its recurring purpose, recognizable outcome, and product-level invariants remain meaningful after that replacement. Current controls, service calls, screen sequences, and detailed error paths belong to a more specific specification.

Back to top

5. Structured Discussion and Decision Authority

Stable Use Cases are established through Structured Discussion. Participants compare persona goals, representative scenarios, Product Intent, existing behavior, domain knowledge, and current requirements to decide which recurring purposes deserve durable representation.

The discussion should establish:

• which persona goal is being materialized and which personas share it;

• which observed situations are representative scenarios of the same recurring purpose, recognizable outcome, and product-level invariants;

• which differences indicate a separate Stable Use Case because the purpose or recognizable outcome changes materially;

• which product-level invariants are needed to preserve the meaning of the purpose or outcome;

• whether the record passes the implementation-independence test;

• whether the record contains current implementation detail that belongs in a later specification;

• whether every proposed use case has an applicable persona; and

• whether material persona goals reveal missing use cases or another product decision.

The scenario inquiry described above gives the discussion concrete material to test. Decision authority determines what the organization accepts from that inquiry. A Product Owner, Product Manager, or equivalent product decision owner typically has primary authority over whether a recurring purpose belongs in the product. Domain participants contribute operating knowledge. Engineering exposes implementation assumptions and consequences. Specialist functions contribute decisions within their own professional authority.

AI can group candidate scenarios, locate persona records, identify missing traceability, compare outcomes, and draft candidate updates. Accountable human roles decide what becomes authoritative product knowledge. A participant who discovers an inconsistency makes it visible; the role with the relevant authority resolves the underlying decision.

Back to top

6. Relationship to Increment-Specific Specifications

Stable Use Cases operate upstream of increment-specific specifications. Most increments change behavior associated with one or more Stable Use Cases, so Structured Discussion interprets the proposed change against that durable context. A Functional Specification then defines the supported behavior, normal and exceptional paths, invalid states, user-facing outcomes, and acceptance conditions required for the increment. Other specialized specifications add decisions within their professional responsibilities, and technical and test specifications make the reviewed conditions executable and verifiable. Product-level review is required when the proposal would materially change the recurring purpose, recognizable outcome, product-level invariants, or participating personas themselves.

Earlier use-case methods also explored how a durable view of user goals can coexist with incremental delivery. Jacobson, Spence, and Kerr developed Use-Case 2.0 around this problem: use cases retain the broader view of what the system should support, while use-case slices select portions of that behavior for implementation within an increment. Their model connects those slices with architecture, design, testing, and user experience, allowing incremental delivery to proceed while preserving the larger user-oriented structure.⁷ The relevant precedent for Stable Use Cases is this separation between durable product context and increment-sized delivery work. Specification-First Delivery applies that separation by keeping recurring purpose, recognizable outcome, and product-level invariants in the Stable Use Case, while the increment's Specification Set carries the detailed behavioral, specialist, technical, and verification decisions.

Specification-First Delivery assigns the Stable Use Case a narrower Knowledge System responsibility. The Stable Use Case preserves recurring purpose, recognizable outcome, and product-level invariants across increments; the increment's Specification Set owns the detailed functional, specialist, technical, and verification decisions. For the AI Travel Planner, partial journey re-planning may therefore remain one Stable Use Case while separate increments add rail-cancellation handling, cancellation-cost previews, or a new itinerary interface.

Back to top

7. Establishment and Maintenance Procedure

A team can establish Stable Use Cases from existing product knowledge without first constructing a complete catalogue. It should create enough durable coverage for the personas and responsibilities that current delivery depends on, then improve the model as Structured Discussion exposes material gaps.

During preparation, move shorter-lived decisions to the knowledge artifact that owns them. UI controls, workflow sequencing, API decisions, model prompts, implementation modules, error copy, thresholds, and executable acceptance checks can be important without belonging in the Stable Use Case.

Material changes to the recurring purpose, recognizable outcome, product-level invariants, or applicable personas follow the product and domain authority appropriate to the change. This revision threshold gives the record its lifecycle durability. When delivery itself alters the underlying knowledge, Knowledge Convergence Across the Increment Lifecycle provides the broader mechanism for returning that learning to authoritative current-state knowledge.

Back to top

8. Reference Representation

Specification-First Delivery permits several Stable Use Case representations. A useful representation makes the recurring purpose, participating personas, recognizable outcome, product-level invariants, authority, and relevant relationships inspectable.

Stable Use Case ID:
Title:

Recurring Purpose:
Participating Personas:
Recognizable Outcome:
Product-Level Invariants (when needed):
Representative Scenarios:
Related Product Intent:
Decision Owner:

Optional Scenario Family:

Optional Provenance:
- Raised by:
- Observed or discussed:
- Reference:

Recurring Purpose, Recognizable Outcome, and Product-Level Invariants make the three defining elements inspectable. Participating Personas establishes required traceability and may list several personas. Representative Scenarios test the use case against concrete situations without redefining it as one observed workflow. Related Product Intent connects the use case to the product-level outcome or priority it serves. Decision Owner identifies who can confirm a material interpretation or revision. Implementation independence is assessed across the defining elements, while product-level revision authority maintains lifecycle durability. Optional Scenario Family is useful only when a larger catalogue uses that organization layer.

Provenance is optional and proportionate. Stable Use Cases are directional product knowledge, while acceptance evidence has a separate downstream responsibility. Recording who raised a use case, when it was discussed, or which research, support case, or operational observation explains its origin can still help future participants reconstruct context.

An AI Travel Planner record might therefore state:

Stable Use Case ID: travel-partial-replan
Title: Partial journey re-planning after external disruption

Recurring Purpose:
Allow a traveler to recover a usable journey when an external event invalidates
part of an established plan.

Participating Personas:
- Independent traveler
- Group trip coordinator

Recognizable Outcome:
The traveler has a coherent revised journey that addresses the disrupted portion.

Product-Level Invariants:
- Unaffected commitments remain represented.
- Material consequences are understandable before confirmation.
- The revised journey remains coherent for participating travelers.

Representative Scenarios:
- Transport cancellation
- Severe weather
- Venue closure

Related Product Intent:
Keep itinerary planning understandable and adaptable as real travel conditions change.

Decision Owner:
Product Owner

Optional Scenario Family:
Journey disruption and recovery

A future Functional Specification can decide detection, alternative selection, cost calculation, unavailable-state behavior, and confirmation rules without changing this record unless those decisions alter its underlying recurring purpose, recognizable outcome, product-level invariants, or participating personas.

Back to top

9. Validation and Readiness Criteria

Stable Use Case validation is a knowledge-adequacy review. It determines whether a qualified participant can use the records to understand durable product purpose and identify when a more specific decision is required.

These checks extend the unfamiliar-participant test. A qualified participant with no prior product history should be able to read the Product Intent, applicable personas, and Stable Use Cases and explain who the product serves, which recurring purposes matter, which outcomes and product-level conditions future delivery should continue to recognize, and who should resolve a material inconsistency.

Adequacy means there is enough durable structure for future increments to start from established user purpose instead of reconstructing it from the current implementation. New scenarios can expand the evidence under an existing use case, expose missing personas or use cases, or trigger material revision when the underlying product need changes.

Back to top

10. Scaling the Stable Use Case Library

A product should start with the simplest representation that makes its Stable Use Cases discoverable and reviewable. A small product may keep the entire catalogue in docs/use-cases.md. Each use case can be a short, clearly identified record with its participating personas, recurring purpose, recognizable outcome, product-level invariants, representative scenarios, and decision owner.

As the catalogue grows, separate files become useful when use cases have different owners, evidence, review histories, or loading needs. At that point, docs/use-cases.md can evolve into a docs/use-cases/ directory. docs/use-cases/README.md becomes the maintained catalogue and routing entry point, while each Stable Use Case receives its own Markdown record.

A Scenario Family is an optional organizational layer for a large catalogue. It should be introduced when the number of Stable Use Cases makes a flat index difficult to navigate, not as a required part of every Stable Use Case definition. A family groups several Stable Use Cases that belong to a recognizable area of product usage while each use case keeps its own recurring purpose, recognizable outcome, product-level invariants, persona traceability, authority, and lifecycle.

The organizational problem has an earlier use-case analogue. Cockburn separates user-goal use cases from higher summary-level use cases, with summary use cases tying several user goals together to provide larger context.¹ A Scenario Family here has a lighter responsibility: it helps readers and AI locate related Stable Use Cases in a large Knowledge System. It does not add a new product requirement or replace the underlying use cases.

For example, an AI Travel Planner might eventually group Partial journey re-planning after external disruption, Recovering from a missed connection, and Replacing an unavailable booked activity under a Journey disruption and recovery family. A smaller product with only a handful of use cases gains little from introducing that extra label.

The same Progressive Context Loading pattern used for personas can support a large use-case library. When simple file discovery is no longer sufficient, an optional use-case-directory Skill can list compact use-case summaries, optional Scenario Families, and load paths. The agent reads the directory first, then loads only the Stable Use Cases relevant to the current product question.

A compact router might contain entries such as:

# Stable Use Case Directory

## Journey disruption and recovery

- `travel-partial-replan` – revise an affected journey portion after an external disruption
  - Load: `docs/use-cases/travel-partial-replan.md`
  - Use for: disruption handling, itinerary recovery, preserving unaffected commitments

- `travel-missed-connection-recovery` – recover a usable journey after a missed connection
  - Load: `docs/use-cases/travel-missed-connection-recovery.md`
  - Use for: missed connections, downstream transport impact, journey recovery

This Skill is a routing aid and contains only a brief description of each use case. The authoritative recurring purpose, recognizable outcome, product-level invariants, persona relationships, and decision owner remain in the Stable Use Case records. Knowledge System Readiness for Specification-First Delivery owns the broader repository convention for root skills/, coding-agent discovery paths, and optional symlink compatibility.

A scaled repository-centered implementation can therefore look like this:

The framework requirement remains discoverable, governed Stable Use Case knowledge with reliable persona traceability. One file, a multi-file catalogue, Scenario Families, and a routing Skill are progressively richer implementations adopted only when the product creates a concrete navigation or maintenance need.