A discovery call is a structured elicitation, not a conversation

You know how to evaluate the pattern, the deployment platform, and the control posture. Discovery reveals whether you are solving the right problem. A stakeholder will usually describe the problem in business terms. Your job is to listen to what the business is trying to achieve, identify the constraints hidden inside that description, and leave the call with a record the design can follow.

A discovery conversation functions as a three-step filter: listen, translate, and write down.

1. 1First, listen to the business goal in plain language and pay attention to the meaning behind the word. Stakeholders usually describe the outcome they want but not the constraint you need to design for.
2. 2Second, translate that into requirements, assumptions, and unresolved constraints. This allows you to see what the design must support, what still needs confirmation, and what could block the solution later.
3. 3Third, write those items down before the conversation moves on. The design needs a clear record to follow. Without that filter, the design inherits your assumptions. The mismatch may not be revealed until much later, when changing trajectory is slower, harder, and more expensive.

The most important skill in discovery is translation. Stakeholders usually speak in preferences, but design decisions are made against constraints. Imagine a stakeholder says, "We want this to feel seamless." If you write down "seamless" as the requirement, you have not learned enough to design anything yet. You only have the stakeholder's summary of the experience they want.

The real work starts with the next question: what would make it feel not seamless? That is where the hidden constraints begin to appear. Maybe the user should never wait more than a second or two for the next step. Maybe they should not have to re-enter information that already exists upstream. Maybe exceptions should move quietly to a human reviewer instead of exposing a technical error. Maybe the workflow must stay inside one application, so the user never has to jump between tools. Each answer sharpens the design.

That exchange transforms "seamless" into requirements the architecture must support: a latency target, an integration requirement, a handoff rule, and a safe failure path. The stakeholder names the outcome in business language. You turn it into something the system can build and be measured against.

The preference sits on the top level, and the constraint sits underneath it. When a stakeholder gives you an experience word like seamless, easy, fast, simple, or intuitive, treat it as a signal that more discovery is needed. Ask what would break that experience, what the user must never notice, what has to happen behind the scenes, and what must still be true when something goes wrong. Those answers are what belong in the design record.

A testable, bounded constraint is what the design can be built against. A stakeholder preference tells you where to investigate, while the follow-up questions produce the constraint itself.

Discovery works best when you force a vague stakeholder statement into the four buckets below. A statement like "we want this to feel seamless" is not yet something you can design against. It usually hides one or more specific answers. Investigate the following:

• 1What the system must do. These are the capabilities the deployment must deliver, expressed as business outcomes rather than features. This is where you separate the work Claude owns from the work that remains with an existing system or a human.
• 2What the system must not do. These are the boundaries, prohibited actions, and cases that must route to a human. Stakeholders rarely volunteer these, so you must ask for them explicitly.
• 3What must the system cost. This is the budget constraint, expressed in terms the stakeholder controls. A latency target, a per-interaction cost ceiling, or a volume forecast should all be taken into account here. These become crucial design constraints.
• 4What the system must prove. This is the evidence that the deployment must be able to produce something of value. In regulated workflows, proof obligations are part of the requirement set. Identifying them in discovery is far cheaper than during a legal review weeks later.

"Seamless" may really mean a latency budget the user should not notice, a handoff that should not interrupt the flow, or a failure state that must not expose system internals. Once you discover those answers, you have requirements the team can design for, test, and defend.

Each item found in discovery becomes one row in a translation table. The row captures the stakeholder statement as it was said, the constraint it implies, the architectural decision that constraint forces, and any assumption you are documenting when the constraint has not yet been confirmed. One row per item keeps the reasoning intact as the work moves from discovery into design, and it keeps assumptions top of mind.

The discovery call that turned into a design session

In the exchange below, the Architect hears two stakeholder statements and begins proposing a solution. The stakeholder confirms the initial proposal because it sounds competent. The constraints that would have ruled out that architecture are never identified. They emerge two weeks later during a compliance review. This section shows exactly where the question that would have caught each constraint belonged. Use this example to learn to recognize the pattern in your own calls.

