Learning goal: distinguish conditional acceptance of an architectural direction from permission to launch a service, and turn each condition into an accountable, verifiable obligation: owner, evidence, verifier and decision gate.

Fictional educational scenario. A review group accepts a design on two conditions: demonstrate that access can be revoked effectively, and recover the complete user journey after a failure. The minutes end with “IT will confirm compliance”. Delivery reads this as a green light. Nobody has agreed who runs the checks, who assesses the evidence or what happens if a test fails. This is a model example, not an account of an incident at a particular organisation.

Three options, three different consequences

OptionBenefitRisk
A. Accept without qualification and move the conditions to a task list.Work starts quickly.No explicit gate stops launch when evidence is missing; a declaration may be mistaken for completion.
B. Stop all work until both checks are complete.Uncertainty is not mistaken for proof.Work independent of the checks is blocked, increasing waiting costs.
C. Conditionally accept a defined scope but keep the launch gate closed until evidence is verified.Reversible work can proceed while the risk is controlled.Conditions need active tracking and an explicitly authorised gate decision-maker.

Choose C in this scenario, provided the missing evidence does not undermine the feasibility of the architecture itself. Accepting a direction, authorising implementation and authorising launch may be three separate decisions. A single “approved” status should not collapse them.

Give every condition an execution contract

Record six fields for each condition: what must be true, who owns fulfilment, which artefact proves it, who verifies and accepts that evidence, before which gate, and what happens on failure. A due date and decision ID help with traceability but cannot replace acceptance criteria.

Condition and criterionDelivery ownerEvidence and verifierGate
Access revocation: after privileges are withdrawn, a protected operation is denied even from a previously active session.Owner of the identity mechanism.Positive and negative test record; reviewed by the security-control verifier.Before users are admitted.
Service recovery: after a controlled failure, the agreed user journey works, not merely the database process.Owner of service continuity.Recovery exercise report with outcomes, limitations and deviations; reviewed by the operational-readiness verifier.Before production launch.

These are illustrative roles, not a universal governance policy. The review coordinator maintains decision coherence and escalations; that does not automatically make them the control owner, test executor or risk acceptor. The final gate belongs to the role authorised by the organisation's actual governance.

Write a decision someone can execute

Example decision note: “We accept the architectural direction for reversible work. This does not authorise service launch. Before the launch gate, the two control owners must provide agreed test results; designated verifiers must confirm the acceptance criteria. Missing evidence or a failed test leaves the condition open and returns the matter to the authorised decision-maker: change the design, repeat the test or explicitly change the scope. Silence is not acceptance.”

The minimum flow is proposal → conditional acceptance → evidence and verification → gate decision. Keep the decision version, date, outstanding conditions and evidence links in the record. Do not mark a condition closed merely because its deadline passed or its delivery task was marked done.

When is C the wrong choice?

If an essential mechanism may not be feasible at all, the condition could invalidate the design. Do not approve a direction whose viability depends on that unknown: commission an experiment or proof of feasibility and revisit the options. Conversely, a minor improvement should not automatically block launch; record it as follow-up work with an owner and due date. The consequence of a failed condition, not emphatic wording in meeting minutes, should determine the gate.

Your two-minute decision

An owner submits a screenshot saying “test complete”, but it does not describe the negative test case. Launch is tomorrow. Can the coordinator close the condition? Not on the screenshot alone. Compare the evidence with the criterion, obtain the designated verifier's assessment, and keep the gate closed or refer an exception to the authorised risk decision-maker. Coordination is not a substitute for that decision.

Continue learning: ADR — decisions and consequences; Quality-attribute scenarios — testable criteria; Practice — responsibility boundaries; Anti-pattern — temporary integration without an exit decision. The latter two cover different cases but reinforce the distinction between responsibility and a verifiable condition.

Primary sources (checked 13 October 2026): Official ADR process guidance — context, decision, consequences, status and ownership; ADR process FAQ — responsibility for maintaining decisions; Public security and privacy control assessment methodology — planning and assessing control evidence. The six-field condition contract, A–C options and examples are original educational synthesis; these sources do not prescribe one mandatory architecture approval process for every organisation.