Execution-time checks
Bind a preview to its facts and payload, then re-evaluate volatile controls at send, dial, submit, or post time so queued work cannot act on stale permission.
Preparation answers “would this action be eligible now?” Execution answers “may this exact action run now?” Both are necessary because facts can change between them.
What can change
In the seconds or days between planning and execution:
- the customer revokes consent or asks you to stop;
- a bankruptcy, representation, dispute, fraud, or vulnerability signal arrives;
- another worker uses the remaining contact capacity;
- a payment posts, returns, or moves in flight;
- a loan, schedule, restriction, instrument, or case version changes;
- the customer’s local time crosses a configured boundary;
- a product or rule version reaches its effective time;
- an approver rejects or the approval expires.
An earlier allowed result cannot authorize around any of those changes.
Two-decision pattern
Interaction example
curl -X POST "$BASE/v1/servicing/interactions" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: hbr-call-attempt-2027-05-01-1" \
-d '{
"caseId": "case_HBR_COL_51",
"direction": "outbound",
"channel": "voice",
"purpose": "collections",
"contactPointId": "cp_MAYA_MOBILE_1",
"content": { "scriptVersion": "collections-opening-v5" }
}'The interaction API does not trust a caller-provided allowed flag. It creates or schedules the interaction, resolves the latest contact facts, makes the execution decision, and only then invokes the channel provider.
Atomicity boundary
To avoid a check-then-act race, the executor binds:
- normalized action payload hash;
- customer, loan, case, instrument, schedule, and restriction versions used;
- policy bundle and rule versions;
- decision ID and expiry;
- idempotency key and attempt number;
- provider request or authoritative action reference.
If a bound version changes before commit, execution fails with a conflict or new decision—not a stale side effect.
Blocked attempts are evidence
A blocked attempt is not a sent interaction and should not count as provider delivery. It still records the intended action, pre-check, current blocking fact, rules, time, actor, and safe next step. This proves the control prevented execution.
Population actions
A mass action fans out into individually governed actions. Each customer receives a fresh evaluation at their execution time. One customer can be allowed, one blocked, one missing facts, and one already resolved; the aggregate result preserves every branch.