The "quick check" was not a convenience feature. The nursing workflow required a licensed clinician to authorize any model output before it reached the patient record. This made human authorization a required architectural gate as opposed to an optional addition. The dictation contained protected health information. Protected health information moved through the context window without the handling that the workflow required. The network spanned two states with different record-retention rules, and the single-region design never accounted for either. None of these requirements were unusual or hard to find. Each would have come out of a direct question in the must-prove and must-not-do categories, had the call not moved to sketching before those questions were asked.

Checkpoint: find the undocumented assumption

Present a tradeoff so the stakeholder can act on it, and design a demo that advances the deal

Discovery told you what the buyer needs. Turning those requirements into a decision a stakeholder can make is the next work.

The Architect is now helping the stakeholder understand the tradeoff, see the business consequences, and approve a path forward with confidence.

Your job is to describe the options clearly enough that the stakeholder can make an informed choice.

Every meaningful design decision has a tradeoff. One option may reduce cost or complexity but increase latency, risk, or compliance burden. Another may improve the user experience or scale better but require more effort upfront. If you present only the conclusion, the decision may look clear, but it is weak. When the downside appears later, the stakeholder may feel they approved of a recommendation without understanding what came with it. So, use a simple decision frame:

• 1What do we gain?
• 2What do we give up?
• 3What happens if we choose this now but have to reverse it later?
• 4In regulated environments, what does this do to our compliance posture?

That third question is the one most people skip, and it is often the one that changes the meeting. It turns the discussion from "what is the better technical answer?" into "what is the better business choice?"

Technical precision is necessary, but it is not sufficient. In architecture reviews, the recommendation is often technically correct but still not understandable to the person who must approve it. The Architect may explain the options in technical vocabulary (i.e. latency, logging depth, context size, retrieval pattern, deployment route) but the executive is asking a simpler question: "What happens to the business if we make the wrong choice?" At that point, the room does not need more detail, what it needs is translation into something a person can understand. When you do this well, the stakeholder is not just hearing your recommendation. They are making an informed decision they can defend later.

Present the decision as a package the stakeholder can act on: the options you considered, the criteria you weighed them against, your recommendation, and the risks that remain. The stakeholder is not adopting your architecture; they are accepting a decision they will have to defend to their own leadership.

Description is one of the four AI Fluency competencies: communicating effectively with AI. Extended to the stakeholder side of the work, the same discipline means telling the audience precisely what they need, in terms they can understand. Applied to stakeholder communication, Description means framing the system's behavior, its limits, and the oversight around it in the stakeholder's goal term. The framing should match their AI familiarity without sacrificing accuracy. Three rules apply in practice: lead with the business outcome rather than the architecture; frame limitations honestly, since a security stakeholder trusts a system whose limits are clearly stated; and anticipate the peer-proof demand, since the stakeholder will need to justify the choice to others and should leave the conversation with that justification in hand.

The map exists to help the stakeholder see the consequence of their choice clearly enough to decide.

Picture the buyer meeting where discovery went well. The team aligned on the problem, the use case, and the value at stake. Then the demo begins. Instead of showing the buyer's world, it shows a polished but generic set of features. The reaction is usually polite, that the demo was interesting, but not quite what they envisioned.

A weak demo can make the buyer question whether the team understood the core problem. This happens when teams confuse two different jobs. A capabilities demo answers, "What can this system do?" A scenario-specific demo answers, "What does this system do with my problem, my workflow, and my constraints?"

The first creates interest; only the second creates confidence. Design proof that the solution fits the buyer's context is part of the demo's job. A well-designed demo advances the opportunity while a weak one can undo the trust discovery built.

Before building any screens, make four design decisions. Those decisions determine whether the demo feels tailored and credible or generic and easy to dismiss.

Of the four demo-design decisions, limit placement is the one that most often runs against instinct. In practice, naming a weakness can feel risky, so the temptation is to hide it or soften it. This usually backfires.

Imagine the moment where the buyer asks, "What does this not handle well?" If the answer is vague, confidence drops. If the answer is clear and scoped, the buyer sees discipline instead of defensiveness.

That is why you should decide in advance which one or two constraints you will name and how you will frame them. Show that the boundary is deliberate, that this is what the solution is built to do, and this is what it is not built to do.

This matters even more in regulated industries such as healthcare, financial services, and the public sector. In those settings, a clear boundary often signals rigor, while a deflection signals risk.

A simple way to prepare is to ask:

