Architecture Portal

Systems and rules

Responsibilities from interface to implementation.

Adrian Sutherland · Version 1.0 · · © 2005–2026

BP-V06 (Systems and rules) · Version 1.0 · September 2026

Systems and rules

A contract carried by named responsibilities.

Design state
SOFT-01 (Later software option)
Level
Logical
Design
Proposed; checks unrun
Scope
Case-service components and their external exchanges
ASAF aspects
Systems, Information, Channel, Security

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

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.
BP-V06 (Systems and rules). Fictional software option; implementation checks are unrun.

Key

  • Boxes identify logical responsibilities; grouping does not require separate deployments.
  • Arrows name requests, plans or information. Optional summary and booking contracts remain separate.

Linked records

Text description

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.

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 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 retains the complete contract. The reference catalogue explains the wider roles that another solution might need.

About this edition

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

Scope, limitations and next checks

Status and accountability

Read this page with its boundaries visible

Status

Proposed

Last reviewed

Intended users

  • Architects describing, comparing and adapting an architecture

Non-goals

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

Limitations

  • The service is a fictional design. Its proposed implementation and operational checks remain unrun.

Next evidence sought

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