Architecture Portal

Generic support assets

Acceptance, diagnosis, recovery procedures and useful measures.

Adrian Sutherland · Version 1.0 · · © 2005–2026

A service can be running while the people using it still have unresolved work. These support assets help a team define an acceptable outcome, investigate without changing the service and check how it would recover.

Each task pairs a human brief with an artificial intelligence (AI) prompt template, required inputs, expected outputs and a fictional worked example. Adapt the record to your sources and existing authority. The download contains the complete template; the descriptions below help you choose one.

Acceptance criteria

Define observable outcomes and the checks needed to accept a service or support change.

State whose outcome matters and under which conditions. Describe the expected behaviour, failure response and observation needed. Name the person who accepts the result and keep targets separate from actual observations.

Human brief and AI prompt template — Markdown

Example. For the fictional service, an accepted handover must leave one current owner, retain pending work and return a receipt to an authorised caller. The checks have not run, so the sample has no actual results. An availability target remains for the service owner to agree.

Read-only diagnosis

Establish the observed service position without changing it during investigation.

Collect the relevant records using authorised read access. Preserve timestamps, environment and source identity. Summarise symptoms and affected work, distinguish live observations from historical or simulated records, and identify useful next checks.

Human brief and AI prompt template — Markdown

Example. For the fictional lost response, support reads the request record, case version and receipt store. The example describes what to collect; no live incident has occurred and no booking is retried.

Causal uncertainty

Assess possible causes while retaining missing information and competing explanations.

Compare each plausible explanation with observations that support or contradict it. Consider timing, dependency direction and shared causes. Choose the next observation that could distinguish explanations rather than forcing a definitive root cause.

Human brief and AI prompt template — Markdown

Example. A fictional missing booking could reflect failed acceptance, failed notification after acceptance or incomplete records after restoration. The sample leaves the cause open and proposes checking the durable receipt and restored-record history.

Runbook validation

A runbook records the steps for a known service task. Check whether that procedure is suitable for the actual target and current conditions.

Identify the runbook edition and target. Check prerequisites, permissions, expected effects and what might have changed. Establish stop conditions, verification and recovery, including business actions that a technical rollback would not undo.

Human brief and AI prompt template — Markdown

Example. A fictional restore runbook brings back data from before a handover. Validation identifies the risk of losing the receipt while staff have already moved the work. The proposed procedure must reconcile those actions before resumption.

Honest measures

Use measures that describe the outcome and cost relevant to a decision.

Define the observation before interpreting it. Record the unit, population, start/end events, period, exclusions, source and owner. Include failure, review and rework where they affect the outcome, and explain what a figure cannot establish.

Human brief and AI prompt template — Markdown

Example. A fictional cancellation measure counts resolved learner cases as a proportion of all in-scope cases during a stated period. It reports outstanding cases and repeat contacts separately. A cost-per-resolution measure includes relevant work on unresolved cases, review and rework. Tokens are the units of text a language model processes or produces. A fast response from an application programming interface (API), or a low token count, does not establish that the learner’s case was resolved.

Connected guidance

Supporting a service connects these tasks to people, records, response and learning. Metrics explains how to define and interpret observations.

AI-supported architecture describes how these activities can use AI assistance. Browse the other IT practice collections when a task crosses governance, delivery and support.

Methodology configuration

Use the terms and records your team already understands. Keep their meanings, source versions and decision owners clear. Methodology configuration explains how to map the activities and reviews to your own approach.

Edition and reuse

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

Portal-authored downloads use CC BY 4.0. Keep the author, source edition and licence with adaptations, and identify changes. Read the edition note and use the asset index — JSON for the complete list of tasks and download addresses.

About this edition

Refreshed for the September 2026 website update. This edition extends the retained Architecture Portal and ASAF material with IT practice assets and reported project experience.

Scope, limitations and next checks

Status and accountability

Read this page with its boundaries visible

Status

In development

Last reviewed

Intended users

  • Architects adapting their own approach to IT design, delivery and support

Non-goals

  • A mandatory methodology or a guarantee of AI accuracy or operational safety

Limitations

  • Guidance and adaptable examples; the fictional service is unimplemented and its checks remain unrun.

Next evidence sought

  • Apply the guidance to a real task and review usefulness, results and limitations.