Free lesson · Claude Certified Architect - Foundations (CCA-F)
The Central Lens - Model Discretion Versus Deterministic Enforcement
One Question That Unlocks a Large Fraction of the Exam
If you internalise nothing else from this module, internalise this:
Every design decision on this exam is a decision about what to leave to the model's judgment and what to enforce deterministically outside the model.
That is the lens. It recurs in every domain, in every scenario archetype, and in a large share of individual items. A candidate who applies it consistently can reason through unfamiliar questions. A candidate who has memorised what each mechanism does, without the lens, has to guess when the question is phrased in an unfamiliar way.
The reason this lens is so productive is that it maps directly onto how production AI systems actually fail. Systems fail when something that needed to be guaranteed was merely requested.
The Distinction, Precisely
Interactive animation: One question routes every requirement - must it hold every single time - to discretion or to enforcement.
Model discretion means the outcome depends on the model's judgment at inference time. You describe what you want, and the model decides how - or whether - to comply. Prompts, system prompts, tool descriptions, and instruction files all operate here.
Deterministic enforcement means the outcome is guaranteed by code that runs regardless of what the model decides. Schemas that reject invalid output, permission rules that block a tool call, hooks that fire on an event, and validation gates in your orchestration layer all operate here.
The difference is not reliability in a vague sense. It is categorical. A well-written instruction is followed most of the time. A permission deny rule is followed every time, because the model is not the thing making the decision.
graph TD
A[A requirement] --> B{Must it hold<br/>every single time?}
B -->|Yes| C[Deterministic enforcement<br/>Outside the model]
B -->|No, usually is enough| D[Model discretion<br/>Instruction or description]
C --> C1[Schema validation]
C --> C2[Permission rules]
C --> C3[Hooks]
C --> C4[Orchestration-layer gates]
D --> D1[System prompt]
D --> D2[Instruction files]
D --> D3[Tool descriptions]
This diagram presents the central decision as a branch. A requirement enters and meets the question: must it hold every single time? A yes answer routes to deterministic enforcement outside the model, which expands into schema validation, permission rules, hooks, and orchestration-layer gates. A no answer, meaning usually is good enough, routes to model discretion, which expands into system prompts, instruction files, and tool descriptions.
The question in the middle of that diagram - must it hold every single time? - is the one to ask on every design question you meet.
The Enforcement Ladder
Mechanisms are not binary. They sit on a spectrum from pure suggestion to hard guarantee, and part of architectural skill is choosing the lowest rung that actually satisfies the requirement.
| Rung | Mechanism | Guarantee level | Cost of using it |
|---|---|---|---|
| 1 | Prompt or instruction text | Suggestion | Nearly free, easy to change |
| 2 | Tool description and schema constraints | Strong nudge; invalid inputs rejected | Low; requires schema design |
| 3 | Structured output schema with validation | Output shape guaranteed | Low; constrains flexibility |
| 4 | Permission rules | Action blocked | Moderate; can block legitimate work |
| 5 | Hooks on lifecycle events | Code runs regardless of model choice | Moderate; adds operational surface |
| 6 | Orchestration-layer gates and validation code | Full control | Highest; most code to maintain |
graph LR
A[Rung 1<br/>Instruction] --> B[Rung 2<br/>Schema constraint]
B --> C[Rung 3<br/>Output validation]
C --> D[Rung 4<br/>Permissions]
D --> E[Rung 5<br/>Hooks]
E --> F[Rung 6<br/>Orchestration code]
A -.->|Weaker guarantee<br/>Lower cost| A
F -.->|Stronger guarantee<br/>Higher cost| F
This diagram shows the enforcement ladder as a left-to-right progression through six rungs: instruction, schema constraint, output validation, permissions, hooks, and orchestration code. Annotations indicate that the leftmost end offers weaker guarantees at lower cost, while the rightmost end offers stronger guarantees at higher cost.
Two errors are possible here, and the exam tests both.
Under-enforcing means placing a must-hold requirement on rung 1 or 2. This is the more common error and the one the exam punishes hardest, because it produces systems that work in testing and fail in production.
Over-enforcing means climbing to rung 6 when rung 3 would have satisfied the requirement. This is the over-engineering trap covered in the next topic. It costs complexity, maintenance burden, and often flexibility the system needed.
Tip: The correct answer is usually the lowest rung that provides a genuine guarantee for the stated requirement. Not the lowest rung available, and not the strongest mechanism available - the lowest rung that actually guarantees what must be guaranteed.
Interactive animation: Under-enforcing puts a must-rule on rung 1 or 2; over-enforcing climbs to rung 6 when rung 3 would do.
How the Lens Appears in Each Domain
The same decision recurs in five different costumes. Recognising the costume is most of the work.
| Domain | The discretion option | The enforcement option |
|---|---|---|
| D1 - Agentic architecture | Instruct the agent to escalate when uncertain | Orchestration-layer gate that routes on a confidence threshold |
| D2 - Tools and MCP | Describe in the tool description which inputs are valid | Schema constraints and enums that reject invalid inputs |
| D3 - Claude Code | Add the team rule to an instruction file | A hook or a permission deny rule |
| D4 - Structured output | Ask the model to return JSON matching a shape | A schema-constrained tool definition plus validation on the way out |
| D5 - Context and reliability | Tell the model to preserve important facts when summarising | A persistent fact block held outside the summarisation path |
Read that table twice. Every row is the same decision. The mechanisms differ; the reasoning does not.
Important: The D3 row is the highest-frequency instance of this pattern on the exam. When a scenario says a rule must hold - no commits to a protected branch, no reads of a credentials file, formatting applied without exception - the answer is essentially never "document it in an instruction file." Instruction files shape default behaviour. They do not guarantee it.
A Worked Example
A scenario establishes the following: an engineering team uses Claude Code across a shared repository. Company policy prohibits any modification to files under a infra/production/ directory without a senior engineer's review. The team has documented this in their project instruction file. Violations have occurred anyway.
The question asks what to change.
Example: Applying the lens step by step.
Step 1 - Classify the requirement. "Prohibits any modification without review" is absolute language. This must hold every time. It belongs on the enforcement side, not the discretion side.
Step 2 - Diagnose the current design. The rule lives in an instruction file, which is rung 1. The team placed a must-hold requirement on a suggestion mechanism. The violations are not a model failure; they are an architecture failure.
Step 3 - Find the lowest rung with a genuine guarantee. A permission deny rule scoped to that path blocks the action at rung 4. A hook on the pre-tool-use event could also intercept and reject at rung 5. Both guarantee; the permission rule is simpler and involves no operational surface.
Step 4 - Check against the trap patterns. Is there a simpler adequate answer? Rewriting the instruction more emphatically is rung 1 and still does not guarantee. Is there an over-engineered answer? Building a custom orchestration service to mediate all file access is rung 6 for a requirement rung 4 satisfies.
Conclusion: the permission deny rule. Not because permissions are always right, but because it is the lowest rung that actually guarantees the stated absolute requirement.
The reasoning in that example transfers wholesale. Change the domain and the mechanisms change; the four steps do not.
Interactive animation: The infra/production/ rule lived in an instruction file; the lowest rung that guarantees it is a permission deny rule.
When Discretion Is Correct
The lens is not an argument that enforcement is always better. Over-applying enforcement produces brittle systems that cannot handle the variability they were built for, and the exam penalises that too.
Discretion is the right answer when:
- The requirement is a preference rather than a guarantee - style, tone, typical approach
- The correct behaviour genuinely depends on context that code cannot evaluate
- The cost of a wrong outcome is low and recoverable
- Enforcing it would block legitimate variation the system needs
An agent that must handle ambiguous customer requests needs discretion in how it interprets them. What it must not have discretion over is whether to escalate when a stated escalation condition is met. Those are different decisions and they get different mechanisms - which is precisely why "use discretion" and "use enforcement" are not competing philosophies but complementary tools applied per requirement.
Pros of deterministic enforcement:
- Guarantees hold regardless of model behaviour
- Failures are visible and debuggable in code
- Auditable for compliance and security requirements
- Behaviour does not drift as prompts or models change
Cons of deterministic enforcement:
- Adds code and operational surface to maintain
- Can block legitimate cases the rule did not anticipate
- Slower to change than an instruction
- Over-application produces brittle systems
Warning: Do not read this topic as "enforcement good, prompts bad." An exam option that wraps every decision in validation code is as wrong as one that leaves a security requirement to a prompt. The skill is matching the mechanism to the requirement, per requirement.
Carrying the Lens Forward
Every subsequent module in this course will explicitly re-invoke this lens. When you meet hooks in Module 11, the question will be when a hook is the right rung. When you meet nullable schema fields in Module 14, the question will be whether a schema can guarantee the model does not fabricate. When you meet escalation triggers in Module 16, the question will be whether the trigger is evaluated by the model or by your code.
Same lens, five domains.
Interview: On exam day, when a question describes a system where something went wrong, run this diagnostic before reading the options: was a must-hold requirement placed on a discretion mechanism? In scenarios describing an unexpected failure, that is the underlying cause more often than any other single explanation, and identifying it usually eliminates two of four options immediately.
Exercise: Starter. For each of the six enforcement ladder rungs, write one requirement from a system you have built that belongs at that rung. If you cannot fill a rung, that is a mechanism to study more closely.
Intermediate. Take a Claude system you have built and audit it: list every requirement you would describe as "must," then identify which mechanism currently enforces each. Any must-requirement sitting on rung 1 or 2 is a real defect in your system, not just an exam exercise.
Advanced. Write four exam-style options for the worked example above - one correct, one under-enforcing, one over-engineered, and one that enforces the wrong thing. Constructing plausible wrong answers is the fastest way to learn to spot them.
Quiz: Quick check: A scenario requires that an agent never returns a customer's full account number, under any circumstances. Which mechanism best satisfies the requirement?
A) A clearly worded instruction in the system prompt forbidding it B) A tool description explaining that account numbers are sensitive C) An output validation layer that redacts or rejects responses containing the pattern D) A few-shot example demonstrating the correct redacted format
Answer: C - "never, under any circumstances" is absolute language, which places the requirement on the enforcement side. Options A, B, and D are all discretion mechanisms; they shape default behaviour but guarantee nothing.