A treasury refund agent must not call process_refund until get_resident returns a verified resident ID. How should that prerequisite be enforced?
Select an answer to reveal the explanation.
Short Explanation
Money moves need locked doors, not polite signs. Use a hook or hard gate so process_refund literally cannot fire until get_resident verifies the ID—prompts alone are too easy to shrug off.
Full Explanation
A treasury refund agent must not call process_refund until get_resident returns a verified resident ID; that prerequisite should be enforced programmatically with a hook or equivalent gate rather than prompt-only ordering. Monetary side effects in municipal systems require hard controls: the runtime should block or intercept process_refund when verification has not succeeded, regardless of what the model proposes in a given turn.
Programmatic gates work because LLMs are probabilistic compliers. Prompt instructions about order are helpful hints, not audit-grade controls for disbursements from the treasury. Hooks, allowlist state machines, or pre-tool validators create fail-closed behavior suitable for refund risk and resident trust.
Mentioning the order once in the system prompt and relying on probabilistic compliance is insufficient for refund integrity. Allowing process_refund first and verifying identity afterward optimizes for speed at the cost of wrongful payments. Skipping get_resident when the resident types their name in chat confuses self-asserted identity with verified ID from the authoritative resident system.
Exam caveat: combine gates with logging—denied process_refund attempts are security-relevant events for treasury operations. Operational check: attempt process_refund before a successful get_resident in test and confirm the hook blocks the call; after verification, confirm the same call proceeds under policy.