THE AUTOMATION PROPOSAL REALITY CHECK | v1
Original AI-assisted synthetic training examples. No customer audits performed.

A green response, an empty CRM
Evidence: Acceptance of the request was mistaken for durable completion. The complete destination query shows no persisted lead after the queue drained.
Acceptance condition: For test enquiry E-101, submit once with a valid owner. Within 60 seconds, a fresh CRM query by source enquiry ID must return exactly one persisted record with the expected name and owner. Repeat the query after worker restart. With owner missing, report a failed write, never a completed CRM save, and retain a visible recovery item.
Limits: This shows one failed save, not that every request fails. A successful HTTP response alone cannot prove storage. A timestamp without a destination record is insufficient.

One lead becomes two
Evidence: The retry repeats a side effect after an ambiguous timeout. There are two CRM records for one source enquiry; neither automatic retries nor an eventual success response establishes uniqueness.
Acceptance condition: Send E-202 once, force a response timeout after the destination commits, then replay the identical source ID twice. After the retries settle, a fresh CRM query must show exactly one record for E-202 with unchanged agreed fields. Replaying a distinct source ID must create its own single record. Record the replay outcome and chosen source-ID rule.
Limits: Matching names or emails alone are not an agreed identity rule. Do not merge different real people just to pass a duplicate-count test. This case proves duplication in one synthetic run, not a vendor-wide defect.

The draft that sent itself
Evidence: The sending boundary did not enforce the promised approval. The mail sink accepted the pending, unapproved version. The evidence does not establish that a real customer read it.
Acceptance condition: Keep D-303/v1 pending and attempt to send: the mail sink must receive zero messages and the block must be logged. Approve that exact version with an authorized test manager, then send: exactly one matching message may reach the sink. Edit the approved content to v2 and verify sending is blocked until v2 has its own approval. Replayed send requests must not duplicate the approved send.
Limits: A draft label in the interface is not a sending control. Approval for one version must not silently authorize edits. This training example is not a security certification.

Try a new handoff: the booking calendar
Evidence: The UI confirmation did not establish a durable calendar event. The unavailable dependency was not recovered; the complete destination query shows zero events.
Acceptance condition: Force a temporary calendar outage for B-404. The workflow must show calendar sync pending or failed, retain a recoverable item, and avoid claiming calendar completion. Restore the service and exercise the documented recovery. Within the agreed five-minute recovery window, a fresh calendar query must show exactly one correctly timed event for B-404. Replay the recovery once and verify the count remains one.
Limits: Other reasonable time windows can pass if explicit and agreed. The answer must cite the missing event and test the destination, not merely ask for better AI.

SCORING: For baseline and transfer separately, score failure identification 0/1 and observable acceptance condition 0/1. An acceptance condition must name the relevant destination state and a concrete test with a pass/fail threshold. Report the two components separately; a vague request to improve reliability does not pass. Different wording and explicit reasonable time windows can pass. These scores are a manual teaching rubric, not a validated instrument.