Skip to content
Domain 1
17%

Quick Reference: Domain 1 — Solution Design & Architecture

Translating Business Problems (1.1)

The professional sequence, in order: quantify the problem → capture constraints → define the success criterion → choose the solution shape. Inverting any pair produces designs that fit the technology rather than the problem.

  • Success criterion = metric + baseline + target, stated before the build. No criterion, no architecture — just a demo.
  • The fit test: language understanding, synthesis, or judgement over unstructured input → Claude. Fully rule-specified (tax, validation, thresholds) → deterministic code. Most real systems are hybrids; drawing the boundary is the architect's job.
  • Task shapes: classification, extraction, summarisation, generation, conversation, agentic action. Each implies its own architecture, validation, and evaluation.
  • Scope narrow first. Target the measured cost driver, prove value, expand. The general-purpose assistant with no baseline is a planted wrong answer.

The Six-Stage Pipeline (1.2)

Input → Context assembly → Processing → Output → Delivery → Feedback loops.

StageOwnsCommonly missing?
InputIngestion, validation, PII scrubbing (here, never later)—
Context assemblyRetrieval, memory, prompt construction—
ProcessingThe model call(s)—
OutputSchema validation + business-rule checks + guardrailsYes
DeliverySync / async / draft-for-review (a risk decision)—
FeedbackUser feedback, sampled evals, monitoring → iterationYes
  • Model output is untrusted until validated. Schema validity ≠ business validity.
  • Design for failure: timeouts, retries with backoff, idempotency, and an explicit degraded path. Silent failure is the one forbidden outcome.
  • Blast radius determines validation and review depth: wrong internal draft ≠ wrong customer refund.
  • "Quality is inconsistent and nobody knows why" = missing feedback loop, not a weak model.

Pattern Selection (1.3)

Three tiers: augmented LLM (one call + retrieval/tools/memory) → workflows (predefined code paths) → agents (model directs its own process). Escalate only when the simpler tier fails a named requirement.

PatternSelection cue
Prompt chainingFixed sequential subtasks; gates between steps
RoutingDistinct input categories handled separately
ParallelisationIndependent parts (sectioning) or confidence (voting)
Orchestrator-workersSubtasks unpredictable in advance
Evaluator-optimizerClear criteria + iteration measurably helps

The exam punishes over-engineering as hard as under-engineering. Fixed steps + audit requirement → workflow, never agent.

Multi-Agent Design (1.4)

  • Justified by: breadth-first parallel exploration, tasks exceeding one context window, distinct specialisms. Not by ambition.
  • Cost: agents ≈ 4× chat tokens; multi-agent ≈ 15×. The value case must clear the multiplier.
  • Subagents share no memory. No inherited conversation, no peer visibility. All context passes explicitly in the brief.
  • A complete brief: objective + output format (with claim–source fields) + tool guidance + scope boundaries.
  • Failure signatures: duplication + gaps = unpartitioned coordinator decomposition. Fix the briefs, not the agent count or model size.
  • Long runs need: checkpointed state (resume, not restart) and per-agent decision observability.

Decomposition (1.5)

  • Fixed (design-time pipeline) when steps are known; dynamic (orchestrator/agent) when structure emerges during the work.
  • Four axes: by stage, by section, by perspective, by specialism.
  • Attention dilution: one pass over too much material → inconsistent depth, contradictory judgements on identical patterns. Fix = per-unit local passes + a cross-unit integration pass. Both halves mandatory. A bigger context window is the planted distractor — it solves fit, not attention.
  • Interfaces: structured intermediate outputs (schemas with source locations) + acceptance gates between stages. Prose interfaces lose attribution and testability.
  • Don't decompose a task that fits one call with no dilution symptoms; every split adds latency, cost, and error surface.

Business Value Pillars (1.6)

Efficiency · Transformation · Productivity · Cost · Performance SLAs

  • Efficiency vs transformation discriminator: did the capability already exist? Faster existing process = efficiency. Newly possible = transformation.
  • Productivity attaches to people assisted, not processes automated away.
  • Model selection = per-task cost/performance decision against your own benchmarks; smallest model that meets the bar.
  • Prompt caching: ~90% off cache reads + lower time-to-first-token. Serves cost AND latency SLA. Request-path lever.
  • Batch processing: ~50% off asynchronous volume. Off-path lever. Distractors swap the two.
  • SLA engineering: decompose p95 into per-stage budgets (a chain that doesn't sum inside the target changes); availability targets force designed fallbacks; quality SLAs need evaluation machinery.
  • Value case: baseline before build; hypothesis (pillar, metric, target, measurement) stated up front and verified after.