• What is the limit?
• Why does it exist?
• What happens if the use case needs to go beyond it?

That same discipline carries directly into joint scoping with the Applied AI team. A good scoping session is not a place to figure out the basics for the first time. It is a place to refine choices, test assumptions, and resolve the questions that need specialist input.

If the demo proves you understand the buyer's problem, the scoping session proves you are ready to shape a credible solution around it. That only works if you arrive with three things prepared:

• A documented view of the customer's requirements and constraints. This captures what came out of discovery: the use case, workflow, stakeholders, data conditions, technical environment, compliance concerns, and success criteria. This gives the session a shared starting point.
• A proposed pattern or small set of candidate patterns, with tradeoffs already named. Walk in with a point of view. Show the likely options, what each gives you, what each gives up, and where the risks sit.
• A short list of open questions the Applied AI team is best positioned to answer. These are the questions worth spending the session on: model behavior, architecture implications, scaling constraints, evaluation approach, safety considerations, or pattern fit.

In the demo, you earn trust by identifying limitations clearly. In joint scoping, you keep that trust by bringing a structured view of the problem, the options, and the unanswered questions.

Technical objections in a sales cycle usually fall into three categories. Capability objections ask whether the system can do the thing at all. Governance and compliance objections ask whether the deployment can be trusted, controlled, and evidenced in a way the buyer can defend. Design-choice objections ask why you made this choice instead of another. Those require more than just justification. You need to explain the tradeoff the choice makes and what the alternative would have cost, using the same translation structure you used when you presented the tradeoff in the first place.

The go-to-market engagement map should treat demo design as a tracked workstream. That is why it includes a demo-design column with scenario, identified limitations, confirmed data source, and sales-team sign-off as explicit deliverables. This matters most when a partner is running parallel opportunities or when Architects hand off mid-cycle, because continuity depends crucially on what is documented.

The approval that was not an informed choice

The Architect presented a context-strategy tradeoff in technical terms. The CTO asked one question about cost, the Architect answered it accurately, and the CTO approved. Six weeks later the higher per-call cost appeared in the production invoice. This is the exchange, and then the note the CTO wrote when the bill was received. It shows where the presentation answered the wrong version of the question.

The presentation named what the design gained, simplicity, and it answered the per-call cost as asked. What it never identified was the third element: what happens to the business when this choice meets production volume and must be reversed after the system is built around it. The CTO approved a per-call number, not a monthly bill, and not the cost of unwinding a decision later. Two parts of the tradeoff were clearly communicated and understood. The third was not, and it turned out to be the load-bearing one.

Checkpoint: recommend the option and name the missing element

The feedback loop decides which signals reach a stakeholder, and the SLA names what you owe when one breaks

Production observability and the audit trail record what a live deployment is doing. This topic covers filtering those signals, deciding when to escalate beyond the team, and defining what the SLA requires when performance falls below standard. The system is live; keeping it trustworthy over time what takes effort. In lifecycle terms, the feedback loop is the monitoring-and-iteration stage of the deployment lifecycle.

Imagine a customer support assistant that is launched in solid shape. It answers quickly, stays in a tone, and handles the most common questions well. First, everything looks stable. But over time, usage patterns change, new prompt styles appear, and customer issues become more complex. Some responses merely slow down, and some answers start missing the mark entirely.

Nothing breaks dramatically, which is what makes drift hard to catch. Quality erodes gradually rather than all at once. A team without a feedback loop may not see the decline until users already feel it.

Observability gives you the raw material: latency, error rates, eval scores, usage patterns, and other signals from the system. But a signal by itself is not yet a decision. One spike may be noise. Another may point to a real problem. A third may be important only if it keeps happening.

The feedback loop sits on top of observability to answer five questions:

Signals → Triage → Decide → Act → Review

• 1Signals: What is the system showing us?
• 2Triage: What needs attention now, and what can wait?
• 3Decide: Does the issue need a team fix, a stakeholder review, or no action?
• 4Act: What correction, guardrail update, or escalation is required?
• 5Review: Did the response work and does the rule need to change?

Think of it like a control room in a train station. The sensors can tell you where the trains are late, but someone still must decide whether a delay is minor, whether passengers need to be informed, and whether the schedule needs to change. That judgment layer is what makes the system manageable instead of just measurable.

