One service change can reopen several decisions
A cancelled appointment can change a business rule, an authoritative record, a team’s work, the software that carries the request, the recovery procedure and the assurance decision. Those responsibilities do not change on one timetable. A recovery rehearsal may show that the wrong component owns a record. A support team may discover that an apparently successful interaction leaves a person unable to continue.
The method makes those movements explicit. An architecture loop is a recurring question, the people or tools allowed to answer it, and a result that may change later work.
Six loops carry intent into use
- Purpose and outcomes asks whose situation should improve, what result is worthwhile and how people will recognise it.
- Domain and organisation establishes the work, information, language, policy and human responsibility needed to produce that result.
- Architecture and blueprint assigns logical component roles, defines their interactions and turns important qualities into questions that can be tested.
- Delivery and experiment implements the smallest complete change that can answer the next important question.
- Operations and support checks whether people can observe, diagnose, recover, support and safely change the service.
- Assurance and learning challenges whether the result remains safe, lawful, secure, explainable and faithful to its purpose.
The order explains how intent can travel into operation. It is not a required handoff. Several loops can run together, and a result can return directly to any earlier loop that needs to change.
A seventh loop decides what becomes shared guidance
The portfolio-learning loop asks whether a result applies beyond one delivery slice. A useful interaction pattern may enter the system blueprint. A workshop prompt may need revision. A component idea may be retired after an implementation exposes a false assumption.
This wider loop prevents a reference architecture from becoming a frozen catalogue. It also stops one local result from becoming a general rule without review.
Six dials change how each active loop runs
- Cadence: when the loop runs—continuously, daily, per increment, per stage or per release.
- Batch size: whether it considers one decision or thin slice, or waits for a larger specification and release.
- Coordination: whether roles exchange a formal handoff, synchronise at intervals or work together continuously.
- Decision authority: what an agent, team, architect, operator, risk owner or sponsor may decide.
- Automation and proof: what a tool may generate, simulate or check, and which result a reviewer needs before accepting the change.
- Learning reach: whether a finding changes one increment, the system blueprint, the operating model or the wider portfolio.
Recording these settings is more informative than attaching a delivery label to the project.
The same dials produce different delivery profiles
- A staged or waterfall profile tends to use larger batches, formal handoffs and later operational feedback. Assurance is often concentrated at gates.
- An evolutionary or agile profile uses smaller batches and reconnects purpose, architecture, delivery, operation and assurance throughout the work.
- A high-assurance incremental profile keeps batches small but requires frequent independent challenge, strong traceability and low autonomy for high-impact decisions.
- An agent-assisted profile may shorten research, modelling, implementation and checking. Its authority and required proof still need to be set loop by loop.
A real programme may combine these settings. The method helps a team describe that combination and decide whether it suits the risk and uncertainty.
Keep agents inside the authority people set
An agent-assisted loop can frame a question, research alternatives, propose a change, run defined checks and prepare a decision record. A person still owns the purpose, grants the authority, reviews consequences and accepts or rejects the result when judgement is required.
Increasing automation changes the speed and the acting role inside a loop. It does not remove operational responsibility, independent review or the need to learn from failure.
Apply the dials to the rebooking slice
Suppose a service cancels an appointment and a scheduling team must offer a new date within five working days. A staged team might approve the complete record, work and rule design before implementation. An evolutionary team might first deliver one repeatable rebooking request and learn from support use. A high-assurance team might add independent review of the deadline rule and recovery behaviour to that same increment.
An agent could draft the interaction, implement a test fixture and run the checks. The service owner would still approve the rule, the operator would accept the recovery procedure and the delivery record would say what the agent was not authorised to change.
The blueprint turns this loop profile into named responsibilities. The working assets provide questions for recording the settings and decisions.