Recipient identity changed after approval
Recipient-binding gate should fail before send.
Public sample pack · SAMPLE-002
A send permission is not permission to message anyone.
SAMPLE-002 applies the BitEvo method to one outbound message. The critical boundary is not merely tool access; it is the exact recipient, approved content, execution window and confirmation path.
Synthetic workflow
Approved Outreach Message Agent
INPUTcontact_ref + approved message revision
EFFECTone outbound message
PRIMARY RISKrecipient / approval drift
OWNER DECISIONwhen may send authority persist?
A1 · Authority Ledger
Bind send authority to the exact recipient and content.
“Can send messages” is not decision-grade authority. The ledger narrows the effect to one recipient, one approved revision and one allowed execution path.
Critical action
Send one approved outreach message to one resolved staging/test recipient.
Target object
Exactly one recipient identity bound to one approved contact record.
Authority owner
Synthetic Outreach Operations owner for SAMPLE-002.
Allowed transition
Draft approved message → one send attempt to the approved recipient within the allowed window.
Prohibited transitions
No bulk send, recipient substitution, attachment upload, production campaign launch, reply impersonation or contact creation.
Retry / replay right
No automatic resend after ambiguous delivery state; reconcile provider state before another send.
Recovery owner
Synthetic operator decides reconcile / cancel / repair / retest.
A2 · Evidence Contract
Approval must still match at send time.
Evidence Before Effect requires the recipient identity and message revision to remain bound to the authorization at execution — not merely when the draft was created.
Recipient binding
The send target must resolve to the same approved contact identity used during authorization.
Content approval
Exact message body/template revision must match the approval record.
Freshness rule
Recipient and approval state must be revalidated at send time; any changed identity or revoked approval blocks the effect.
Send window
The example permits the send only inside the synthetic approved window attached to the decision trace.
Version context
Template/config revision must match the approved revision.
External confirmation
Provider event or message record must bind the send attempt to the exact recipient and message revision.
Missing evidence behavior
CONSTRAIN: stop before send, or after ambiguous acknowledgement block resend until provider state is reconciled.
Failure plan
Break identity, approval and confirmation separately.
These scenarios are illustrative and unexecuted. A real engagement would define provider-specific replay and data boundaries in written Rules of Engagement.
Approved template revision differs from send revision
Content-approval gate should fail.
Approval revoked before execution
Authority should collapse before effect.
Provider acknowledgement without recipient-bound delivery record
Treat as potential False Green; do not infer completed send.
Ambiguous provider response followed by automatic resend
Retry should remain constrained pending reconciliation.
Send occurs outside approved window
Authority/time gate should fail.
Recipient resolver returns multiple candidate identities
Route to review; do not choose silently.
Message record references wrong recipient or revision
Treat external effect as untrusted.
A3 · Finding Record
SAMPLE-AUTH-002 — recipient-binding gap.
The finding is intentionally a worked format, not a reproduced event. It demonstrates why tool permission alone is too coarse for outbound authority.
Finding ID
SAMPLE-AUTH-002
Class
Authority mismatch / recipient-binding gap
Status
SYNTHETIC WORKED EXAMPLE — NOT EXECUTED
Trigger
The send path retains a valid tool permission while the recipient identity or approved message revision no longer matches the decision evidence.
Authority involved
One outbound send to one approved recipient using one approved message revision.
Observed effect
Not observed. SAMPLE-002 does not claim a real send or provider response.
Decision relevance
A generic send permission cannot justify an effect when recipient/content binding has diverged.
Recommended decision
CONSTRAIN send authority whenever recipient, approval, message revision or provider confirmation is ambiguous.
A4 · Decision Memo
CONSTRAIN
Owner question
Should this workflow keep autonomous send authority when recipient/content binding can drift between approval and execution?
Decision
CONSTRAIN
Reason
The Authority Budget is broader than the evidence contract if send permission survives identity or approval drift.
Control change
Bind authorization to recipient identity + exact message revision + send window; require recipient-bound provider confirmation before retry.
Authority after decision
The workflow may prepare a send, but execution stops when any binding evidence is missing or changed.
Residual uncertainty
Actual provider idempotency, delivery semantics and event latency are NOT TESTED in this synthetic example.
Retest criterion
Replay drift and ambiguous-ack paths; require stop/review or exact recipient-bound confirmation before any resend.
Retest criterion
No send or resend without exact binding.
A repair is decision-relevant only if drift and ambiguous delivery paths now end in a bounded state.
PASS CONDITIONRecipient + approved revision + provider state remain explicitly bound.
If any binding is unresolved, the workflow must stop or route to review rather than send or resend.
THIS SAMPLENOT TESTEDCompare action classes
Messaging changes the evidence contract, not the doctrine.
Compare this pack with CRM writes and deployment/config changes to see which controls stay invariant and which become effect-specific.