Domain 1: Solution Design & Architecture

Solution design terms: problem framing, e2e stages, patterns, multi-agent, decomposition, and value pillars.

• Business problem framing

  Translating a vague stakeholder ask into goals, constraints, owners, inputs/outputs, non-goals, and measurable success criteria before choosing models or integrations.

  Exam Refuse "AI on X" until outcomes and Claude-vs-code fit are explicit.

  See also: 1.1 Business → Claude solutions

• Claude fit vs deterministic software

  Use Claude for judgment-heavy language tasks (nuance, drafting, exception explanation); keep sorts, checksums, fixed field updates, and hard rule checks in code.

  Exam SQL sorts and Redis counters are not Claude-shaped jobs.

  See also: 1.1 Business → Claude solutions

• Non-goals

  Explicit statements of what the solution will not cover in this phase — critical to prevent scope sprawl after a vague AI ask.

  Exam Missing non-goals are a framing failure, not a prompt failure.

  See also: 1.1 Business → Claude solutions

• End-to-end stages

  The full Claude architecture path: input (intake) → processing → output (delivery) → feedback (outcomes that improve the system).

  Exam Diagrams that stop at "model responds" are incomplete.

  See also: 1.2 End-to-end architectures

• Feedback loop

  A path that captures corrections, failures, escalations, and outcome signals and feeds evals, prompts, retrieval, or ops — not only a thank-you UI.

  Exam Missing feedback in an otherwise complete intake→output path is a classic trap.

  See also: 1.2 End-to-end architectures

• HITL as architecture stage

  Human-in-the-loop review treated as an explicit processing/output stage when risk requires it, with handoff context — not a slide-deck afterthought.

  Exam HITL belongs on the diagram when irreversible or high-risk outputs are in scope.

  See also: 1.2 End-to-end architectures

• Workflow pattern

  Architectural pattern for fixed sequential steps with explicit gates and deterministic checks between stages.

  Exam Fixed claims/compliance gates favor workflow over open agentic loops.

  See also: 1.3 Architectural patterns

• Agentic pattern

  Architectural pattern for open-ended tool use and adaptive plans under a bounded toolkit, when the next step is not fully known upfront.

  Exam Match to unpredictability and tool exploration — not to buzzwords.

  See also: 1.3 Architectural patterns

• Augmented LLM

  Single-call (or short) generation pattern enhanced with retrieval or light tools — preferred when the task is mostly answer generation over a bounded corpus.

  Exam Prefer augmented LLM over multi-agent when simplicity meets the need.

  See also: 1.3 Architectural patterns

• Coordinator (hub-and-spoke)

  The orchestrating agent that owns decomposition, routing, aggregation, and visibility; specialists communicate through it with explicit handoffs.

  Exam Peer-to-peer specialist chatter that hides the coordinator fails exam items.

  See also: 1.4 Multi-agent orchestration

• Explicit context handoff

  Passing the facts, constraints, and artifacts a specialist needs in a structured contract — subagents do not inherit coordinator history or shared memory.

  Exam Assumed inherited memory is a multi-agent distractor.

  See also: 1.4 Multi-agent orchestration

• Adaptive decomposition

  Splitting work as structure is discovered (e.g., unknown codebases, open research) rather than locking a fixed pipeline before exploration.

  Exam Unknown legacy + open-ended goals favor adaptive splits.

  See also: 1.5 Decomposition techniques

• Coverage / synthesis criteria

  Explicit checklist of categories or acceptance tests used when re-merging specialist outputs so thin or missing areas are caught.

  Exam Thin coverage after good specialist work usually means a bad coordinator split.

  See also: 1.5 Decomposition techniques

• Business value pillars

  Named value dimensions for architecture alignment: efficiency, transformation, productivity, cost, and performance SLAs.

  Exam Answers should name the pillar and the measurable trade-off.

  See also: 1.6 Business value pillars

• Pillar–trade-off alignment

  Documenting which pillar a design choice serves, what was rejected, and how success will be measured — especially when cost/SLA conflict with marginal accuracy.

  Exam Ignore-SLA accuracy wins and mislabeled "transformation" fail.

  See also: 1.6 Business value pillars