The case service

A later software option

The fictional cancellation service first proposes a shared register and agreed handover procedure for provider-run courses. This page explores a possible later software increment, SI-D1 (Case-service option). It has not been built or tested.

The business example requires continuous case ownership until resolution or accepted transfer. The data example defines the case, learner agreement and assignment history. The organisation example establishes who may accept work and how cover is arranged. Those rules continue here.

Responsibilities

These are logical responsibilities. Their packaging and deployment remain open. SI-D1 would move the shared register into the case service only after migration and acceptance checks; the earlier process-only trial remains the starting point. The diagram below shows selected exchanges.

Proposals and permission

The optional AI assistant could receive the permitted case version, agreement reference and next-action details, then return a proposed summary with its source references and any missing information. Record the prompt and model configuration versions needed to investigate the result. Check the output against the case before it enters another prompt or tool call.

In this proposal, AI has no authority to accept learner agreement or transfer ownership. The service checks the person’s permissions. For a new acceptance operation, it also checks the current case version. Data access, retained prompt content and supplier arrangements need agreement before real records are used.

The acceptance contract

Contract SI-C01 (Transfer acceptance contract) defines how the receiving person accepts an offered transfer through the case service. For an illustrative case C42 (Example cancellation case), offer H7 (Example transfer offer) identifies the intended receiver and case version 12. The receiver has checked the learner’s agreement to the chosen alternative and the next action. They have also checked that they have the access and capacity needed to take the case. The existing assignment remains current until the accepted transfer takes effect in the case service.

The request contains a unique operation identity, X7 (Acceptance operation), so the service can recognise a repeat. It also identifies the case, offer and expected case version, 12. The version identifies the accepted record on which the request is based. The service authenticates the caller and checks their authority to accept the offer; naming a receiver in the request is not sufficient permission.

For a new operation, the service checks that the offer is pending, addressed to this receiver and based on the current case version. As one atomic change, it closes the previous assignment, records the new assignment, marks the offer accepted, retains the operation result and records a pending notification. Either all these changes take effect or none do. The accepted case becomes version 13. Its case state, such as “awaiting confirmation”, remains unchanged.

Concurrent requests must be checked against the same authoritative state. A second new operation based on version 12 cannot also apply after the first has changed that state. Rejected or stale offers need a fresh review of the case before another acceptance is proposed.

A mobile client can retain a proposed action while offline. It shows that action as pending until the case service accepts it. On reconnection, a changed case version requires review; the most recent device timestamp does not win ownership automatically.

The lost response

Suppose the change takes effect but the response is lost. The client shows outcome unknown, retains X7 and looks up its result, or repeats the same request with that identity. A timeout does not establish that nothing happened.

Within the agreed retention period, an authorised repeat with the same inputs returns the recorded result. It does not make another assignment. The service recognises the existing operation before treating the old expected version as a new conflicting update. Reusing X7 with changed inputs is rejected.

The service checks the caller’s current permission to retrieve the result. A caller whose access has been revoked cannot retrieve an old receipt through a lookup or retry.

The identity is scoped to the caller and operation type. Both the original request and result must survive a service restart. Retention, expiry, retry limits and lookup permissions must be agreed before implementation. If the receipt is missing or expired, the outcome remains unknown. Support reconciles the case and its history; the client must not silently create a fresh operation identity and try again.

An old receipt describes what that operation did. If a later legitimate transfer has occurred, the current owner may have changed again. Display the operation result and current case state separately.

Notifications and reports

The proposed case update also records a pending notification in the same transaction. A separate delivery step sends it and retries failures. This is the transactional outbox pattern: the accepted update and the record of work to send remain together. Delivery may still repeat, so consumers need to handle duplicates.

The event identifies its source, event identity, case and accepted version. A reporting consumer applies each relevant change once to its derived view, checks version order and reconciles gaps against the authoritative case record. A late older event must not overwrite a newer view. Reconciliation and alerting need an assigned support owner and agreed timing.

