# Sample workflow review: simulated CRM status update
Prepared October 23, 2026 | Demonstration only | No customer engagement

## Decision
Continue testing in a non-production environment. The recorded synthetic checks support the SDK's tested approval-binding and receipt-recovery behavior. They do not establish that a real CRM action is controlled, durably deduplicated, or independently reconciled. Production readiness is not established.

Confidence: high in the seven assertions recorded by the October 17 fixture run; unknown for a customer deployment. This is an example of the findings deliverable for the $300 one-workflow review, not a customer case study or an implementation commitment.

## Scope and evidence
Reviewed: the local demo report generated October 17, 2026 at 23:44:41.664 UTC and its seven scenario assertions, plus the demo runner's stated boundaries. The environment uses an in-memory simulated service, ephemeral fixture Ed25519 signing keys, and a simulated CRM executor. The report records zero network attempts, zero real payments, and zero real customer actions.

Evidence file: [synthetic scenario report](workflow-review-demo.json).
Not reviewed: a real CRM, customer data, production credentials, durable storage, crash recovery, a live approval interface, signer operations, a native n8n adapter, or live enforcement. The October 17 run was inspected for this memo; it was not rerun on October 23.

## Workflow map
Agent proposes a CRM status update -> host validates inputs and classifies risk -> policy produces a decision bound to the proposed action -> SDK checks the action against that decision -> simulated executor runs an allowed action -> receipt records the reported outcome -> integrity bindings are checked.

The customer's technical owner must own validation, trusted executor selection, durable retry handling, and reconciliation. The customer's policy owner must define who may approve what. No customer owners have been assigned in this demonstration.

## Observed controls
| Synthetic scenario | Recorded result | What this supports |
| --- | --- | --- |
| Allowed client update | One executor call; fulfilled receipt; decision/receipt bound; response hash verified | The tested allowed path preserves these bindings in the fixture |
| Tool outside allowlist | Zero executor calls | The tested disallowed tool does not reach the executor |
| Host-declared high risk | Review required; zero executor calls | The host's high-risk classification stops this tested action |
| Arguments changed after approval | Rejected; zero executor calls | The tested change cannot reuse the original approval |
| Receipt outage and recovery | One executor call; duplicate blocked; receipt recovered as fulfilled | Receipt recovery does not repeat this simulated action |
| Uncertain executor outcome | One executor call; no fabricated failure receipt; retry blocked | This ambiguous result remains unresolved rather than being blindly retried |
| Returned MCP tool error | Failed receipt | A returned tool error is recorded as failure |

Seven of seven recorded scenarios passed. These are observed fixture results, not production coverage percentages.

## Prioritized findings
These are deployment evidence gaps, not demonstrated production vulnerabilities. Priority reflects the consequence of leaving a gap unresolved; likelihood is unknown without inspecting the host.

### 1. Durable duplicate prevention is not demonstrated — high priority
Evidence: replay protection in the demonstration is in-memory. Receipt-outage and uncertain-outcome scenarios pass within that process.
Consequence: after a process restart or concurrent request, a production host might lose the state needed to prevent a repeated side effect.
Next check: simulate a real action completing while its response is lost; restart the host; replay the same stable operation ID from two workers. Inspect the downstream state and durable operation record.
Acceptance: exactly one downstream change; unresolved outcomes block retry until reconciled.
Suggested owner: customer technical owner.

### 2. Human approval depends on host policy and identity — high priority
Evidence: the fixture's host supplies the high-risk classification and trusted executor. The high-risk case invokes the executor zero times.
Consequence: the tested review result alone does not establish who can approve an action, how an approval is authenticated, or how changed scope and expiry are handled.
Next check: trace one allow, one deny and one review through the actual host, including an unauthorized approver and changed arguments.
Acceptance: only an authorized, current approval for the exact action permits execution; review status alone never permits it.
Suggested owner: customer policy owner with technical owner.

### 3. A signed receipt does not independently establish the CRM change — high priority
Evidence: the executor and its response are simulated. The fixture verifies decision/receipt and response-hash bindings.
Consequence: a valid signed assertion can still lack independent evidence of the actual external system's state.
Next check: correlate the operation ID with a downstream sandbox record and its audit event, including success followed by a lost response.
Acceptance: a reviewer can distinguish observed downstream success, reported failure and unknown outcome using independent records.
Suggested owner: customer integration owner.

### 4. Production signer and evidence operations are outside the test — medium priority
Evidence: the run uses ephemeral fixture signing keys and an in-memory simulated service.
Consequence: key access, rotation, verification across retained history and evidence retention cannot be assessed from these results.
Next check: document key custody and retention; test rotation and verification of records signed before and after rotation with non-production keys.
Acceptance: only approved signers can issue records, historical records remain verifiable, and key/retention incidents have a named response owner.
Suggested owner: customer technical/security owner.

## First milestone and stop condition
Agree one sandbox CRM action and a stable operation ID. Test changed approval arguments, concurrent delivery, process restart after an ambiguous outcome, and receipt-only recovery. Retain the operation record and independent downstream evidence for each case.

Proceed to implementation only after agreeing the integration boundary, acceptance tests, responsible owners, data handling, effort and price. If existing host controls already satisfy these requirements, record that conclusion instead of adding another control layer. If the host cannot support the required evidence or durable state within the agreed scope, stop and scope that work separately.

## Handoff
Deliver this style of map, findings and fix plan, then walk through the evidence and one clarification round within the agreed review time cap. No customer walkthrough, acceptance, payment or implementation occurred for this sample.