Ask the questions that expose a real decision

Choose the prompt for the next unresolved decision

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 proof. 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.

Agree the outcome before choosing a solution

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.

Set the loops for the next decision

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.

Give one component a clear owner

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?

Preserve why a decision was made

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 rejected concerns rather than turn them into a retrospective justification.

Rehearse failure before support has to improvise

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?

Use the prompts on one complete slice

Start with the smallest service path that crosses a meaningful responsibility. The rebooking example is one proposed test. 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.