Quick Reference: Domain 1 — Solution Design & Architecture

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

• Success criterion = metric + baseline + target, stated before the build. Without a criterion, there is no architecture, only a demo.
• The fit test (whether to use a model): language understanding, synthesis, or judgement over unstructured input → Claude. Fully rule-specified (tax, validation, thresholds) → deterministic code. Most real systems use both. The architect decides which parts use Claude and which use deterministic code.
• Task shapes: classification, extraction, summarisation, generation, conversation, agentic action. Each implies its own architecture, validation, and evaluation.
• Scope narrow first. Start with the cause of cost that you measured, prove value, expand. The general-purpose assistant with no baseline is a wrong answer.

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

• Model output is untrusted until validated. Output that matches the schema can still break business rules.
• Design for failure: timeouts, retries with backoff, idempotency, and an explicit degraded path (a defined response for when a failure happens). Silent failure is the one forbidden outcome.
• Blast radius determines validation and review depth: a wrong internal draft does less harm than a wrong customer refund.
• "Quality is inconsistent and nobody knows why" = missing feedback loop, not a weak model.

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.

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

• 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 business value must justify the multiplied token cost.
• Subagents start fresh. A non-fork subagent inherits no conversation and sees no peer findings. All context is passed explicitly in the brief (the instructions that the subagent receives). Current docs (October 2026): a fork inherits the parent conversation; SendMessage lets a subagent message named agents.
• A complete brief: objective + output format (with fields that link each claim to its source) + tool guidance + scope boundaries.
• Signs of failure: duplication + gaps = the coordinator divided the work, but not into separate parts that cover all of it. Fix the briefs, not the agent count or model size.
• Long runs need: checkpointed state (resume, not restart) and a way to see the decisions of each agent.

• 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 tempting wrong answer — it lets the material fit in the window, but it does not fix the attention problem.
• 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 more places where errors can happen.

Efficiency · Transformation · Productivity · Cost · Performance SLAs

• Efficiency or transformation: did the capability already exist? Faster existing process = efficiency. Newly possible = transformation.
• Productivity applies to people who are assisted, not to processes that are automated.
• Model selection = per-task cost/performance decision against your own benchmarks; smallest model that meets the required quality.
• Prompt caching: at least 90% off cache reads + lower time-to-first-token. Reads cost 0.1× base input price on most models (checked 13 November 2026). Opus 5.5 and Sonnet 5.5 read at 0.05×, and Fable 5.2, Mythos 5.2, Fable 5.1 and Mythos 5.1 read at 0.025×. Serves cost AND latency SLA. A cost-saving method for the request path.
• Batch processing: ~50% off asynchronous volume. A cost-saving method for work outside the request path. Wrong options confuse the two.
• SLA engineering: decompose p95 into per-stage budgets. A chain whose stage times, added together, do not fit inside the target is redesigned. Availability targets force designed fallbacks. Quality SLAs need evaluation tools.
• Value case: baseline before build; hypothesis (pillar, metric, target, measurement) stated at the start and verified after.