A current ownership view and an operational notification may need different responses to a missing event. Fetching the latest case can repair the view; it may not establish whether an earlier notification was sent. Record that outcome separately. The data processing example shows how corrected case facts affect reports.

Booking completion

Acceptance of a handover does not confirm a replacement booking. If a booking request times out, the case owner needs its operation result or a supplier reconciliation route. The case stays unresolved until the required agreement and booking confirmation are established. A case-service transaction cannot by itself make a remote booking transaction atomic.

Partner bookings and refunds remain separate later decisions. A supplier interface must make its own acceptance, confirmation and recovery rules clear.

Proposed checks

SI-V1 (Interface checks) is an unrun set of checks for a future implementation.

Timing targets, storage and transport choices, operation retention, staffing and supplier behaviour remain open. When the checks run, record elapsed time and correction effort. Assessing support needs and long-term usefulness will require experience of operating and changing the service.

The shared contract

The component design, SW-D1 (Case-service components), develops SI-D1 inside the case service. It must preserve SI-C01, including the receiver, learner agreement, current case version and distinction between transfer and case resolution. The component design remains unimplemented.

Component responsibilities

These are logical components; packaging and language remain open. The rule module can be exercised without a screen or model provider. The transaction store still needs checks against the actual persistence mechanism.

A proposed rule

Rule SW-R1 (Transfer rule) accepts facts about the case, offer, receiver and authority. For a new operation, it requires a pending offer addressed to the authenticated receiver and based on the current case version. For this handover, the required agreement reference and next action must be present. Missing required facts produce a rejection with a reason, rather than a guessed default.

If the conditions hold, it returns a plan naming the old assignment, new assignment and expected version. It does not save the case. The handler asks the transaction store to apply the complete change only if that version is still current. Concurrent operations must compete at this point: at most one can advance version 12 to 13.

The accepted change closes the previous assignment, creates the new one, marks the offer accepted and retains the result for operation X7, together with a pending notification. The case’s resolution state remains unchanged. If any part fails before commit, none of those updates takes effect.

Repeats and failures

After authenticating the caller and checking current permission to retrieve an operation’s result, the handler recognises an existing X7. Within the agreed retention period, the same inputs return the retained result. Changed inputs are rejected. This path does not rerun the transfer rule against the now newer case as though it were a new acceptance.

For a new operation, the handler checks acceptance authority and current facts. A stale version returns a conflict requiring review. A storage interruption may leave the caller’s outcome unknown; it triggers result lookup or the agreed recovery procedure. An expired lookup requires reconciliation. A historical receipt is displayed separately from the current owner.

A mobile client’s early validation can help the person prepare a request. It cannot commit ownership while disconnected. The service applies SW-R1 when the request reaches it, and the client must handle a changed case.

A summary between steps

Contract SW-C1 (Summary workflow contract) describes the optional summary workflow. Each stage has a different result and authority. Before preparing context, the workflow checks the caller’s permission to read the relevant case facts:

For example, a proposal saying “the learner agreed” must point to the agreement for the chosen alternative. A syntactically valid reference is insufficient if it concerns another alternative. The next prompt or tool must receive the record’s identity, version and review status, rather than treating generated prose as an accepted business fact.

A second model may help review wording, but agreement between models does not replace source checking or human authority. If the case changes, invalidate or recheck the prepared context and summary. A generation timeout must not create an acceptance request. Agree retry limits, retention and support before use.

Component checks

SW-V1 (Component checks) develops the earlier SI-V1 conditions at the components that own them. All checks remain unrun.

These checks serve different purposes. Rule examples do not qualify storage atomicity, and model evaluation does not qualify case acceptance. Record actual results, versions, timing and investigation effort when an implementation exists.

Change and support

The service owner accepts changed business meaning; maintainers change its implementation and checks. Keep rule, schema, prompt and migration versions connected. Compare old and new results on representative cases, including pending work. Changing a library or provider may alter errors, timing or output without changing a function’s name.

The technology example examines the persistence, recovery and capacity obligations from this proposal. No deployment or language has yet been selected.