# Course cancellation blueprint

Adrian Sutherland · Version 1.0 · September 2026

© 2005–2026 Adrian Sutherland.

Refreshed for the September 2026 website update.

Licensed under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/). Keep the [edition note](https://architectureportal.org/downloads/blueprint/1.0/edition.md) with adaptations.

## Course cancellation blueprint

A course is cancelled. The learner needs an alternative they accept and a
clear answer about who will arrange it. This blueprint brings the architecture
of that service into one connected set of views.

The [worked example](https://architectureportal.org/worked-example) follows the decisions and their
consequences. Here the views show the resulting arrangements, their shared
rules and the decisions still needed. The service is fictional; its trial
and software implementation have not been carried out.

### Design states

| State | Arrangement | Scope |
|---|---|---|
| PROC-01 (Process-only proposal) | Shared register, named case owner and explicit acceptance of handovers | Proposed trial for provider-run courses |
| SOFT-01 (Later software option) | A case service with staff access, booking integration and recoverable transfers | Possible later software support |
| PART-01 (Partner extension) | An agreed partner service with its own booking and confirmation responsibilities | Later extension; responsibility and terms remain open |

These states describe different arrangements. Conceptual, Logical and Physical
describe how much detail a view supplies. Visioning, Transforming, Operating
and Governing describe the architectural work around them.

### The views

| View | Question |
|---|---|
| [Service overview](https://architectureportal.org/blueprint/service-overview) | Who keeps the learner's case moving? |
| [Work and responsibility](https://architectureportal.org/blueprint/work-responsibility) | How is agreement reached, ownership transferred and an exception handled? |
| [Information](https://architectureportal.org/blueprint/information) | What does the case mean, and which states and relationships are valid? |
| [Systems and rules](https://architectureportal.org/blueprint/systems) | Which components own decisions, records and exchanges? |
| [Accepted handover](https://architectureportal.org/blueprint/accepted-handover) | What happens when a transfer succeeds but its reply is lost? |
| [Security](https://architectureportal.org/blueprint/security) | Where are identity, permission and information use checked? |
| [Technology and operation](https://architectureportal.org/blueprint/technology-operation) | What must survive release, restart and restoration? |
| [Direction and measures](https://architectureportal.org/blueprint/direction-measures) | Who decides, what would it cost and how would results be judged? |
| [Change and review](https://architectureportal.org/blueprint/change-review) | How do the process areas revisit the design? |

The [object reference](https://architectureportal.org/blueprint/objects) defines identifiers, roles,
information and components used across the views. The
[records and downloads](https://architectureportal.org/blueprint/records) provide the completed blueprint
and an outline to adapt.

### ASAF coverage

A Simple Architectural Framework (ASAF) supplies the aspects below. One view
may address several aspects, and an open choice can be a useful part of the
architecture.

| Aspect | Treatment in this blueprint |
|---|---|
| Customer | [Learner choice, payer and representative authority](https://architectureportal.org/blueprint/work-responsibility#customers-and-channels) |
| Supplier | [Partner confirmation, failure and exit](https://architectureportal.org/blueprint/work-responsibility#partners) |
| Channel | [Messages, assisted contact and offline proposals](https://architectureportal.org/blueprint/work-responsibility#customers-and-channels) |
| Process | [Work, acceptance and escalation](https://architectureportal.org/blueprint/work-responsibility) |
| Structure | [Role responsibilities and delegated decisions](https://architectureportal.org/blueprint/work-responsibility#responsibilities) |
| Information | [Definitions, relationships, state and history](https://architectureportal.org/blueprint/information) |
| Security | [Access, risks, controls and incident response](https://architectureportal.org/blueprint/security) |
| Metrics | [Service results, method effort and recovery quality](https://architectureportal.org/blueprint/direction-measures#measures) |
| Systems | [Applications, integration, software and business rules](https://architectureportal.org/blueprint/systems) |
| Technology | [Runtime, release, persistence and recovery](https://architectureportal.org/blueprint/technology-operation) |
| Management | [Authority, dependencies and exceptions](https://architectureportal.org/blueprint/direction-measures#decisions) |
| Finance | [Comparable option costs and commitments](https://architectureportal.org/blueprint/direction-measures#costs) |
| Purpose | [Accepted resolution, learner agreement and continuous ownership](https://architectureportal.org/blueprint/service-overview) |

### Detail and open choices

The views provide Conceptual and Logical architecture. The
[implementation choices](https://architectureportal.org/blueprint/technology-operation#physical-choices)
record what a Physical description would need: named people, products,
environments, configuration and operating procedures. Those choices remain
open in this fictional service.

### Methodology configuration

Use the views that answer your team's questions and combine them with your
existing records. Retain the meaning, authority and source references when
renaming an object or moving it into another diagram. The
[configuration guidance](https://architectureportal.org/method/configuration) explains this mapping.

The [Systems reference components](https://architectureportal.org/systems/reference-components) offer a
wider catalogue of responsibilities. They can inform a design without becoming
mandatory components of this service.


## Service overview

### Reading the view

The case owner keeps the learner informed, records their agreement and follows
the case through to confirmed resolution. The booking and course teams provide
the alternatives and booking confirmation. The shared case record, I1 (Cancellation case record), holds the current owner,
agreement, next action, state and confirmation reference.

The arrows show exchanges and responsibilities. Their position does not set
the order of work. The [business example](https://architectureportal.org/business-architecture/worked-example)
describes that work and its intended outcome, O1 (Accepted resolution).

### Ownership and exceptions

Requirement **R1 (Continuous ownership)** preserves learner agreement and continuous ownership.
An offered handover leaves the existing assignment current until the receiving
person accepts and the transfer takes effect in the shared register. The duty
coordinator arranges cover; the service owner decides unresolved exceptions.
The [handover procedure](https://architectureportal.org/organisation-process/worked-example) supplies the detail.

This proposal covers provider-run courses. Partner courses, refunds and cases
with no acceptable alternative require escalation. Learner agreement and
booking confirmation are both needed to resolve the case.

### What remains open

The shared register's tool, named staff, response targets, cover arrangements
and reconciliation procedure need agreement before a real trial. V1 (Two-handover check) and OP-V1 (Handover checks)
specify the proposed service checks. Both are unrun.

### Methodology configuration

A team might call this a service context view or a responsibility map. Map the
roles and records to your own terms while retaining who accepts work and what
is recorded. See [Methodology configuration](https://architectureportal.org/method/configuration).

Continue to the [later software handover](https://architectureportal.org/blueprint/accepted-handover) or use
the [completed and blank records](https://architectureportal.org/blueprint/records).


### BP-V01 (Service overview)

The learner agrees a replacement with the case owner. Booking and course teams supply cancellation, alternatives and confirmation. The owner maintains I1 (Cancellation case record), the shared case record. The duty coordinator arranges cover; the service owner decides unresolved exceptions. Ownership continues until confirmed resolution or an explicitly accepted transfer.

[Diagram source](https://architectureportal.org/downloads/blueprint/1.0/service-overview.mmd) · [SVG](https://architectureportal.org/downloads/blueprint/1.0/service-overview.svg)

## Work and responsibility

### Responsibilities

PR1 (Resolution process) carries out the resolution work. RO1 (Case owner) maintains I1 (Cancellation case record) until resolution is
confirmed or an explicitly accepted transfer takes effect. OP-D1 (Accepted-transfer procedure) defines that
transfer: the receiver checks the current record, authority, access and
capacity; the shared record retains the effective acceptance and history.

| Role | Responsibility and decision |
|---|---|
| Learner | Chooses whether an alternative meets their need. |
| Booking and course teams | Identify alternatives and provide the booking confirmation. |
| Case owner | Maintains the record, contacts the learner and progresses resolution within the agreed scope. |
| Receiving case owner | Accepts the current version and next action or returns a query. |
| Duty coordinator | Arranges suitable cover; unresolved capacity or authority gaps reach the service owner. |
| Service owner | Agrees meaning, scope, service readiness and unresolved exceptions. |
| Data steward | Maintains definitions and coordinates recurring quality problems. |

The coordinator is a responsibility that could sit in an existing role.
Named staff, cover and response targets remain to be agreed. V1 (Two-handover check) and OP-V1 (Handover checks)
specify unrun checks of two handovers and the related organisational failures.

### Customers and channels

CU-D1 (Customer roles) distinguishes the learner, payer and representative. Paying for a course
does not establish the learner's agreement; a representative needs explicit
authority for the information and actions involved.

CH-D1 (Cross-channel journey) keeps the same case and meaning through a cancellation message and an
assisted call. A sent message is not agreement. CH-S1 (Pending and accepted actions) requires a later mobile
client to distinguish a locally saved proposal from accepted service state.
A reconnecting client must handle a changed case or withdrawn permission.
CU-F1 (Channel research) would test whether online and assisted routes allow the same choice;
that research has not been run.

### Partners

SU-D1 (Partner responsibilities) describes the later partner arrangement. Before PART-01 (Partner extension) can be
introduced, the provider and partner must agree who may offer, reserve,
confirm, change or cancel a place; what information may be shared; and who
resolves unknown or disputed outcomes. The internal case owner retains
responsibility for resolution.

L1 (Partner confirmation gap) is the hypothetical finding that exposes an unagreed partner-confirmation
responsibility. Partner courses and refunds remain escalations in PROC-01 (Process-only proposal).
SU-X1 (Partner exit exercise) would exercise exit with an open case, retained commitments and removal
of the previous partner's access. Its result is unrun.

### Connected records

The [Process example](https://architectureportal.org/organisation-process/worked-example) owns the handover
procedure. [Customer](https://architectureportal.org/customers/worked-example), [Channel](https://architectureportal.org/channels/worked-example)
and [Supplier](https://architectureportal.org/suppliers/worked-example) records retain the wider decisions.
Follow the [case lifecycle](https://architectureportal.org/blueprint/information) and the
[software acceptance contract](https://architectureportal.org/blueprint/accepted-handover) to see how these
responsibilities are preserved.


### BP-V03 (Work and responsibility)

The case owner opens a case and identifies alternatives. The learner can accept or reject an alternative. A matching confirmation resolves the case. An unavailable alternative or authority gap is escalated while ownership and next action are retained. Handover changes the assignment only on explicit acceptance.

[Diagram source](https://architectureportal.org/downloads/blueprint/1.0/work-responsibility.mmd) · [SVG](https://architectureportal.org/downloads/blueprint/1.0/work-responsibility.svg)

## Information

### Meaning and ownership

I1 (Cancellation case record) records one cancellation case and its cancelled booking. ID-DEF1 (Learner agreement definition) defines
learner agreement as acceptance of a specific alternative, including who
recorded it, when and the supporting interaction. An offer remains an offer
until that acceptance is recorded.

ID-D1 (Shared case register) proposes the shared case register for PROC-01 (Process-only proposal). The case service would
hold the same authoritative meaning in SOFT-01 (Later software option). Booking records and booking
confirmation retain their separate authority.

### Relationship rules

| Information | Rule |
|---|---|
| Cancelled booking and case | One case refers to one booking. At most one active case is allowed for a cancelled booking; earlier resolved history may remain. |
| Assignments | History can contain several assignments; exactly one is current while the case is active. |
| Agreements | Each agreement names one alternative; corrections preserve history and at most one agreement is current. |
| Confirmation | A resolution needs confirmation of the current agreement and resulting booking. |
| Acceptance receipt | In the software option, identifies the result of one operation; it does not establish the owner after subsequent changes. |

The relationship drawing allows historical records. Its cardinalities do not
replace the temporal rules for the current assignment and agreement.

### State changes

A case opens when cancellation is accepted for handling. Recorded agreement
moves it to awaiting confirmation; matching confirmation permits resolution.
An exception retains the owner, reason and next action while escalated. The
service owner's decision returns it to the appropriate active state.

A transfer changes the assignment while preserving the case's resolution
state. A correction can invalidate agreement or confirmation; retain its
reason and earlier version, then reopen at the appropriate state.

### Quality and retention

The service owner approves meaning and retention choices; the steward
maintains definitions and helps resolve recurring errors. Access, correction,
retirement and treatment of copies need explicit decisions before real learner
information is used. The [data-governance guide](https://architectureportal.org/information-data/governance) and
[completed governance record](https://architectureportal.org/downloads/information-data/1.0/id-t05-governance-example.md)
follow a correction into a derived report and its copies. Retention periods
and real-data approval remain open.

ID-V1 (Case meaning checks) checks duplicate cancellation, conflicting agreement and confirmation,
unaccepted ownership and corrected history. The checks are unrun.
See the [information records](https://architectureportal.org/assets/information-data) and
[original case example](https://architectureportal.org/information-data/worked-example).


### BP-V04 (Information relationships)

A cancelled booking may have historical cancellation cases, with at most one active case. Each active case has one current owner assignment. Agreement and confirmation histories retain corrections. A resolved case requires confirmation matching its current agreement.

[Diagram source](https://architectureportal.org/downloads/blueprint/1.0/information.mmd) · [SVG](https://architectureportal.org/downloads/blueprint/1.0/information.svg)

### BP-V05 (Case lifecycle)

Opening assigns an owner. Learner agreement permits awaiting confirmation. Matching confirmation permits resolution. Exceptions retain responsibility while escalated; the appropriate active state resumes after a decision. Corrections can invalidate an agreement or confirmation. Ownership transfer preserves the case state.

[Diagram source](https://architectureportal.org/downloads/blueprint/1.0/case-lifecycle.mmd) · [SVG](https://architectureportal.org/downloads/blueprint/1.0/case-lifecycle.svg)

## Systems and rules

### Service responsibilities

SI-D1 (Case-service option) is the later case-service option. The staff client proposes actions;
the case service owns accepted case state. The booking service owns bookings.
Notification delivery reports accepted changes, and a reporting consumer
maintains a derived view with version-gap checks and reconciliation.

Those responsibilities need not be separate applications. SW-D1 (Case-service components) describes
components inside the case service; packaging and language remain open.

| Component | Responsibility |
|---|---|
| Input adapter | Decode the request and obtain authenticated caller context. |
| Transfer handler | Check authority, distinguish a retained operation from a new one, coordinate rule evaluation and save. |
| Transfer rule | Return a plan or rejection from current facts, with no external effects. |
| Transaction store | Apply the full change only if the expected version is still current. |
| Notification relay | Send committed pending work and track progress through retries. |

### Rule and contract

SW-R1 (Transfer rule) checks the pending offer, named receiver, current version, agreement
reference and next action for a new operation. Missing required facts lead
to a rejection with a reason. The handler and store preserve SI-C01 (Transfer acceptance contract): old
assignment, new assignment, accepted offer, result and pending notification
change together, or none do.

The [accepted handover view](https://architectureportal.org/blueprint/accepted-handover) follows X7 (Acceptance operation) after a
lost reply. A retained identical request takes the repeat path; a new request
at a stale version is rejected. Two new requests against the same version
cannot both take effect. Notifications can repeat, and a reporting consumer
must not let an older event overwrite a newer view.

### Optional summary

SW-C1 (Summary workflow contract) defines an optional summary workflow: check access to versioned source
facts, generate a proposal, check its references and facts, then have a person
review it. Prompt, model and context versions are retained for investigation.
A syntactically valid citation to the wrong alternative still fails the check.

The workflow cannot accept learner agreement or transfer ownership. A changed
case requires context and summary to be rechecked. A timeout in generation
must not create an acceptance request; ordinary review and handover remain
available when their own dependencies are healthy.

### Checks and alternatives

SI-V1 (Interface checks) and SW-V1 (Component checks) specify interface and component checks, including concurrency,
partial-write failure, restart, withdrawn access and hostile summary input.
They remain unrun. A simpler deployment can keep the logical responsibilities
within one application; separate deployment requires a reason and compatible
contracts.

The [Systems example](https://architectureportal.org/systems/worked-example) retains the complete contract.
The [reference catalogue](https://architectureportal.org/systems/reference-components) explains the wider
roles that another solution might need.


### BP-V06 (Systems and rules)

The staff client sends a request through the input adapter. The transfer handler checks authority and existing operation results. New operations use the pure transfer rule and a conditional transaction store. The notification relay sends committed pending work. Booking remains separately authoritative. Optional summary work has no authority to change ownership.

[Diagram source](https://architectureportal.org/downloads/blueprint/1.0/systems.mmd) · [SVG](https://architectureportal.org/downloads/blueprint/1.0/systems.svg)

## Accepted handover

### Reading the sequence

The receiving person has checked the learner's agreement, next action, access
and capacity. Their staff application (the client) sends a request identified as **X7 (Acceptance operation)** for
case **C42 (Example cancellation case)**, offer **H7 (Example transfer offer)** and expected version **12**. X7 identifies this
operation for this caller and operation type. The case service authenticates the caller and checks their authority.

For a new operation it checks the pending offer, intended receiver and current
case version. One atomic change closes the old assignment, records the new one,
marks the offer accepted and retains the result as an acceptance receipt and records a pending notification.
All changes take effect together, or none do. The accepted version is **13**.
The case's resolution state stays unchanged.

### When the reply is lost

The client retains X7 and shows an unknown outcome. A repeat with the same
identity and inputs returns the stored result within the agreed retention
period. The service checks current access and recognises that existing
operation before applying the version checks for a new operation.

Notification follows the commit independently. The drawing places it below
the retry for readability; it could occur earlier. Delivery can repeat or fail.
Booking confirmation remains a separate responsibility.

### Other outcomes

| Situation | Required treatment in SI-C01 (Transfer acceptance contract) |
|---|---|
| Caller has lost access | Refuse access to the retained result, including through a retry. |
| X7 has different inputs | Reject conflicting reuse; preserve the original result. |
| A new operation uses stale version 12 | Reject the new request because version 12 is stale. Read the current case before proposing another acceptance. Two new requests based on version 12 cannot both apply. |
| Receipt is missing or expired | Keep the outcome unknown and reconcile the history. Do not silently create a new operation identity. |
| An old receipt follows a later transfer | Show its historical result separately from the current owner. |
| Client is offline | Keep the proposed action pending until the service accepts it. |

The diagram selects one path through [SI-C01](https://architectureportal.org/systems/worked-example#the-acceptance-contract).
The contract and these exception rules complete its meaning. Storage,
transport, retention periods, retry limits and support response targets remain
open. SI-V1 (Interface checks)'s [implementation checks](https://architectureportal.org/systems/worked-example#proposed-checks)
are unrun.

### Methodology configuration

This view could sit within an interface specification or a service design.
Keep the business requirement, interaction contract and checks linked when
mapping it into your records. See [Methodology configuration](https://architectureportal.org/method/configuration).

Return to the [service overview](https://architectureportal.org/blueprint/service-overview) or inspect the
[blueprint records](https://architectureportal.org/blueprint/records).


### BP-V02 (Accepted handover)

A receiving member of staff requests acceptance through the staff client. The case service checks authority and current state, then commits assignment, offer, receipt and pending notification together. The response is lost. A repeat uses the same operation and inputs. Current permission is checked before the retained result is returned, without another assignment. Notifications follow the commit independently. Booking confirmation is separate.

[Diagram source](https://architectureportal.org/downloads/blueprint/1.0/accepted-handover.mmd) · [SVG](https://architectureportal.org/downloads/blueprint/1.0/accepted-handover.svg)

## Security

### Access and authority

SEC-A1 (Service authorisation) places the permission decision at the service where information is read
or a change takes effect. A request includes a claimed purpose and case
reference; trusted identity and current policy establish what the caller may
do. A network location, device or earlier successful call does not supply
continuing authority. This applies the [Zero Trust guidance](https://architectureportal.org/security/zero-trust)
to the service's actual reads, transfers and receipt lookups.

A new acceptance checks the intended receiver and current case facts. A retry
checks current access before returning the retained receipt. If permission
has been withdrawn, the accepted business event stays recorded while that
caller loses access to its protected result.

### Risks and controls

| Risk | Control in the proposal | Responsible role |
|---|---|---|
| SEC-R1 (Excess disclosure) | Limit disclosure to the case and fields required; check reads and exports. | Information owner |
| SEC-R2 (Unauthorised acceptance) | Check identity, current policy, intended receiver and version when accepting work. | Service owner |
| SEC-R3 (Unsafe summary use) | Restrict summary source facts, retained content and tools; check generated text against sources. | Application owner |
| SEC-R4 (Altered records or traces) | Protect credentials, records and audit information; separate administration and prepare recovery. | Platform and service owners |

Likelihood, consequence, remaining exposure and acceptance are open decisions.
The wider partner option needs separately agreed disclosure and supplier
controls; it is not part of the first process-only trial.

### Operation and assurance

SEC-O1 (Security operation record) links actor, action, case, policy decision and result so an authorised
operator can investigate. Logs require access and retention controls and
should exclude credentials and unnecessary learner content.

An incident owner coordinates containment and business communication. Recovery
includes trustworthy configuration, credential replacement where needed and
reconciliation of accepted work. Test denied access, revoked permissions,
unavailable identity services, unwanted tool actions and damaged records.
The security checks are unrun. The [security example](https://architectureportal.org/security/worked-example)
and [recovery view](https://architectureportal.org/blueprint/technology-operation) retain the connected details.


### BP-V07 (Access and authority)

The caller uses a staff client. The case service checks trusted identity, current policy and requested resource before performing the permitted operation. Protected case and receipt records remain behind this decision. A restricted summary workflow reads permitted context and returns a proposal for human review. Security records support authorised investigation.

[Diagram source](https://architectureportal.org/downloads/blueprint/1.0/security.mmd) · [SVG](https://architectureportal.org/downloads/blueprint/1.0/security.svg)

## Technology and operation

### Runtime arrangement

TD-D1 (Runtime arrangement) evaluates one application release and a durable transactional store for
SOFT-01 (Later software option). The notification relay can run as a worker from that release.
Scheduling, suppliers, products and instance count remain open. Only the
case service accepts ownership changes; summary work receives narrower access.

Keep deployment permissions separate from normal service permissions. Identify
support for the application, store, identity, network and supplier dependencies.
Measure realistic concurrent acceptance, reconnecting clients and pending
notifications before selecting capacity and cost limits.

### Restart and restore

| Event | Required treatment |
|---|---|
| Application restart after acceptance | Preserve case, receipt and pending notification together. An authorised identical repeat returns the result without another transfer. |
| Restore a copy from before acceptance | Accepted work may be missing even if the restore succeeds. Pause affected actions and notifications, prevent old writers, establish the missing interval and reconcile with the people doing the work. |
| Resume after reconciliation | The service owner accepts the reconciled position and the remaining risks before writes resume. |

TD-R1 (Recovery procedure) and SO-I1 (Incident and restoration) connect the technical recovery procedure to the business
incident. An older receipt is historical; the current owner must be checked
separately. Recovery time, allowable loss, copy location, encryption, retention
and restoration checks remain open.

### Release and service acceptance

TD-C1 (Release and compatibility) records the package, configuration, schema and client compatibility.
Reverting an application does not undo accepted transfers. Choose rollback,
forward repair or paused reconciliation according to the actual failure.

SO-R1 (Readiness record) gathers migration, access, staffing, observation, supplier and recovery
readiness. SO-A1 (Service acceptance) records the service owner's acceptance decision, including
funding and residual risks. Begin with agreed limited exposure and stop
widening when checks fail. Thresholds and decision owners need agreement.

TD-V1 (Environment checks) checks restart, concurrent callers, repeated notification, identity
failure, older restoration, incompatible schema and representative load.
All results remain unrun.

### Physical choices

| Choice | Information needed before implementation |
|---|---|
| People and procedures | Named owners, cover, escalation contacts, training and effective working instructions |
| Runtime and location | Selected hosting, language, runtime version, deployment units, instance counts and network paths |
| Persistence | Store product and configuration demonstrating atomic acceptance and restart durability |
| Access | Identities, policies, credentials, rotation and emergency-access arrangements |
| Release | Tested package, configuration, data migration, client compatibility and recovery route |
| Recovery | Measured restore procedure, protected copies, accepted loss and business reconciliation |

These are open Physical decisions, rather than an as-built specification.
The [technology](https://architectureportal.org/technology-deployment/worked-example) and
[operations](https://architectureportal.org/service-operations/worked-example) records provide the source detail.


### BP-V08 (Runtime and recovery)

The staff client calls the application. Its case handler uses a durable transactional store; the notification worker resumes committed work. Identity and booking have separate dependencies. Recovery copies can restore older records, so accepted business work may need reconciliation before writes resume. Runtime products, instance counts and service objectives remain open.

[Diagram source](https://architectureportal.org/downloads/blueprint/1.0/runtime.mmd) · [SVG](https://architectureportal.org/downloads/blueprint/1.0/runtime.svg)

## Direction and measures

### Decisions

MG-D1 (Shared direction) connects the provider's direction to the cancellation trial and possible
partner service. MG-R1 (Service roadmap) records the sequence and dependencies. Local working
instructions can change within the agreed rule; cross-team responsibility
changes go to the business-area owner, and commitments require the funding
owner. MG-E1 (Temporary exception) would retain a temporary exception's owner, scope, checks and
review trigger.

The process trial is the proposed first step, not an approved expenditure or
an observed success. Software support and the partner extension each need
their own acceptance conditions. L1 (Partner confirmation gap) reopens the unagreed partner-confirmation
responsibility while retaining the existing purpose and learner-agreement rule.

### Costs

FN-D1 (Option cost comparison) compares invented estimates over twelve months, in pounds sterling.
Each total is introduction plus twelve months of operation plus transition
overlap. Operation includes the assumed staff, supplier and technology costs.

| Option | Introduction | Monthly operation | Overlap | Twelve-month total |
|---|---|---|---|---|
| Continue current practice | £0 | £1,600 | £0 | £19,200 |
| Process and ownership trial | £2,400 | £1,500 | £0 | £20,400 |
| Later case-service option | £9,000 | £1,100 | £1,500 | £23,700 |

If monthly operation of the case service rises by £250, its total becomes
£26,700. Lower monthly cost does not make it the cheapest option in this
period. Benefits are unmeasured; refunds, lost bookings and additional partner
charges need estimates before a real decision. FN-C1 (Funding commitment) connects each proposed
commitment to its funding owner and architecture decision. The preferred
option remains open.

### Measures

MT-M1 (Resolution measures) keeps different questions separate:

| Question | Observation and use |
|---|---|
| Does the service achieve its purpose? | Time from recorded cancellation to confirmed accepted resolution; include waiting and missing events. |
| Is ownership reliable? | Intervals without an accepted owner, unresolved transfers and causes. |
| Is work correct and supportable? | Incorrect bookings, repeated work, correction effort and support effort. |
| Is the architecture method effective? | Elapsed time to an accepted design decision, including active work, waiting and rework. |
| Can the design be changed? | Effort to alter an agreement rule, find its meaning, update checks and prepare support. |
| Does recovery restore the business position? | MT-Q1 (Recovery quality) examines accepted work lost, uncertainty and reconciliation alongside technical restoration time. |

Baselines, targets, observation periods and results remain open. Useful
longevity requires following operation, change and eventual retirement over
time; a long-lived service alone would not establish quality.

See the [management](https://architectureportal.org/management/worked-example), [finance](https://architectureportal.org/finance/worked-example)
and [metrics](https://architectureportal.org/metrics/worked-example) records for the linked assumptions.


## Change and review

### Process areas

The ASAF process areas continue around each design state. They overlap and
return to earlier decisions when an observation changes an assumption.

| Area | Work in this example | What may be reopened |
|---|---|---|
| Visioning | Establish accepted resolution, ownership, scope and options. | Purpose, agreement rule or choice of service scope |
| Transforming | Prepare the process trial; later migrate records and introduce software if agreed. | Responsibilities, contracts, rollout and acceptance checks |
| Operating | Observe handovers, unresolved cases, costs, access events and recovery. | Procedures, capacity, support, supplier behaviour or design assumptions |
| Governing | Assign decision authority, review exceptions and accept service changes. | Shared policies, funding, risk acceptance and standards |

These areas are not the process-only and software increments. Either increment
requires appropriate work in all four areas, at the needed level of detail.

### A change to follow

L1 (Partner confirmation gap) identifies a suitable partner alternative without an agreed confirmation
owner. Record the finding, then follow its consequences through SU-D1 (Partner responsibilities),
information references, permissions, support, cost and the check for partner
handover. The service owner and business-area owner resolve the responsibility
before expanding scope. The internal case owner and learner-agreement rule
continue unless a separate decision changes them.

### Review the affected records

1. Identify the changed assumption or rule, the affected design state and who
   can decide it.
2. Follow the [object references](https://architectureportal.org/blueprint/objects) to the views, contract,
   procedure and checks that depend on it.
3. Update those records together; retain why the previous decision changed.
4. Run the relevant checks and record actual results separately from expected
   behaviour.
5. Accept the new arrangement and prepare the people who operate it. Feed
   observations back to the appropriate process area.

The [records](https://architectureportal.org/blueprint/records) keep source and view identities together.
Their edition identifies the website material; an application release, case
version or operation identity has its own meaning and must not be substituted
for that edition.

### Methodology configuration

Map these activities into your actual reviews, iterations and operating
routines. One meeting may cover several process areas. A changed rule may
require several teams to revisit a small set of records without recreating
the whole architecture.

#### Dials

Choose review cadence, change size, coordination and decision authority to
match the work. A small process trial can use short feedback cycles; a shared
contract change needs coordinated acceptance. More automation can shorten
production of artefacts, while checked results and accepted decisions still
determine readiness. See [Methodology configuration](https://architectureportal.org/method/configuration).


## Object reference

| Object | Meaning | Source |
|---|---|---|
| O1 (Accepted resolution) | The learner receives a timely resolution they accept, with one named owner until it is confirmed. | [Read in context](https://architectureportal.org/business-architecture/worked-example) |
| P1 (Learner agreement) | The learner must agree to the chosen alternative. | [Read in context](https://architectureportal.org/business-architecture/worked-example) |
| R1 (Continuous ownership) | Preserve learner agreement and continuous case ownership through each handover. | [Read in context](https://architectureportal.org/business-architecture/worked-example) |
| C1 (Resolve a cancelled booking) | The ability to reach a confirmed resolution after a course cancellation. | [Read in context](https://architectureportal.org/business-architecture/worked-example) |
| VS1 (Cancellation resolution) | Understand options, agree a resolution and receive confirmation. | [Read in context](https://architectureportal.org/business-architecture/worked-example) |
| PR1 (Resolution process) | Open the case, assign an owner, contact the learner, agree an alternative and confirm. | [Read in context](https://architectureportal.org/business-architecture/worked-example) |
| RO1 (Case owner) | The named person responsible for the case until confirmed resolution or effective accepted transfer. | [Read in context](https://architectureportal.org/business-architecture/worked-example) |
| I1 (Cancellation case record) | The case, booking reference, current owner, options, agreement, state, next action and confirmation reference. | [Read in context](https://architectureportal.org/business-architecture/worked-example) |
| A1 (Responsibility and information) | The case owner maintains the case record through the resolution process. | [Read in context](https://architectureportal.org/business-architecture/worked-example) |
| D1 (Process-only trial) | Propose a shared register and accepted handovers for provider-run courses. | [Read in context](https://architectureportal.org/business-architecture/worked-example) |
| V1 (Two-handover check) | Follow a cancellation through two handovers and check owner, agreement and next action; unrun. | [Read in context](https://architectureportal.org/business-architecture/worked-example) |
| L1 (Partner confirmation gap) | A hypothetical partner alternative has no agreed confirmation owner; it triggers a scope decision. | [Read in context](https://architectureportal.org/business-architecture/worked-example) |
| ID-DEF1 (Learner agreement definition) | Acceptance of a specific alternative with actor, time and supporting interaction. | [Read in context](https://architectureportal.org/information-data/worked-example) |
| ID-D1 (Shared case register) | Use a case register with linked assignment, agreement and correction history. | [Read in context](https://architectureportal.org/information-data/worked-example) |
| ID-V1 (Case meaning checks) | Check duplicate cases, agreement/confirmation consistency, ownership and corrections; unrun. | [Read in context](https://architectureportal.org/information-data/worked-example) |
| OP-D1 (Accepted-transfer procedure) | Offer current context; receiver checks access, capacity and authority; record acceptance and effective transfer. | [Read in context](https://architectureportal.org/organisation-process/worked-example) |
| OP-V1 (Handover checks) | Check waiting, absent owners, access, changed records and conflicting offers; unrun. | [Read in context](https://architectureportal.org/organisation-process/worked-example) |
| SI-D1 (Case-service option) | Possible later software increment replacing the shared register after migration and acceptance. | [Read in context](https://architectureportal.org/systems/worked-example) |
| SI-C01 (Transfer acceptance contract) | Authority, version, atomic acceptance, retained result, repeat and failure rules for an offered transfer. | [Read in context](https://architectureportal.org/systems/worked-example) |
| SI-V1 (Interface checks) | Exercise lost responses, conflicts, repeats, restart, notifications and unknown booking outcomes; unrun. | [Read in context](https://architectureportal.org/systems/worked-example) |
| SW-D1 (Case-service components) | Separate input, transfer handling, pure rules, conditional storage and notification work. | [Read in context](https://architectureportal.org/systems/worked-example) |
| SW-R1 (Transfer rule) | Validate current facts and return a transfer plan or rejection without external effects. | [Read in context](https://architectureportal.org/systems/worked-example) |
| SW-C1 (Summary workflow contract) | Prepare permitted context, generate and check a proposed summary, then obtain human review. | [Read in context](https://architectureportal.org/systems/worked-example) |
| SW-V1 (Component checks) | Check rules, atomic writes, concurrency, recovery and summary restrictions; unrun. | [Read in context](https://architectureportal.org/systems/worked-example) |
| C42 (Example cancellation case) | An illustrative instance of the cancellation case, not a class of case. | [Read in context](https://architectureportal.org/systems/worked-example) |
| H7 (Example transfer offer) | An offer naming the intended receiver of case C42 at expected version 12. | [Read in context](https://architectureportal.org/systems/worked-example) |
| X7 (Acceptance operation) | A unique acceptance request identity scoped to the caller and operation type; retained for lookup or an identical retry. | [Read in context](https://architectureportal.org/systems/worked-example) |
| SEC-R1 (Excess disclosure) | Disclosure of unrelated or unnecessary learner information. | [Read in context](https://architectureportal.org/security/worked-example) |
| SEC-R2 (Unauthorised acceptance) | An actor without current authority accepts ownership. | [Read in context](https://architectureportal.org/security/worked-example) |
| SEC-R3 (Unsafe summary use) | Summary content discloses information or induces an unauthorised action. | [Read in context](https://architectureportal.org/security/worked-example) |
| SEC-R4 (Altered records or traces) | An intruder changes records or removes information needed for investigation. | [Read in context](https://architectureportal.org/security/worked-example) |
| SEC-A1 (Service authorisation) | Check trusted identity and current policy where a read or action takes effect, including receipt lookup. | [Read in context](https://architectureportal.org/security/worked-example) |
| SEC-O1 (Security operation record) | Link actor, action, case, policy decision and result for protected investigation and recovery. | [Read in context](https://architectureportal.org/security/worked-example) |
| TD-D1 (Runtime arrangement) | Evaluate one application release and a durable transactional store; products and instance counts remain open. | [Read in context](https://architectureportal.org/technology-deployment/worked-example) |
| TD-R1 (Recovery procedure) | Distinguish restart from restoring older data; reconcile lost accepted work before resumption. | [Read in context](https://architectureportal.org/technology-deployment/worked-example) |
| TD-C1 (Release and compatibility) | Control package, configuration, schema, clients and recovery behaviour through a release. | [Read in context](https://architectureportal.org/technology-deployment/worked-example) |
| TD-V1 (Environment checks) | Test commit, restart, restoration, access dependency and representative load in the chosen configuration; unrun. | [Read in context](https://architectureportal.org/technology-deployment/worked-example) |
| MG-D1 (Shared direction) | Link learner resolution to the cancellation trial and a possible partner service. | [Read in context](https://architectureportal.org/management/worked-example) |
| MG-R1 (Service roadmap) | Sequence changes and prerequisites, including partner acceptance responsibilities. | [Read in context](https://architectureportal.org/management/worked-example) |
| MG-E1 (Temporary exception) | Identify the owner, scope, checks and review trigger for a temporary arrangement. | [Read in context](https://architectureportal.org/management/worked-example) |
| FN-D1 (Option cost comparison) | Compare invented twelve-month costs on a stated common basis; preference remains open. | [Read in context](https://architectureportal.org/finance/worked-example) |
| FN-C1 (Funding commitment) | Link expenditure and its authorisation to a funding owner and architecture decision. | [Read in context](https://architectureportal.org/finance/worked-example) |
| MT-M1 (Resolution measures) | Measure resolution time, ownership gaps, correction effort and architecture decision time separately. | [Read in context](https://architectureportal.org/metrics/worked-example) |
| MT-Q1 (Recovery quality) | After restore, establish the accepted work lost and reconciled as well as technical recovery time. | [Read in context](https://architectureportal.org/metrics/worked-example) |
| CU-D1 (Customer roles) | Distinguish learner choice, payer authority and representative permissions. | [Read in context](https://architectureportal.org/customers/worked-example) |
| CU-F1 (Channel research) | Check whether assisted and online routes preserve the same learner choice; unrun. | [Read in context](https://architectureportal.org/customers/worked-example) |
| SU-D1 (Partner responsibilities) | Agree authority, confirmation, information, failure and exit before adding a partner service. | [Read in context](https://architectureportal.org/suppliers/worked-example) |
| SU-X1 (Partner exit exercise) | Transfer an open case and remove former access without losing necessary history; unrun. | [Read in context](https://architectureportal.org/suppliers/worked-example) |
| CH-D1 (Cross-channel journey) | Retain the same case and meaning through messages and assisted calls. | [Read in context](https://architectureportal.org/channels/worked-example) |
| CH-S1 (Pending and accepted actions) | A locally saved or offline proposal becomes accepted only after authoritative service acceptance. | [Read in context](https://architectureportal.org/channels/worked-example) |
| SO-R1 (Readiness record) | Gather migration, staffing, observation and recovery checks before use. | [Read in context](https://architectureportal.org/service-operations/worked-example) |
| SO-A1 (Service acceptance) | Service-owner decision based on checks, risks, funding and fallback arrangements. | [Read in context](https://architectureportal.org/service-operations/worked-example) |
| SO-I1 (Incident and restoration) | Pause affected work, reconcile accepted actions, and obtain service-owner agreement before resuming. | [Read in context](https://architectureportal.org/service-operations/worked-example) |
| PROC-01 (Process-only proposal) | The provider-run course trial using a shared register and an accepted-transfer procedure. | [Read in context](https://architectureportal.org/blueprint) |
| SOFT-01 (Later software option) | The unimplemented case-service arrangement preserving the process and information rules. | [Read in context](https://architectureportal.org/blueprint) |
| PART-01 (Partner extension) | A later scope option requiring agreement on supplier responsibilities and confirmation. | [Read in context](https://architectureportal.org/blueprint) |
| ROLE-LEARNER (Learner) | Chooses whether an alternative meets their need. | [Read in context](https://architectureportal.org/customers/worked-example) |
| ROLE-TEAMS (Booking and course teams) | Record cancellation, identify alternatives and provide booking confirmation. | [Read in context](https://architectureportal.org/business-architecture/worked-example) |
| ROLE-COORD (Duty coordinator) | Arranges suitable cover and escalates unresolved gaps. | [Read in context](https://architectureportal.org/organisation-process/worked-example) |
| ROLE-SERVICE (Service owner) | Approves service meaning, readiness, exceptions and changes in scope. | [Read in context](https://architectureportal.org/organisation-process/worked-example) |
| ROLE-STEWARD (Data steward) | Maintains shared definitions and coordinates recurring quality issues. | [Read in context](https://architectureportal.org/organisation-process/worked-example) |
| ROLE-FUNDING (Funding owner) | Authorises expenditure and commitments. | [Read in context](https://architectureportal.org/management/worked-example) |
| ROLE-PARTNER (Course partner) | Would accept agreed booking and confirmation responsibilities. | [Read in context](https://architectureportal.org/suppliers/worked-example) |
| ROLE-RECEIVER (Receiving case owner) | Checks current information, authority, access and capacity before accepting a transfer. | [Read in context](https://architectureportal.org/organisation-process/worked-example) |
| SYS-CLIENT (Staff client) | Presents case state and sends proposals; offline saving does not transfer ownership. | [Read in context](https://architectureportal.org/systems/worked-example) |
| SYS-CASE (Case service) | Owns authoritative case information and accepts permitted case changes. | [Read in context](https://architectureportal.org/systems/worked-example) |
| SYS-BOOKING (Booking service) | Owns bookings and booking confirmation independently of case transfers. | [Read in context](https://architectureportal.org/systems/worked-example) |
| SYS-IDENTITY (Identity service) | Provides trusted identity information; service policy determines authority. | [Read in context](https://architectureportal.org/technology-deployment/worked-example) |
| SYS-NOTIFY (Notification delivery) | Delivers committed notifications and exposes failures; delivery may repeat. | [Read in context](https://architectureportal.org/systems/worked-example) |
| SYS-REPORT (Reporting consumer) | Maintains a derived view, detects version gaps and reconciles with the authoritative case. | [Read in context](https://architectureportal.org/systems/worked-example) |
| SYS-SUMMARY (Optional summary workflow) | Returns a source-linked proposal for human review; cannot accept agreement or ownership. | [Read in context](https://architectureportal.org/systems/worked-example) |
| CMP-INPUT (Input adapter) | Decodes requests and obtains authenticated context. | [Read in context](https://architectureportal.org/systems/worked-example) |
| CMP-HANDLER (Transfer handler) | Coordinates authority, retained-result lookup, rule evaluation and conditional save. | [Read in context](https://architectureportal.org/systems/worked-example) |
| CMP-RULE (Transfer rule module) | Returns a plan or rejection based on current facts; causes no external effects. | [Read in context](https://architectureportal.org/systems/worked-example) |
| CMP-STORE (Transaction store) | Commits all acceptance records together only against the expected version. | [Read in context](https://architectureportal.org/systems/worked-example) |
| CMP-RELAY (Notification relay) | Sends committed pending work and records delivery progress. | [Read in context](https://architectureportal.org/systems/worked-example) |
| DATA-BOOKING (Cancelled booking) | The learner and cancelled course occurrence that a case concerns. | [Read in context](https://architectureportal.org/information-data/worked-example) |
| DATA-ASSIGN (Owner assignment) | One case assignment with its effective period; only one is current. | [Read in context](https://architectureportal.org/information-data/worked-example) |
| DATA-AGREEMENT (Learner agreement record) | One accepted alternative, actor, time and source reference; at most one current agreement. | [Read in context](https://architectureportal.org/information-data/worked-example) |
| DATA-CONFIRM (Booking confirmation) | Confirmation of the current agreement and resulting booking. | [Read in context](https://architectureportal.org/information-data/worked-example) |
| DATA-RECEIPT (Acceptance receipt) | The retained outcome of one operation; historical and distinct from the current owner. | [Read in context](https://architectureportal.org/systems/worked-example) |
| DATA-PENDING (Pending notification) | Work to deliver recorded atomically with the accepted transfer. | [Read in context](https://architectureportal.org/systems/worked-example) |
| TECH-APP (Application release) | The evaluated packaging of the case-service components and notification worker. | [Read in context](https://architectureportal.org/technology-deployment/worked-example) |
| TECH-STORE (Durable transactional store) | Preserves accepted state, receipt and pending work across restart. | [Read in context](https://architectureportal.org/technology-deployment/worked-example) |
| TECH-COPY (Recovery copy) | A mutually consistent recovery set whose retention and acceptable loss need agreement. | [Read in context](https://architectureportal.org/technology-deployment/worked-example) |
| BP-V01 (Service overview) | The learner agrees a replacement with the case owner. Booking and course teams supply cancellation, alternatives and confirmation. The owner maintains I1 (Cancellation case record), the shared case record. The duty coordinator arranges cover; the service owner decides unresolved exceptions. Ownership continues until confirmed resolution or an explicitly accepted transfer. | [Read in context](https://architectureportal.org/blueprint/service-overview) |
| BP-V02 (Accepted handover) | A receiving member of staff requests acceptance through the staff client. The case service checks authority and current state, then commits assignment, offer, receipt and pending notification together. The response is lost. A repeat uses the same operation and inputs. Current permission is checked before the retained result is returned, without another assignment. Notifications follow the commit independently. Booking confirmation is separate. | [Read in context](https://architectureportal.org/blueprint/accepted-handover) |
| BP-V03 (Work and responsibility) | The case owner opens a case and identifies alternatives. The learner can accept or reject an alternative. A matching confirmation resolves the case. An unavailable alternative or authority gap is escalated while ownership and next action are retained. Handover changes the assignment only on explicit acceptance. | [Read in context](https://architectureportal.org/blueprint/work-responsibility) |
| BP-V04 (Information relationships) | A cancelled booking may have historical cancellation cases, with at most one active case. Each active case has one current owner assignment. Agreement and confirmation histories retain corrections. A resolved case requires confirmation matching its current agreement. | [Read in context](https://architectureportal.org/blueprint/information) |
| BP-V05 (Case lifecycle) | Opening assigns an owner. Learner agreement permits awaiting confirmation. Matching confirmation permits resolution. Exceptions retain responsibility while escalated; the appropriate active state resumes after a decision. Corrections can invalidate an agreement or confirmation. Ownership transfer preserves the case state. | [Read in context](https://architectureportal.org/blueprint/information) |
| BP-V06 (Systems and rules) | The staff client sends a request through the input adapter. The transfer handler checks authority and existing operation results. New operations use the pure transfer rule and a conditional transaction store. The notification relay sends committed pending work. Booking remains separately authoritative. Optional summary work has no authority to change ownership. | [Read in context](https://architectureportal.org/blueprint/systems) |
| BP-V07 (Access and authority) | The caller uses a staff client. The case service checks trusted identity, current policy and requested resource before performing the permitted operation. Protected case and receipt records remain behind this decision. A restricted summary workflow reads permitted context and returns a proposal for human review. Security records support authorised investigation. | [Read in context](https://architectureportal.org/blueprint/security) |
| BP-V08 (Runtime and recovery) | The staff client calls the application. Its case handler uses a durable transactional store; the notification worker resumes committed work. Identity and booking have separate dependencies. Recovery copies can restore older records, so accepted business work may need reconciliation before writes resume. Runtime products, instance counts and service objectives remain open. | [Read in context](https://architectureportal.org/blueprint/technology-operation) |
| BP-R01 (Blueprint record set) | Cover, view records, linked objects, decisions and reusable outline. | [Read in context](https://architectureportal.org/blueprint/records) |