The service remains in use
In the fictional example, a cancellation during the proposed trial could expose a new exception. The service owner needs a route to correct local work, improve the service or reopen a wider architecture decision.
| Loop | Work and retained result |
|---|---|
| Prepare and introduce | Define scope, versions, open work, readiness checks and authority to proceed. |
| Operate and support | Maintain ownership, access, service knowledge and the actual operating position. |
| Respond and recover | Coordinate containment, restoration, reconciliation and communication. |
| Improve and govern | Review causes, recurring effort, service objectives, costs and remaining risks. |
These loops connect A Simple Architectural Framework (ASAF)’s Transforming, Operating and Governing process areas. They can return to Visioning when experience changes the intended service or its viability.
Where a finding goes next
An incident review may change a local support instruction, require a service change or reopen a shared architecture decision. Record which finding led to the change and who accepts it. Restoration can be complete while the cause remains unresolved. Keep that distinction in the support record and use guidance supersession when an accepted instruction needs replacing.
Methodology configuration
Your service desk, incident process, change process and review meetings may implement these loops in different combinations. Use Methodology configuration to map terms, records and reviews to your own approach.
Dials
Review each release at the scale of its effects. Respond to incidents as they occur. Review trends and known problems at agreed intervals. Limit simultaneous changes so the team can understand their effects and recover when something fails. Coordinate affected owners; pre-agree who may stop work or invoke a fallback. Automate checks and alerts with a named response owner. Use recurring problems to review planned work and funding.