Once the feedback loop decides that something matters, the SLA defines what happens when it crosses the line. An SLA is a commitment that makes three things clear:

• 1What are we measuring?
• 2What counts as a breach?
• 3What happens when a breach occurs?

The threshold should never be arbitrary. It should trace back to something tangible:

• 1Latency should reflect the user experience expectation identified earlier
• 2Availability should reflect how critical the deployment is to the business
• 3Quality should reflect the eval results and acceptance criteria already established

That traceability matters because it keeps the SLA defensible. If the number cannot be tied to one of those sources, it is probably just a target someone chose because it sounded reasonable.

Cost is the expectation that breaks most often after launch. Production volume routinely runs one to two orders of magnitude above the pilot, so a cost that looked trivial in the proof of concept becomes a five-figure monthly line at scale. Pre-empt it: give the stakeholder a consumption forecast at expected production volume, name the spend-control posture (caching, model tiering, budget alerts), and frame the model-tiering narrative before the first invoice rather than after it.

Observability records what happened; the feedback loop determines what to do about it. In regulated deployments, some reviews must happen even when nothing has gone wrong. A healthcare workflow with a documentation obligation may require periodic output audits on a defined schedule. A data-residency deployment may need scheduled confirmation that the environment still meets residency rules. These are design-time obligations rather than tasks to be added later. If they are not built early, they become far more expensive to establish when someone asks for proof.

Build a governance table that maps each signal to its trigger, the Architect's response, and any regulatory checkpoint. The table should exist before launch. It is the mechanism that turns policy into an operating routine.

The observability stack that replaced the feedback loop

The excerpt below places a deployment alert log next to its stakeholder review calendar over a ninety-day window. The alert log shows a sustained drift in output quality across weeks four through seven. The review calendar shows no review that happened in that window. A single row in a feedback-loop governance table would have connected the two. This shows what the gap looks like in the record.

Every metric the deployment needed was already being collected. The eval score was visibly drifting downward since week four. What was missing was the decision layer: no governance rule mapped a slow quality drift to a review trigger. The drift never crossed an error-rate threshold, so no alert fired. A drift with no trigger is invisible until a human happens to notice. The stack was measuring the right thing and telling no one it mattered.

Checkpoint: triage the production signals

Documentation that survives your absence serves the handoff recipient, the auditor, and the returning Architect

The feedback loop keeps the system healthy while you are running it. Documentation is what keeps it functioning after you are gone. This topic turns the full design into documentation that outlives a handoff and satisfies a compliance reviewer. Either the design carries its own reasoning into that handoff, or that reasoning disappears the moment you leave. In lifecycle terms, documentation is the handoff stage of the deployment lifecycle.

Architecture documentation serves three readers. The inheriting engineer takes over a deployment they had no part in building. The auditor arrives later, looking for evidence that a specific control is live and accounted for. The returning architect, often you, comes back months later with no memory of the design sessions. A document built for one of these readers and not the others is incomplete even when it is detailed.

For whoever inherits the system, the document must carry the decisions that were made, the alternatives that were rejected, and the reason each rejection happened. A design delivered without its rejected alternatives cannot be understood by someone who was not in the room. They will reverse the right decision for the wrong reason or defend the wrong decision because they cannot tell which tradeoff it was resolving. The rejected options explain why the design is shaped the way it is.

For the compliance reviewer, the document must carry each regulatory obligation, the technical control that satisfies it, the owner of that control, and the evidence artifact that demonstrates the control is operating. This is the regulated deployment control register, carried forward into the living document that governs the deployment's production life. The reviewer does not accept mere assertions. They require evidence, which means that a statement that control exists is not enough on its own.

For the Architect who returns months later, the document must stand on its own. Decisions are dated. Assumptions are explicitly labeled as assumptions rather than embedded as facts. Open items have owners and resolution criteria. The test is practical: after reading the document, can a competent Architect who was not present at the design sessions make a safe change to the system? If the answer is no, the document is not complete.

The design rationale that lived in the Architect's head

In this case, the original Architect left a mid-sized financial-services engagement twelve weeks after launch. Their replacement inherited a thorough architecture diagram with no rationale attached. A performance issue prompted a proposal to switch context strategies, the replacement made the switch, and it reintroduced a data-handling pattern that violated the deployment's data-residency constraint. The postmortem traces the failure to the one row that was missing. This is what that looks like in the record.

