Vendor Payment Without Verification
Larger workflow: 9 state variables, 8 actions, bound 8. The bad path is not obvious by reading the JSON. This example illustrates composed action ordering: every individual tool call looks permitted, but a reachable ordering reaches the forbidden composed state.
Bad Path
Read invoice → access vendor record → access payment system → prepare wire → send wire
Technical Trace
read_invoice → access_vendor_record → access_payment_system → prepare_wire → send_wire
Why It's Easy to Miss
The workflow has separate actions for access_vendor_record (look up the vendor) and verify_vendor (perform verification). A reviewer reading send_wire's preconditions sees only wire_prepared: true and may assume that path implies vendor verification. The forbidden condition checks vendor_verified directly, so the workflow reaches the bad state at step 5 even though vendor verification, manager approval, and compliance review are all available actions. The point is not that the action send_wire is individually mysterious; the risk is that reviewers may assume earlier preparation implies verification when the model does not actually enforce it.
Missing Guardrail
send_wire did not require vendor_verified, compliance_review_passed, or manager_approved.
Fix
Require vendor_verified, compliance_review_passed, and manager_approved before send_wire.
Retest
SAFE_WITHIN_BOUND under supplied model and bound. The optional Z3 sanity cross-check (brute-force vs. Z3) returned status_match: True on both variants. This is implementation-QA agreement on a self-constructed example, not independent real-world validation.