Use an architecture review to resolve a decision.

Invite the people who own the consequences

Include application, data and operating perspectives where the decision crosses those boundaries. A review without the future operator can miss a costly constraint.

Finish with a decision record

Capture what was agreed, what remains uncertain and who will obtain the missing evidence. A meeting summary without actions does not move the design forward.

Choose a question the session can resolve

An architecture session works best when it has one decision to advance. Examples include where customer identity should live, how a new integration will recover from failure or whether a workflow needs an AI component. A broad request to review everything makes it difficult to prepare useful evidence.

Before the session, share a short description of the current system, the problem and any fixed constraints. Include a simple diagram if one exists, but do not delay the conversation to produce a polished presentation. Invite the people who operate the workflow as well as those who build it. They often know failure cases that are absent from the diagrams.

Work through one normal case and one failure

Start by following a real transaction through the system. Identify where information changes, where access is checked and where a person makes a decision. Then change one condition, such as an unavailable provider, a duplicate request or a user losing access part way through the process.

Use the failure case to expose assumptions. If nobody can say which system owns a partially completed order, the design has an unresolved boundary. Record the uncertainty in plain language and decide what evidence would resolve it. The session should produce a clearer decision, not simply a more detailed picture of an uncertain system.

Turn discussion into an accountable next step

Close by recording the chosen direction, alternatives considered and unresolved questions. Assign an owner to each follow-up and agree when the decision needs to be revisited. A diagram without those details can look complete while leaving the original disagreement intact.

Useful outputs may include a decision record, a small validation experiment or a first delivery increment with acceptance criteria. Keep those outputs accessible to the team that will implement and maintain the change. This page describes an architecture session format rather than a calendar of scheduled events. Availability, participants and commercial arrangements need to be agreed for an actual engagement.