Architecture Portal

Blueprint objects

A reference for names, identifiers and meaning.

Adrian Sutherland · Version 1.0 · September 2026 · © 2005–2026

An identifier names a particular item across the views. For example, X7 (Acceptance operation) identifies the illustrative transfer request; R1 (Continuous ownership) identifies an architectural requirement. A case version such as 12 or 13 describes that case’s state, while version 1.0 identifies this website edition.

The catalogue below includes design states, architecture records, example instances, roles, information and components. The source link leads to the record that explains each item in context. When using another method, retain the reference while mapping the name to your own terminology.

Download the object catalogue as JSON or as CSV. Return to the blueprint index.

Outcome

Object	Meaning and source
O1 (Accepted resolution)	The learner receives a timely resolution they accept, with one named owner until it is confirmed. Read in context

Principle

Object	Meaning and source
P1 (Learner agreement)	The learner must agree to the chosen alternative. Read in context

Requirement

Object	Meaning and source
R1 (Continuous ownership)	Preserve learner agreement and continuous case ownership through each handover. Read in context
CH-S1 (Pending and accepted actions)	A locally saved or offline proposal becomes accepted only after authoritative service acceptance. Read in context

Capability

Object	Meaning and source
C1 (Resolve a cancelled booking)	The ability to reach a confirmed resolution after a course cancellation. Read in context

Value stream

Object	Meaning and source
VS1 (Cancellation resolution)	Understand options, agree a resolution and receive confirmation. Read in context

Process

Object	Meaning and source
PR1 (Resolution process)	Open the case, assign an owner, contact the learner, agree an alternative and confirm. Read in context

Role

Object	Meaning and source
RO1 (Case owner)	The named person responsible for the case until confirmed resolution or effective accepted transfer. Read in context
ROLE-LEARNER (Learner)	Chooses whether an alternative meets their need. Read in context
ROLE-TEAMS (Booking and course teams)	Record cancellation, identify alternatives and provide booking confirmation. Read in context
ROLE-COORD (Duty coordinator)	Arranges suitable cover and escalates unresolved gaps. Read in context
ROLE-SERVICE (Service owner)	Approves service meaning, readiness, exceptions and changes in scope. Read in context
ROLE-STEWARD (Data steward)	Maintains shared definitions and coordinates recurring quality issues. Read in context
ROLE-FUNDING (Funding owner)	Authorises expenditure and commitments. Read in context
ROLE-PARTNER (Course partner)	Would accept agreed booking and confirmation responsibilities. Read in context
ROLE-RECEIVER (Receiving case owner)	Checks current information, authority, access and capacity before accepting a transfer. Read in context

Information

Object	Meaning and source
I1 (Cancellation case record)	The case, booking reference, current owner, options, agreement, state, next action and confirmation reference. Read in context

Relationship

Object	Meaning and source
A1 (Responsibility and information)	The case owner maintains the case record through the resolution process. Read in context

Decision

Object	Meaning and source
D1 (Process-only trial)	Propose a shared register and accepted handovers for provider-run courses. Read in context
ID-D1 (Shared case register)	Use a case register with linked assignment, agreement and correction history. Read in context
OP-D1 (Accepted-transfer procedure)	Offer current context; receiver checks access, capacity and authority; record acceptance and effective transfer. Read in context
SI-D1 (Case-service option)	Possible later software increment replacing the shared register after migration and acceptance. Read in context
SW-D1 (Case-service components)	Separate input, transfer handling, pure rules, conditional storage and notification work. Read in context
TD-D1 (Runtime arrangement)	Evaluate one application release and a durable transactional store; products and instance counts remain open. Read in context
MG-D1 (Shared direction)	Link learner resolution to the cancellation trial and a possible partner service. Read in context
FN-D1 (Option cost comparison)	Compare invented twelve-month costs on a stated common basis; preference remains open. Read in context
CU-D1 (Customer roles)	Distinguish learner choice, payer authority and representative permissions. Read in context
SU-D1 (Partner responsibilities)	Agree authority, confirmation, information, failure and exit before adding a partner service. Read in context
CH-D1 (Cross-channel journey)	Retain the same case and meaning through messages and assisted calls. Read in context

Check

Object	Meaning and source
V1 (Two-handover check)	Follow a cancellation through two handovers and check owner, agreement and next action; unrun. Read in context
ID-V1 (Case meaning checks)	Check duplicate cases, agreement/confirmation consistency, ownership and corrections; unrun. Read in context
OP-V1 (Handover checks)	Check waiting, absent owners, access, changed records and conflicting offers; unrun. Read in context
SI-V1 (Interface checks)	Exercise lost responses, conflicts, repeats, restart, notifications and unknown booking outcomes; unrun. Read in context
SW-V1 (Component checks)	Check rules, atomic writes, concurrency, recovery and summary restrictions; unrun. Read in context
TD-V1 (Environment checks)	Test commit, restart, restoration, access dependency and representative load in the chosen configuration; unrun. Read in context
CU-F1 (Channel research)	Check whether assisted and online routes preserve the same learner choice; unrun. Read in context
SU-X1 (Partner exit exercise)	Transfer an open case and remove former access without losing necessary history; unrun. Read in context

Finding

Object	Meaning and source
L1 (Partner confirmation gap)	A hypothetical partner alternative has no agreed confirmation owner; it triggers a scope decision. Read in context

Definition

Object	Meaning and source
ID-DEF1 (Learner agreement definition)	Acceptance of a specific alternative with actor, time and supporting interaction. Read in context

Contract

