From Brief to Design

The order matters

Under time pressure — an interview, a sprint — the temptation is to jump to a shape you recognise. That produces designs that are locally clever and globally wrong, because the shape was chosen before the problem was understood. A fixed order prevents it.

Clarify the requirements. Ask what is in scope and, more usefully, what is out. Write down the assumptions you are allowed to make.
Extract candidate entities. Underline the nouns. Do not filter yet.
Assign responsibilities. For each candidate, finish 'X is the only thing that knows ___.' Drop the ones that fail.
Draw relationships. For each pair that must interact, decide: owns, holds, references, or merely uses.
Find the variation points. Which requirement will change first? That is where a seam goes.
Name the patterns, if any apply. Only now, and only if a shape you already have matches one.
State the trade-offs. For each significant decision: what you chose, over what, and why.

Clarifying, concretely

Ask	Because the answer changes
Who uses this, and how many of them?	Whether concurrency is in scope at all
What must never be wrong?	Where invariants and validation live
What will change first?	Where the seams go
What is explicitly out of scope?	How much you are allowed to not build
Is there existing code this must fit?	Whether you are free to choose the shape

Five questions that reliably change the answer.

Justifying a design

A finished design has, for each significant decision, a sentence of the form: I chose A over B because C. If you cannot produce that sentence, either the decision was arbitrary — in which case take the simpler option — or you have not yet understood why you made it.

This is also the honest standard for reviewing someone else's design, including the AI reviewer in this track. "This is wrong" is not useful. "This couples the processor to a specific provider, so a second provider means editing the processor — was that deliberate?" is.