TLDR
Every architectural choice - pattern, model tier, guardrail overhead - has to trace back to a named business-value pillar an executive sponsor recognizes: efficiency, transformation, productivity, cost, or performance SLAs. Anthropic's enterprise guidance frames system sophistication as NOT the goal - measurable outcomes are. The exam trap is a technically elegant architecture with no stated pillar justification.
What it is
The exam names five value pillars an architecture decision should map to: efficiency (cutting time/cost on existing work), transformation (a genuinely new capability, not just a faster old process), productivity (more work handled by the same team), cost (spend versus the baseline it replaces), and performance SLAs (a named latency/accuracy target the business depends on). This exact five-pillar wording doesn't appear verbatim in a single published Anthropic taxonomy - treat it as the exam's own synthesis of standard enterprise-value categories, grounded in real Anthropic guidance on outcome-anchored, trusted AI adoption rather than a direct quote.
The architect's job is to name which pillar (or pillars) each design decision serves, not to assume that a better-performing system is automatically better-value. Anthropic's guidance ties cost discipline directly to complexity: "Start with the simplest solution possible, and only increase complexity when needed" - unjustified architectural complexity is itself a cost-pillar violation, not merely a technical inefficiency.
How it works
Efficiency and productivity are related but distinct: efficiency asks whether an existing unit of work now costs less time or money, while productivity asks whether the team can now handle more volume with the same headcount. A workflow that replaces a manual triage step is an efficiency win; a batch pipeline that lets one team clear ten times the document volume is a productivity win - a single architecture can claim both if it earns them.
Cost is the pillar most often left implicit. Model tier, workflow-vs-agent choice, and guardrail overhead are all cost decisions in disguise - picking Opus "for quality" without stating which pillar justifies the added spend is the textbook exam trap. The fix is a stated cost ceiling per unit of work, compared explicitly against the labor or system cost it replaces.
Performance SLAs connect the architecture's technical configuration (model tier, retry/guardrail depth, context size) directly to a number the business depends on - e.g. "95% of triage decisions returned within 30 seconds." An architecture with no stated SLA has left this pillar unaddressed, which the exam treats as a gap, not a neutral omission.
Transformation is the pillar most often confused with efficiency. Doing the same manual process faster is only efficiency; surfacing a capability that did not exist before - a new fraud-pattern signal, a previously invisible exception trend - is transformation. An architecture that just automates an existing script one-for-one should not claim transformation.
Trust as a precondition, not a sixth pillar. Anthropic's enterprise guidance on "Building trusted AI in the enterprise" frames trust (safety, reliability, security) as necessary for realizing value at scale: an architecture that is fast and cheap but not trusted by stakeholders won't achieve adoption-driven value regardless of its technical merits. Naming a pillar without addressing trust is an incomplete justification.
Presenting a technically elegant architecture without tying any design decision back to a named business-value pillar - e.g. picking a larger model "for quality" without stating which pillar (an SLA target, or a transformation capability) justifies the added cost. The exam rewards explicit, named justification, not an implicit assumption that better-performing is automatically better-value.
Where you'll see it
Loan-document exception triage
Efficiency (less manual triage time), cost (per-document spend under the labor cost it replaces), SLA (95% of decisions in under 30 seconds), and transformation if it surfaces exception patterns no human previously tracked.
Support ticket deflection
Efficiency (faster resolution) and cost (cheaper than added headcount) and SLA (response-time target) - but not transformation if it's just automating an existing decision script one-for-one.
Side-by-side
| Pillar | What it measures | Example architecture decision | Anti-pattern |
|---|---|---|---|
| Efficiency | Time/cost per unit of existing work | A routing workflow instead of an open-ended agent for a fixed-path task | Adding agentic autonomy where the task doesn't need it |
| Productivity | Volume of work the team can now handle | A batch pipeline for high-volume classification | Leaving manual review in the loop for high-volume, low-risk decisions |
| Cost | Spend versus the baseline it replaces | A Haiku-tier model for straightforward extraction, with a stated cost ceiling | Defaulting to the largest model "for quality" with no stated ceiling |
| Performance SLA | A named latency/accuracy target the business depends on | "95% of triage decisions returned within 30 seconds" | No stated SLA - "fast enough" left undefined |
| Transformation | A capability that did not exist before | Surfacing an exception pattern no human previously tracked | Rebuilding an existing manual process one-for-one with no new capability |
Question patterns
6 V2 questions wired to this concept. Tap an answer to check it instantly - you'll see whether it's right and why - then expand the full breakdown for the mental model and all four rationales.
A subscription company has agreed on the goal "cut new-customer onboarding time from two days to four hours without increasing manual review errors." Which design artifact best preserves that intent as the Claude solution is specified?
Frequently asked
Showing 2 of 2 questions