6.1 Structured Discovery & Requirement Gathering

Picture the first call with a new client. They say, "We want a chatbot that handles customer support." If you're an eager architect, the temptation is almost physical: you already have three candidate designs in your head, you know which model tier you'd reach for, you can practically see the retrieval pipeline. It would feel productive to start sketching it right there on the call.

Resist that. "A chatbot that handles customer support" is not a requirement — it's a hint that a requirement exists somewhere underneath it. Does "handles" mean fully autonomous resolution, or drafting replies a human approves? Is this for a SaaS product with thousands of similar tickets, or a regulated bank with individually sensitive cases? Is a two-second response fine, or does the team need sub-second replies during a live chat? None of that is in the sentence they gave you, and every one of those answers changes the architecture. This is exactly the same discipline Domain 1 asks of you when extracting requirements for an agent's design — except now you're doing it live, with a person, who may not know which of their own assumptions are load-bearing.

So the rule for Task Statement 6.1 is simple to state and easy to skip under pressure: elicit the business OUTCOME first, and only then work through the constraints. "What does success look like six months from now?" comes before "what latency do you need?" The outcome is the anchor; without it, a constraint is just a number floating in space. Once the outcome is nailed down — say, "cut average ticket resolution time from six hours to twenty minutes without a drop in satisfaction scores" — every constraint you ask about next has something to be justified against.

Here's a pattern every architect learns the hard way: stakeholders are experts in their business and often novices in what an AI system needs to know about it. Ask an open-ended question — "anything else I should know?" — and you'll usually get silence, because they don't know which details are architecturally load-bearing. They're not hiding anything; they simply don't know that "our EU customers' data can't leave the EU" is a sentence that reshapes your entire deployment topology.

That's why discovery has to be STRUCTURED rather than open-ended. You don't wait for non-functional requirements to surface on their own — you ask for them directly, category by category. Four categories come up again and again and deserve a question each, every time: regulatory context (are there compliance regimes — HIPAA, GDPR, financial regulation — that constrain what the system can do or where data can go?), data residency (must data stay within a specific region or jurisdiction?), peak load (what does the busiest hour of the year look like, not the average hour?), and failure tolerance (if the system is wrong or unavailable for ten minutes, what actually happens downstream — an inconvenience, or a compliance breach?).

• •Regulatory context — "Is there a compliance regime that governs this data or decision?"
• •Data residency — "Does this data need to stay in a specific region or country?"
• •Peak load — "What does your busiest hour look like, not your average hour?"
• •Failure tolerance — "If this system is wrong, or down, for ten minutes — what actually happens?"

Notice what these four have in common: none of them is likely to appear in the stakeholder's original ask. "We want a chatbot that handles customer support" says nothing about data residency — until the deal involves a European bank, at which point it's the single most important sentence in the engagement. Structured discovery exists precisely to surface the requirements that matter but that nobody thought to mention.

A stakeholder will often hand you an implementation, not a requirement. "We want it built with a vector database and a RAG pipeline" sounds like a design decision, but underneath it there's usually a need — "answers should be grounded in our documentation, not hallucinated" — that could be served several different ways. The vector database is a WANT: a preferred implementation. The grounded-answer requirement is the NEED: the must-have outcome.

Why does the distinction matter enough to be its own discovery skill? Because if you silently accept every want as a hard requirement, you lose the room to make the right tradeoff later. Maybe a smaller, cheaper retrieval setup serves the actual need just as well; maybe the stakeholder's preferred implementation would, in this specific case, cost far more than it delivers. You can only have that conversation if you've kept the need visible underneath the want, instead of treating the stated implementation as gospel. Peeling back a want to find the need is not second-guessing the stakeholder — it's giving yourself, and them, more options.

Discovery doesn't end when you've asked all your questions — it ends when the stakeholder has confirmed you understood the answers. This last step is easy to skip because it feels redundant ("I already asked, why ask again?"), but reflecting requirements back and getting explicit confirmation is what turns a pile of notes into an agreed artifact. You're not asking the same questions twice; you're checking that what landed in your head matches what they meant.

In practice this is a short, plain-language summary: "So, to confirm — success means average resolution time under twenty minutes, all customer data has to stay in the EU, and if the system can't resolve a ticket confidently it should hand off to a human rather than guess. Did I get that right?" That one paragraph is doing enormous work. It catches misunderstandings while they're still cheap to fix — before a single line of architecture has been drawn — rather than three weeks into a build when someone finally says "wait, that's not what we meant."

The output of this confirmation step is the thing every later tradeoff conversation gets justified against: a shared, agreed statement of what success means. When you tell a stakeholder in Lesson 6.2 "we gain X, we pay Y," you're implicitly pointing back at this statement — X and Y only matter in relation to the outcome you both signed off on here. Skip the confirmation, and every later tradeoff conversation is arguing from a foundation neither side actually agreed to.

Everything in this lesson points at one failure mode, and the exam returns to it often: proposing a solution before discovery is complete. It usually shows up disguised as competence — a scenario where an architect, eager to demonstrate value, sketches an architecture in the first meeting, before the SLA, the data-sensitivity picture, or the real business outcome has been established.

Why is this specifically dangerous, rather than just a bit premature? Because you cannot justify a model choice, a protocol choice, or a governance choice without the constraints discovery was supposed to produce. If you don't yet know whether the data is regulated, you can't responsibly choose where it's processed. If you don't know the real SLA, you can't choose between a single fast model call and a multi-step agentic pipeline. A design proposed before discovery finishes isn't really a design — it's a guess wearing a design's clothes, and guesses are exactly what structured discovery exists to eliminate.

This is also a good moment to notice how much of Domain 6 chains together. The wants-vs-needs discipline from 6.1.3 gives Lesson 6.2 room to present real options rather than a single locked-in implementation. The agreed statement of success from 6.1.4 is what Lesson 6.3's SLA conversation gets measured against. Discovery isn't a box you tick before the interesting work starts — it's the foundation the rest of the domain stands on.

You now have the full discovery toolkit: outcome before constraints, structured questions for the requirements nobody volunteers, the wants/needs split, and reflect-and-confirm as the close. The fastest way to make this automatic is to run it once, deliberately, end to end.

With an agreed statement of success in hand, you're ready for the conversation that comes next: explaining the tradeoffs behind whatever design you propose, in language this specific stakeholder will actually understand. That's Lesson 6.2.