Deterministic vs. Probabilistic Controls
CoreDesign layered guardrails and safety controls for production Claude systems · Difficulty 3/5
Explanation
The single most exam-relevant distinction in Domain 5 is between a probabilistic control and a deterministic control, because the correct architectural choice depends entirely on how much certainty the requirement demands.
The Distinction
- Prompt guardrail (probabilistic): A sentence in the system prompt ("never issue refunds over $500") is guidance the model usually follows. It has a non-zero failure rate.
- Hook or permission rule (deterministic): Code that runs on every tool call, regardless of what the model "decides" -- for example, a
PreToolUsehook that blocks a destructive account-deletion action every time.
Where Each Belongs
Hard policy limits and destructive-action prevention belong in deterministic controls. Soft style or tone preferences can safely live in a prompt, because an occasional deviation is tolerable there. Once a requirement is a hard limit (financial thresholds, irreversible actions, compliance-mandated behavior), only a deterministic control provides the guarantee an architect needs to sign off on.
Worked Example
A workflow that can issue refunds automatically, where refunds are high-value and hard to reverse, should require human-in-the-loop approval enforced by a deterministic gate before execution -- not merely a system-prompt instruction to "check with a human when unsure," and not just logging the refund after the fact (logging alone is detective, not preventive).
Common exam traps
- "Put the safety rule in the system prompt." This is the same trap restated for a specific scenario: whenever an exam item describes a hard limit (deletion, refunds, compliance thresholds), the correct control is a hook/permission rule, not a prompt sentence, and not a sampling change like lowering temperature or switching to a larger model.
Key Takeaways
- Probabilistic control = prompt guidance, usually followed but not guaranteed
- Deterministic control = hook/permission rule, runs in code every time
- Hard limits (financial thresholds, destructive actions) require deterministic controls
- Logging a violation after the fact is detective, not preventive -- it doesn't replace a gate
- Lowering temperature or using a bigger model does not turn a probabilistic control into a deterministic one
Glossary Terms
An Agent SDK lifecycle hook that intercepts tool calls before execution. Can inspect, modify, or block the call. Used for access control, parameter sanitization, rate limiting, and audit logging. Runs synchronously before the tool executes.
Shell scripts or commands configured in .claude/settings.json that run at defined lifecycle points: PreToolUse (before tool execution), PostToolUse (after tool execution), Stop (before ending), SubagentStop (when subagent finishes). Used for code quality gates, notifications, logging, and safety checks.
Related Concepts