Receive
Webhook accepts the lead. No stable request key is currently recorded.
SAMPLE DELIVERABLE / WORKFLOW RELIABILITY
What an audit actually looks like.
This is a fictional example, built to show the structure and depth of a deliverable before you order one. No client data is used.
SAMPLE SYSTEM
Lead form → AI classification → CRM → Slack.
The sample workflow receives a web lead, enriches it with an LLM, creates or updates a CRM record and posts a Slack notification. The reported symptom is simple: “sometimes the workflow times out, and occasionally we see duplicates.”
Audit goal
Find the smallest set of reliability changes that reduce duplicate side effects and make failures diagnosable without rewriting the workflow.
Separate computation from side effects.
Classify
LLM call may time out. Retrying this step is usually safe because it has no external side effect.
Write
CRM update creates a durable external effect. Blind replay can create or overwrite records.
Notify
Slack send is another external effect and needs its own duplicate boundary.
Issues ranked by operational risk.
CRITICAL
No idempotency key before CRM write
If the worker times out after the CRM accepts the request, the next retry cannot prove whether the write already succeeded.
HIGH
Whole-workflow retries
A transient LLM timeout causes the orchestration layer to replay downstream side effects instead of retrying only the safe computation step.
HIGH
Success is not checkpointed
The workflow has no durable record that the CRM stage completed, so recovery starts from memory rather than evidence.
MEDIUM
Logs miss correlation IDs
Operators cannot reliably connect the original webhook, LLM request, CRM result and Slack send during an incident.
MEDIUM
Timeouts share one policy
LLM, CRM and Slack failures use the same retry behavior despite having different side-effect and rate-limit characteristics.
LOW
Manual recovery is undocumented
There is no short operator checklist for determining whether a failed-looking run should be replayed, resumed or stopped.
Fix the dangerous ambiguity first.
Introduce a request key
Derive or accept a stable request identifier before any external write. Store it with the CRM operation.
Checkpoint external effects
Record started/succeeded/failed state around CRM and Slack independently so recovery can resume instead of replay.
Split retry policies
Retry safe LLM failures automatically; gate ambiguous external-effect retries behind evidence or an idempotent API.
Add correlation logging
Use one request ID across all stages and log status, attempt, latency and final disposition without storing secrets.
Tests that prove the fix, not just the happy path.
TEST 01 CRM succeeds, client times out → retry does not create a second record
TEST 02 LLM times out before side effects → safe retry resumes normally
TEST 03 Slack fails after CRM success → recovery sends Slack only
TEST 04 Same webhook arrives twice → one logical CRM effect
TEST 05 Logs reconstruct every stage from one correlation ID
TEST 02 LLM times out before side effects → safe retry resumes normally
TEST 03 Slack fails after CRM success → recovery sends Slack only
TEST 04 Same webhook arrives twice → one logical CRM effect
TEST 05 Logs reconstruct every stage from one correlation ID
A real audit adapts these checks to the actual tools, APIs and failure evidence you provide. The goal is a reviewable repair order, not a generic checklist.
What you receive.
01
Failure map
Where the workflow can fail, which failures are transient and which can duplicate an external effect.
02
Prioritized findings
Critical, high, medium and low findings with evidence and why each matters.
03
Remediation plan
The smallest sensible repair order, including idempotency, checkpoints, retry boundaries and observability.
04
Verification checklist
Concrete scenarios to prove the workflow recovers safely after changes.
Have a workflow that “usually works”?
Send a sanitized diagram, logs or screenshots. I can first tell you whether an audit, a small fix or a larger rebuild is the right scope.