Object	Meaning and source
SI-C01 (Transfer acceptance contract)	Authority, version, atomic acceptance, retained result, repeat and failure rules for an offered transfer. Read in context
SW-C1 (Summary workflow contract)	Prepare permitted context, generate and check a proposed summary, then obtain human review. Read in context

Rule

Object	Meaning and source
SW-R1 (Transfer rule)	Validate current facts and return a transfer plan or rejection without external effects. Read in context

Example instance

Object	Meaning and source
C42 (Example cancellation case)	An illustrative instance of the cancellation case, not a class of case. Read in context
H7 (Example transfer offer)	An offer naming the intended receiver of case C42 at expected version 12. Read in context
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

Risk

Object	Meaning and source
SEC-R1 (Excess disclosure)	Disclosure of unrelated or unnecessary learner information. Read in context
SEC-R2 (Unauthorised acceptance)	An actor without current authority accepts ownership. Read in context
SEC-R3 (Unsafe summary use)	Summary content discloses information or induces an unauthorised action. Read in context
SEC-R4 (Altered records or traces)	An intruder changes records or removes information needed for investigation. Read in context

Control

Object	Meaning and source
SEC-A1 (Service authorisation)	Check trusted identity and current policy where a read or action takes effect, including receipt lookup. Read in context

Record

Object	Meaning and source
SEC-O1 (Security operation record)	Link actor, action, case, policy decision and result for protected investigation and recovery. Read in context
TD-R1 (Recovery procedure)	Distinguish restart from restoring older data; reconcile lost accepted work before resumption. Read in context
TD-C1 (Release and compatibility)	Control package, configuration, schema, clients and recovery behaviour through a release. Read in context
MG-R1 (Service roadmap)	Sequence changes and prerequisites, including partner acceptance responsibilities. Read in context
MG-E1 (Temporary exception)	Identify the owner, scope, checks and review trigger for a temporary arrangement. Read in context
FN-C1 (Funding commitment)	Link expenditure and its authorisation to a funding owner and architecture decision. Read in context
SO-R1 (Readiness record)	Gather migration, staffing, observation and recovery checks before use. Read in context
SO-A1 (Service acceptance)	Service-owner decision based on checks, risks, funding and fallback arrangements. Read in context
SO-I1 (Incident and restoration)	Pause affected work, reconcile accepted actions, and obtain service-owner agreement before resuming. Read in context

Measure

Object	Meaning and source
MT-M1 (Resolution measures)	Measure resolution time, ownership gaps, correction effort and architecture decision time separately. Read in context
MT-Q1 (Recovery quality)	After restore, establish the accepted work lost and reconciled as well as technical recovery time. Read in context

Design state

Object	Meaning and source
PROC-01 (Process-only proposal)	The provider-run course trial using a shared register and an accepted-transfer procedure. Read in context
SOFT-01 (Later software option)	The unimplemented case-service arrangement preserving the process and information rules. Read in context
PART-01 (Partner extension)	A later scope option requiring agreement on supplier responsibilities and confirmation. Read in context

Component

Object	Meaning and source
SYS-CLIENT (Staff client)	Presents case state and sends proposals; offline saving does not transfer ownership. Read in context
SYS-CASE (Case service)	Owns authoritative case information and accepts permitted case changes. Read in context
SYS-BOOKING (Booking service)	Owns bookings and booking confirmation independently of case transfers. Read in context
SYS-IDENTITY (Identity service)	Provides trusted identity information; service policy determines authority. Read in context
SYS-NOTIFY (Notification delivery)	Delivers committed notifications and exposes failures; delivery may repeat. Read in context
SYS-REPORT (Reporting consumer)	Maintains a derived view, detects version gaps and reconciles with the authoritative case. Read in context
SYS-SUMMARY (Optional summary workflow)	Returns a source-linked proposal for human review; cannot accept agreement or ownership. Read in context
CMP-INPUT (Input adapter)	Decodes requests and obtains authenticated context. Read in context
CMP-HANDLER (Transfer handler)	Coordinates authority, retained-result lookup, rule evaluation and conditional save. Read in context
CMP-RULE (Transfer rule module)	Returns a plan or rejection based on current facts; causes no external effects. Read in context
CMP-STORE (Transaction store)	Commits all acceptance records together only against the expected version. Read in context
CMP-RELAY (Notification relay)	Sends committed pending work and records delivery progress. Read in context

Information object

Object	Meaning and source
DATA-BOOKING (Cancelled booking)	The learner and cancelled course occurrence that a case concerns. Read in context
DATA-ASSIGN (Owner assignment)	One case assignment with its effective period; only one is current. Read in context
DATA-AGREEMENT (Learner agreement record)	One accepted alternative, actor, time and source reference; at most one current agreement. Read in context
DATA-CONFIRM (Booking confirmation)	Confirmation of the current agreement and resulting booking. Read in context
DATA-RECEIPT (Acceptance receipt)	The retained outcome of one operation; historical and distinct from the current owner. Read in context
DATA-PENDING (Pending notification)	Work to deliver recorded atomically with the accepted transfer. Read in context

Runtime responsibility

Object	Meaning and source
TECH-APP (Application release)	The evaluated packaging of the case-service components and notification worker. Read in context
TECH-STORE (Durable transactional store)	Preserves accepted state, receipt and pending work across restart. Read in context
TECH-COPY (Recovery copy)	A mutually consistent recovery set whose retention and acceptable loss need agreement. Read in context

Blueprint view

Object	Meaning and source
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
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
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
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
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
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
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
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

Asset set

Object	Meaning and source
BP-R01 (Blueprint record set)	Cover, view records, linked objects, decisions and reusable outline. Read in context

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 2026-09-18

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.