The replacement was competent and acted reasonably on the information they had. The diagram told them what the system was, not why it was that way. The original context strategy was a deliberate choice to satisfy a residency constraint, and that reasoning was never written as a decision with a named tradeoff and a rejected alternative. With no rationale documented, the replacement could not tell that the strategy they were changing was load-bearing for compliance, so they reversed the right decision for an understandable wrong reason.

Checkpoint: place the documentation artifacts

Entry point selection returns with the full production picture, and the outcome document turns the work into reusable IP

This topic covers how the deployment was routed and what it produced, turning the work into partner IP that survives the engagement. Entry point selection returns here with the full production picture in view.

The earlier module introduced route selection as an entry-point-and-compliance pre-filter: the direct Anthropic API, AWS Bedrock, GCP Vertex AI, and Microsoft Foundry each serve different partner procurement postures and regional compliance requirements. This topic returns to that decision with the full production context. The question is no longer which route survives the compliance pre-filter. It is which route performs best across the latency, cost, and compliance dimensions of a live multi-platform deployment. Because entry-point capabilities change, every specific claim in this section is re-verified against platform.claude.com/docs and anthropic.com at build time.

A deployment that spans more than one entry point exposes a class of problems a single-entry-point system does not. Model identifier strings differ across routes. Feature availability can lag on a route mediated by a cloud service provider relative to the direct API. Regional availability on Bedrock and Vertex requires explicit configuration, and defaulting to a global endpoint is the common pattern that breaks a data-residency requirement. An Architect designing across entry points needs a documented entry-point-responsibility map before writing the first line of integration code.

An app that integrates multiple Claude entry-points in one workflow requires you to specify which entry-point handles which task and the reason. A workflow that uses the API for back-end inference, Claude Code for an engineering sub-task, and a Bedrock endpoint for a regulated data path is not unusual at enterprise scale. Each entry-point boundary is an integration point with its own authentication, logging, and failure-mode profile. The entry-point-responsibility map makes those boundaries explicit and prevents the most common multi-entry-point failure: an entry-point chosen for one task gradually taking on another because the routing logic was never documented.

Customer outcome documentation is the artifact that makes the deployment's value understandable to people who were not on the build. A well-structured outcome document covers six fields: the use case and its scope boundary, the metric before deployment, the metric after deployment, the control that makes the result auditable, the owner responsible for ongoing measurement, and the potential to reuse the pattern for other customers or engagements. The technical metrics alone do not make this document. The before-and-after business outcomes and the reuse notes are what turn it into a reusable asset.

The outcome document that measured the wrong thing

Volume, latency, and error rate are real and worth tracking, but none of them are a business outcome. The fields that would have made the document usable for the CFO conversation were the before-and-after on the business metric the use case targeted, claims-processing time, and the control that made that comparison auditable. Without the before number, there is no story. Without control, the after number is an assertion. The document was complete as a technical record and useless as a case for expansion.

Checkpoint: pick the platform and the required outcome fields

Cumulative: architect a regulated multi-platform deployment end to end

Glossary

The key terms used across this module, in alphabetical order. Click a term to expand its definition.

Recap: five things that hold across everything here

Sources

• Building with the Claude API (Skilljar): stateless request lifecycle, system prompts, evals and graders, tool use, RAG, prompt caching, code execution.
• Claude 101 (Skilljar): general Claude capabilities and everyday-use framing. (Claude 101 does not carry model-family or context-window teaching per the live catalog; those concepts trace to platform documentation; verify the current model lineup at publish time.)
• AI Capabilities and Limitations (Skilljar): the four-properties decision lens carried forward from earlier modules.
• platform.claude.com/docs: model names, platform capabilities, route availability, residency configuration. Re-verify at build.
• anthropic.com partner program documentation: partner GTM stage definitions, IP-contribution protocols.
• Anthropic Applied AI team documentation: joint-scoping engagement structure and preparation inputs.

Congratulations! You have successfully completed this module.

Module 4 covers the stakeholder communication, lifecycle governance, and go-to-market decisions that turn a working AI deployment into a defensible, scalable business asset.

The deployment is only as durable as the documentation, governance, and outcome evidence that surrounds it.