A Controlled CRM Write, Deliberate Failure and Safe Replay
A Controlled CRM Write, Deliberate Failure and Safe Replay
Evidence label: KNIC build note — synthetic demonstration
This deterministic demonstration tests the part of an AI workflow that begins after the model produces an answer: whether the system may act, how it fails and whether an operator can recover it without duplicated work.
It uses fictional people, locations and records. It makes no client, production-scale or return-on-investment claim.
The scenario
A fictional 60-location service network receives a customer enquiry. The workflow must resolve the customer and responsible location, propose a follow-up action, pass an explicit permission check and write to a mock CRM.
The strongest test deliberately makes the CRM unavailable during the first write.
What happens
- The workflow receives only the permitted fields from a synthetic enquiry.
- It resolves identity, location and service availability.
- The model proposes a bounded
CREATE_FOLLOW_UPaction. - A separate policy step decides whether that action may write, needs approval or must stop.
- The first CRM write fails without creating a partial record.
- One exception is created with a named owner, a 15-minute response clock and the context needed to recover.
- A synthetic operator confirms recovery and replays the preserved command.
- A second deliberate retry is suppressed by the idempotency key.
The final audit trail contains 13 ordered events under one stable correlation ID, from ENQUIRY_RECEIVED through DEPENDENCY_FAILED, OPERATOR_RESOLUTION, WRITE_COMPLETED and DUPLICATE_WRITE_SUPPRESSED.
The ambiguity test
A second scenario supplies two possible customer matches and identity confidence below the policy threshold. The model may still propose the follow-up, but the permission layer blocks the CRM write and routes the case to Customer Operations.
This distinction matters: a model recommendation is not authority to act.
What this demonstrates
- model output is separated from the permission decision;
- a live-system action can be limited to one explicit scope;
- ambiguous identity fails closed before a record changes;
- dependency failure creates one owned exception rather than partial work;
- an operator can reconstruct why the workflow stopped;
- a failed command can be replayed; and
- a repeated command cannot create a duplicate record.
What it does not demonstrate
- client adoption;
- production scale or reliability;
- integration with a real customer CRM;
- measured financial results; or
- suitability for a regulated workflow.
That boundary is deliberate. Synthetic evidence can prove implementation technique. Only permissioned production evidence can prove a client outcome.
The production test
Before calling an AI workflow live, break a dependency, supply ambiguous data, remove a permission and retry an action. The workflow should stop safely, expose one actionable exception and recover without duplicate or silent work.