Deterministic vs. Probabilistic Controls

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 PreToolUse hook 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.