Domain 4 — Workflow Integration and Solution Design

CCA Associate Foundations course · Page 5 of 10 · ← Back to all courses · Weight: 16% — the second-heaviest domain. Mark this page complete at the bottom to advance your course progress.

4.1 — Requirements Analysis: Discover Before You Design · Core

Every discovery session must capture four categories:

1. What it must do — business outcomes Claude owns
2. What it must NOT do — boundaries, human-escalation triggers (stakeholders almost never volunteer this one — ask explicitly: "what should Claude never decide on its own?")
3. What it must cost — latency budget, per-interaction cost ceiling, volume forecast
4. What it must prove — audit/evidence obligations in regulated work

Five outputs must exist before any design work starts: a measurable problem statement, a constraint inventory, a data access map, a stakeholder map with named decision owners, and a current-process baseline. That baseline has no retroactive fix — capture it before deployment, or an improvement claim later has no starting point to compare against.

Experience words are a signal, not a requirement. "Seamless," "easy," "fast" mean more discovery is needed — ask "what would make it feel not seamless?" to surface the actual latency target, integration requirement, or handoff rule hiding behind the word. Never assume a specific number for a vague word.

Measurable vs. vague: "Improve customer satisfaction" cannot be evaluated. "Increase CSAT from 72 to 85 within 6 months" can.

4.2 — Spotting a Genuine AI Automation Opportunity · Core

Strong candidates have clear, consistent inputs, well-defined outputs, and steps that can be precisely described and verified. Workflows needing constant exception judgment outside any written policy are lower-feasibility until that judgment is scoped.

Attention dilution: passing too many items into one request (14+ files in a single review pass) produces uneven depth and self-contradiction across items. A bigger context window does not fix this — decomposition does (per-item passes + a separate integration pass).

The POC-to-production gap: a demo on 20–50 clean inputs hides four things production reveals — real cost distribution (a long tail of large requests can make an average-based cost model underestimate total spend by 2–3×), p95 latency under concurrent load, the need for retry logic, and edge-case input formats the demo never saw.

⚠ Often-missed — Building Before Discovery Is Complete · Gap

Starting to design or build before all five discovery outputs exist is a Foundations-level mistake, even when it looks like it saves time. Constraints not yet gathered (a HITL authorization requirement, a PHI handling rule) surface later — during compliance review or after launch — at exactly the point where changing direction is most expensive. A correction during discovery costs a conversation; the same correction after build costs weeks.

4.3 — Designing a Multi-Step Solution · Core

Three design questions, every time:

• How are tools connected? Direct API/SDK for a single application; MCP when the same capability must be reused across multiple surfaces ("build once, expose everywhere" — adding MCP with no reuse requirement is needless overhead).
• How is step order enforced? A prompt instruction ("always do Step 1 first") is probabilistic and has a documented non-zero failure rate. A programmatic prerequisite gate — code that checks Step 1's result is present and valid before Step 2 runs — is deterministic. Use the gate whenever the ordering has financial, safety, or compliance consequences; strengthening the prompt language ("MUST", "MANDATORY") does not close the gap.
• What happens when something breaks? Retry with exponential backoff around transient errors (429/5xx/timeouts); checkpoints after each major step so a crash resumes from the last completed step, not from zero.

A complete handoff to a human must include: customer ID, root-cause analysis, the relevant amounts, and a recommended next action — the handoff is the recipient's only context; they should never need to re-investigate from scratch.

4.4 — Communicating the Design to Stakeholders · Core

Every significant decision needs four elements — the reversal-cost question is the one most often skipped:

1. What do we gain?
2. What do we give up?
3. What does it cost to reverse this later if we're wrong?
4. What does this do to our compliance posture?

Translate every metric into business terms: "adds $0.008/request but lifts first-contact resolution 12 points," not "2× better benchmarks." Never commit to "always correct." Commit to a named accuracy figure on a defined eval set plus a remediation path for the error budget ("95% accuracy; the 5% error budget routes to human review").

Lifecycle order is fixed and non-negotiable: Discovery → Design → Build/Handoff → Monitoring → Iteration. A correction during discovery costs an hour; after build, weeks.

Exam reflexes for Domain 4

• Stakeholder says "seamless" / "easy" / "fast" → ask what would make it feel the opposite; don't assume a number.
• "What must the system NOT do" not yet asked → the category stakeholders never volunteer — ask explicitly.
• Design or build starts before all five discovery outputs exist → wrong, regardless of time pressure.
• "Must guarantee step ordering" (refund, compliance, safety) → programmatic gate, not a prompt instruction.
• Single application, no reuse need → direct API. Reused across multiple surfaces → MCP.
• Cost model built from average request size → check the long tail; averages underestimate skewed distributions.
• Missing current-process baseline before launch → no retroactive fix; improvement claim can't be verified.
• SLA commitment phrased as "always correct" → wrong; commit to a measured rate + remediation path.