ADR-016 — Operational Experience Model¶

Status: Accepted

Date: 2026-07-05

Owner: Architecture Board

Decision Type: Normative Extension

Supersedes: —

Complements: ADR-003 (Canonical Knowledge Model), ADR-007 (Ontology), ADR-015 (Semantic Model)

Context¶

UC-BoK v0.7-alpha completes the Business Knowledge layer of the framework:

Business Objects  →  Capabilities  →  Processes
Events            →  Applications  →  APIs
Domains           →  Patterns      →  Reference Architectures

Every node in the knowledge graph describes what the business is or what it does.

No node describes who does it or how a human experiences it.

This is the gap.

A process like BOPIS is described by its capability requirements, business objects, events, and application dependencies. The framework can answer:

• What capabilities does BOPIS require?
• Which business objects does BOPIS produce?
• Which applications support BOPIS?

The framework cannot answer:

• Who performs BOPIS and in what role?
• What does a store associate actually do during BOPIS?
• Which interactions are triggered?
• What does impact on Reservation propagate to at the human level?

Why this matters¶

A vendor implementing UC-BoK today can map their architecture to the canonical model. They cannot yet validate whether their operational experience — the actual human workflow — is coherent with the knowledge model.

This limits UC-BoK's value as a design reference. It is currently a description framework.

The Operational Experience Model is the layer that makes UC-BoK a design tool.

Why not start from screens¶

The most common mistake in operational modelling is starting from the UI.

Screens are vendor-specific. A picking screen in SAP, Comerzzia, and Manhattan look entirely different. But the underlying task — Pick Reserved Items — is identical across all three.

If UC-BoK catalogued screens, it would become a UI pattern library. That is not the goal.

The canonical unit of the Experience Model is the Task — a unit of work performed by an actor to achieve a business outcome. Tasks are vendor-neutral. Screens are projections of tasks onto a specific application.

Decision¶

UC-BoK will introduce a new normative layer: the Operational Experience Model.

This layer is specified in specifications/016-experience-model/ and implemented through a series of EXP-series catalog extensions.

Layer Definition¶

The Operational Experience Model sits above the Semantic Model and below any UI or vendor-specific implementation:

Process
    ↓
Journey
    ↓
Task           ← canonical unit
    ↓
Interaction
    ↓
Screen
    ↓
UI Component   ← vendor/application specific

Concepts¶

Task as the Canonical Unit¶

A Task:

• Is Actor-specific (different actors perform different tasks within the same process)
• Is Application-agnostic (the task is identical across vendors)
• References Business Objects (the objects manipulated during the task)
• Produces or consumes Events (the state transitions triggered)
• Exercises Capabilities (the capabilities invoked)
• Is composed into Journeys (ordered task sequences)

A Screen is a projection of a Task onto a specific Application. Screens are catalogued in EXP-004 but are explicitly secondary to Tasks.

Relationship to Existing Model¶

The Experience Model does not replace or modify the existing Business Knowledge layer. It extends it with a new axis of description.

Existing relationships that are extended:

The canonical query language will be extended to support:

Show every task that uses [BusinessObject]
Which screens exercise [Capability]
Impact analysis if [Application] changes
Generate journey for [Process] + [Actor]

Key Decisions¶

1. The canonical unit is Task, not Screen¶

Screens are vendor-specific projections. Tasks are vendor-neutral canonical units. All catalog work targets Tasks first.

2. Experience Model is additive, not modifying¶

No existing catalog entries are modified by this ADR. The EXP series adds new concepts without breaking existing cross-references.

3. Actor ≠ User¶

An Actor is a human agent in a business process. It is not a UI user or a system user. Actor concepts are defined in EXP-001 and reference Role definitions from the governance layer, not from authentication systems.

4. Pilot catalog before full expansion¶

The first complete implementation will model BOPIS end-to-end using the new concepts. This validates the model before expanding to all 15 processes.

Not Decided¶

Consequences¶

Positive¶

• UC-BoK becomes a design tool, not just a description framework
• Enables cross-vendor operational benchmarking (same tasks, different screens)
• Enables impact analysis at the human experience level
• Enables automatic journey generation from process + actor + capability
• The BOPIS pilot will produce the first end-to-end human-to-system knowledge chain

Constraints¶

• EXP-series specs must be created in order: Actor → Task → Interaction → Screen → Journey → Projection
• Task cardinality rules will be governed by SPEC-016 (complements SPEC-015)
• The pilot (BOPIS) must be completed before RA-001/RA-002 are updated with the operational view
• Vendor-specific screen catalogues must be clearly labelled as non-canonical

Implementation Checklist¶

• [ ] specifications/016-experience-model/ — SPEC-016 conceptual model
• [ ] schemas/experience-model.schema.yaml — machine-readable schema
• [ ] catalogs/experience/actors.yaml — Actor + Role definitions
• [ ] catalogs/experience/tasks.yaml — pilot: BOPIS tasks
• [ ] catalogs/experience/interactions.yaml — pilot: BOPIS interactions
• [ ] catalogs/experience/journeys.yaml — pilot: BOPIS journey
• [ ] Update RA-001 and RA-002 with operational experience view
• [ ] Extend Knowledge Engine queries for EXP-series concepts

Design Principles¶

1. Tasks are canonical. Screens are projections.
2. Model the work, not the interface.
3. Actors perform Tasks. Applications render Screens.
4. A Journey is a Process seen from a human perspective.
5. Complexity at the Task level — simplicity at the Screen level.

ADR-016 — Operational Experience Model — UC-BoK Architecture Board