Architecture Portal

Accepted handover

A later software option preserves the ownership rule.

Adrian Sutherland · Version 1.0 · · © 2005–2026

BP-V02 (Accepted handover) · Version 1.0 · September 2026

Accepted handover

An accepted transfer with a lost reply.

Design state
SOFT-01 (Later software option)
Level
Logical
Design
Proposed; unimplemented
Scope
Accepting an offered internal case transfer
ASAF aspects
Process, Structure, Information, Security, Systems

On a small screen, scroll the diagram sideways or read the text description below.

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.
BP-V02 (Accepted handover) · SI-C01 (Transfer acceptance contract), later software option. The design is unimplemented and SI-V1 (Interface checks) remains unrun.

Key

  • Read downwards. Columns identify participants; solid arrows show requests or actions.
  • Dashed arrows show results. A crossed arrow marks a lost response. Notes state conditions.

Linked records

Text description

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.

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. 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 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.

Return to the service overview or inspect the blueprint records.

About this edition

Refreshed for the September 2026 website update. This edition develops the earlier Architecture Portal and ASAF material; the fictional worked example was added in 2026.

Scope, limitations and next checks

Status and accountability

Read this page with its boundaries visible

Status

In development

Last reviewed

Intended users

  • Architects reviewing and adapting a blueprint

Non-goals

  • A prescribed product stack or a claim of measured service outcomes

Limitations

  • Fictional proposed architecture; service checks remain unrun.

Next evidence sought

  • Apply the views and linked checks to an actual service.