Review questions

Choose a question

The templates provide editable records and completed examples. Use the questions below to prepare a discussion or review a record.

Use one prompt when one is enough. The outcome prompt records who should benefit and what should change. The loop profile records cadence, authority and required checks. The component card names the owner and accepted requests. The decision record preserves the choice and its review trigger. The failure review identifies what people can observe and who may recover the work.

Outcome

Ask:

• Whose situation should change, and what should be different?
• What observation or measure would show that the change helped?
• Who is affected, and what do they need to understand or decide?
• Which legal, ethical, operational, financial or technical constraints matter?
• What will this work deliberately leave alone?
• Which assumption would invalidate the direction if it proved false?

Keep the result short enough to review when delivery or operation produces new information.

Cycles

For each active architecture loop, record:

• The question it is answering now.
• Its cadence and batch size.
• How its roles coordinate.
• The people or tools allowed to act.
• The test result, observation or approval needed before the loop closes.
• Whether a new finding may change only the increment, the system blueprint, the operating model or the wider portfolio.

This describes the real delivery profile without relying on a label such as agile or agent-assisted.

Component responsibility

Ask:

• What result does the component own, and what must remain elsewhere?
• Who uses it, operates it and approves consequential changes?
• Which requests does it accept, and which accepted facts does it report?
• Which information does it own, reference and retain?
• What happens when a request is repeated, delayed, refused or partly completed?
• Who observes failure, and who may retry, correct, compensate or stop?
• Which qualities must a defined check establish before the component is used?
• Could another implementation replace it without changing unrelated parts of the service?

Decisions

1. Describe the situation and the decision that is needed.
2. Compare realistic options and their important differences.
3. Name the person with authority to decide.
4. Record the chosen option and its consequences.
5. Identify the tests or observations that could challenge it.
6. Set a date or condition for review.
7. Link the decision to the implementation and the observed result.

A decision record explains a choice. It should preserve uncertainty and reasons for rejecting alternatives rather than turn them into a retrospective justification.

Failure and recovery

Choose one important failure and ask:

• What can a participant, operator and neighbouring component observe?
• Which information may be missing, duplicated, late or contradictory?
• Which actions are safe to repeat?
• Who may retry, correct, compensate or stop the work?
• What history must remain after recovery?
• How will support staff know that the service and the work are healthy again?
• Should the lesson change the component, runbook, method or blueprint?

Try one service path

Start with one service path that hands work from one role or component to another. The course-cancellation example follows one proposed change. Record which questions changed a decision, which created unnecessary work and which concern was missing. That observation is what should improve the next version of the assets.

Use the assessment guide to distinguish the quality of the resulting architecture from the effort and usefulness of your method.