# Follow one business rule from intent to evidence.

A customer wants to cancel an order before fulfillment starts. This small example shows how a business decision becomes a lasting requirement and a testable change.

Canonical: https://peakroai.com/methodology/worked-example/
Updated: 2026-10-27


## About this example

This is a conceptual teaching example, not a customer case study, a deployed system or a measured performance result. The names and identifiers below describe an imagined order-management workflow. They show the artifacts and decisions an RDE process would connect.

## 1. State the business intent

**Outcome:** customers should be able to cancel an eligible order without contacting support, while operations avoids canceling an order already being fulfilled.

The product owner identifies the customer benefit and the operational constraint. Engineering asks where order status is owned and how cancellation will interact with fulfillment.

## 2. Define a persistent requirement

**Requirement EX-001 - Cancel an eligible order**

An authenticated customer may cancel an order they own while its status is `pending`. A successful cancellation changes that order to `cancelled`. An order in `fulfilling` or a later state cannot be canceled through this customer action.

Acceptance criteria make the boundary explicit:

- The customer can cancel their own pending order.
- A customer cannot cancel another customer's order.
- An order already in fulfillment is rejected with an understandable explanation.
- Repeating a successful cancellation does not create another transition or duplicate its consequences.
- If cancellation and fulfillment start concurrently, only one valid state transition succeeds.

Refund behavior is not specified by EX-001. If payment exists in the actual system, the team must define the relevant payment requirements and dependencies before releasing this journey.

## 3. Prepare the current change specification

Suppose the current product supports cancellation only through an operator. The change specification asks for customer self-service using the existing order-state rules.

It identifies the affected customer screen, order API, authorization logic and state transition. It also defines the test plan, error responses and what the release must demonstrate. This specification is temporary work; EX-001 remains the durable definition of intended behavior.

## 4. Make and record the technical decision

Engineering proposes an atomic state transition from `pending` to `cancelled`, performed after checking ownership. That design prevents a stale screen from overriding fulfillment that has already started.

The team records why the decision was made and what it depends on. The agent receives the approved requirement, decision and change scope rather than an unbounded instruction to improve the order system.

## 5. Collect evidence against the requirement

| Scenario | Expected evidence |
|---|---|
| Owner cancels a pending order | API and customer journey checks show one valid transition |
| Different customer attempts cancellation | Authorization check rejects the action |
| Fulfillment already started | Order remains in fulfillment and the response explains the conflict |
| Cancellation is retried | State and downstream effects remain consistent |
| Fulfillment and cancellation race | Concurrency test shows only one transition wins |

These are proposed checks for the example, not claims that tests have been executed. A real implementation would attach actual results and identify its environment and revision.

## 6. Review the outcome and preserve the intent

The product owner evaluates the user behavior. Engineers review the implementation and operational effects. The team considers the evidence and any unresolved exceptions before accepting the change.

The requirement stays linked to its decision and checks after the work item closes. If fulfillment rules later change, those relationships help identify what needs to be reviewed again.

[Read the methodology](/methodology/requirements-driven-engineering/) or [discuss an enterprise system](/services/enterprise-software-development/).