# SI-T01: Interface contract

Adrian Sutherland · Version 1.0 · Refreshed September 2026

© 2005–2026 Adrian Sutherland.
Source page: https://architectureportal.org/assets/systems-integration

Fictional cancellation service. Proposed design; checks are unrun.

## Identity and purpose

SI-C01: Accept offered case transfer. Proposed under SI-D1. Business service owner approves the rule; the case-service maintainer implements it. Named people remain to be assigned.

## Linked decisions

R1: continuous ownership until resolution or accepted transfer. I1: case record. ID-D1: shared case register and history. OP-D1: accepted-transfer procedure. SI-D1: possible later software increment. SI-V1: proposed checks. Example: https://architectureportal.org/systems-integration/worked-example.

## Participants and authority

The receiving person acts through the staff client. The case service authenticates the caller and checks authority to accept the named offer. It holds accepted assignments. The booking service remains authoritative for bookings. AI can propose a summary but cannot accept learner agreement or ownership.

## Input and meaning

Unique operation identity X7, case C42, pending offer H7 and expected case version 12. The offer names its intended receiver and references the learner's agreement to the chosen alternative and the current next action. Caller identity comes from authenticated context. No learner details need be repeated in this request. Identity is scoped by caller and operation type.

## Acceptance and result

For a new operation, validate authority, pending offer, intended receiver and current version. Atomically close the former assignment, create the accepted assignment, mark the offer accepted, retain the operation result and pending notification. Either all changes commit or none do. Return accepted version 13 and operation result. Case state remains unchanged by transfer. One current owner remains; acceptance does not resolve the learner case.

## Repeat and conflict

Within the agreed retention period, recognise an authorised repeat before applying new-operation version checks. The same identity and inputs return the retained result. The service rejects changed inputs. Concurrent new requests based on version 12 cannot both apply. A receipt is historical: query current case state separately after later changes. Durable retention, expiry and lookup access are open. Unknown or expired result requires reconciliation; do not silently use a new identity.

## Failure and timing

Permission failure or stale version rejects the new operation. Loss of response after send leaves outcome unknown. Retain X7 for lookup or a permitted repeat. Agree request timeout, retry budget, backoff, operation-retention period and support response target before implementation. Use SI-T02 for unresolved outcomes.

## Data handling and support

Use minimum case references in notifications; authorised consumers fetch permitted details. Decide retention and access for requests, results, history, logs and any AI context. Assign named case-service support for outcome reconciliation and notification failures. The duty coordinator arranges operational cover; a client timeout alone does not change the authoritative assignment.

## Compatibility and checks

Contract version 1.0 proposal. Check SI-V1, including restart, duplicate, conflicting version, expired lookup and unauthorised action. The design has not been implemented and the checks have not run. Use SI-T03 to plan migration and consumer compatibility; payload, storage, transport and deployment choices remain open.