Outcome-Driven
Context Modeling.

Define outcomes and metrics

Start by articulating the outcomes a capability must produce — and there is rarely just one. An outcome is an observable change in the attitude or behaviour of people: customers, employees, or other stakeholders. If nothing changes, no value — good or bad — was created.

Defining outcomes this way keeps the focus on real-world impact, not outputs or deliverables, and gives every downstream activity a measurable target.

Identify the capabilities that deliver those outcomes

The first capability you find is usually core to why the organisation exists — a product or a service. If your outcomes point only at a supporting capability, that is a signal you have not found the real outcome yet; supporting capabilities exist to improve the core value stream.

Each capability is a domain of knowledge — a distinct context, with its own language and expertise.

Identify the activities — and their metrics

The processes inside a context are activities; their individual outcomes combine to deliver the capability’s outcome. Once an activity’s outcome is clear, KPIs show how well you are progressing toward it — evidence of what is working and where the gaps are.

Reading that data in the context of each capability tells you exactly which activities to introduce, improve, or scale, so effort lands where it has the most impact.

Identify the systems each activity consumes (optional)

Most activities rely on systems — applications, platforms, infrastructure. Mapping which systems serve which activities clarifies dependencies and integration points and surfaces opportunities to automate.

It also connects business activities to the underlying technology services that support them, so technology investment lines up directly with value delivery.

For each activity, discover the interactions that produce its metrics

Delivering an activity means interacting with other systems and people — and those interactions are where performance is made and measured.

The critical discipline: do not describe how an interaction happens. Describe the outcome of the interaction between two systems, in the past tense — “application submitted,” “payment captured.” That single rule is what keeps the model unbiased and implementation-agnostic.

Move to operational specifications: the slice

The outcome model places each interaction outcome inside a slice — a self-contained unit that holds everything required to produce that outcome. Here you identify the new or updated facts the interaction should leave behind.

This is usually the moment you discover missing interaction outcomes and fold them back into the model.

Apply the interaction pattern

This is where the approach gets its simplicity — there are only three patterns:

• Interaction — add new information to the system.
• Automation — listen for relevant outcomes and decide whether a follow-up action is required.
• View — present the current state of one or more systems.

The arrows in the model automatically validate that every fact a slice needs is available — exposing any dependency on outcomes in other activities or contexts.

Capture the scenarios within each slice

A single interaction rarely has just one path. A scenario is a Given / When / Then branch through a slice: given certain facts are present, when its business rules hold, then a specific outcome is produced.

This is where the decision logic lives — the same interaction can resolve to different outcomes (approved vs. declined, eligible vs. not), each with its own rules and, where needed, its own fact calculation. Capturing every scenario makes the slice’s behaviour explicit and complete: the model now states not just what outcome is wanted, but under which conditions each variant fires.