diff --git a/docs/live-ai-integration/n8n-current-state.md b/docs/live-ai-integration/n8n-current-state.md
index 8989ac5..bf83c3e 100644
--- a/docs/live-ai-integration/n8n-current-state.md
+++ b/docs/live-ai-integration/n8n-current-state.md
@@ -175,3 +175,48 @@ workflow exists yet.
 6. Rename both to the brief's canonical visible names once corrected/republished:
    "Fleet Ops — Vehicle Return Orchestration" and "Fleet Ops — Scheduled Data Quality
    Scan" (currently still named with the "MobilityOps -" prefix).
+
+## Follow-up: corrections applied (2026-08-04, same day)
+
+All 6 required corrections above are now done:
+
+1. **Done.** Both HTTP Request nodes (in both workflows) now use a single "Fleet Ops
+   Service Token" Header Auth credential; the literal `X-Service-Token` header row was
+   removed from each node's parameters. Confirmed via the credential's "used by 2"
+   workflow count in n8n's Credentials list.
+2. **Done.** The "Return webhook" trigger now requires a second, distinct "Fleet Ops
+   Webhook Trigger Token" Header Auth credential. Fleet Ops's outbox dispatcher
+   (`backend/app/services/dispatcher.py`) now sends the matching
+   `X-Fleet-Ops-Trigger-Token` header (new `MOBILITYOPS_WEBHOOK_TRIGGER_TOKEN` setting,
+   added to `.env.example`, `compose.yaml`, the local dev `.env`, and the Unraid
+   server's `.env`). Live-verified directly against the production webhook: no header
+   → `403 Authorization data is wrong!`; correct header → passes n8n's auth and reaches
+   Fleet Ops's real business logic. Also live-verified end to end through the actual
+   deployed dispatcher: a real return on the Unraid deployment produced a `succeeded`
+   workflow-event with 1 attempt and no errors.
+   - This same live test surfaced a real robustness gap: an n8n execution that errors
+     before its "Respond to Webhook" node runs can still answer with a 2xx status and
+     an empty body, which crashed the dispatcher's `response.json()` outside its own
+     error handling. Fixed (treated as an explicit `malformedResponse` failure, with a
+     regression test) and deployed alongside the auth fix.
+3. **Done.** Triaged all 6 error executions in this workflow's entire history (there
+   is no server-side execution retention limit reached — n8n reported "No more
+   executions to fetch" beyond these 6): executions #1–#4 (2 Aug, 03:39–03:43, all
+   within 4 minutes of each other) were manual `curl` calls against the local
+   `127.0.0.7:5678` test webhook with a `curl/8.16.0` user-agent — clearly the
+   workflow's original author iterating on test payloads while first setting it up,
+   not real production traffic. Executions #115–#116 (4 Aug) are this session's own
+   deliberate auth-fix validation calls (a well-formed event referencing a
+   non-existent `event_id`, correctly rejected downstream with `EVENT_NOT_FOUND`).
+   **Zero unexplained or currently-live failures.**
+4. Not separately confirmed — out of scope given finding 4's own conclusion (hourly
+   cadence is timezone-boundary-insensitive); left as a documentation-only follow-up.
+5. **Done, per explicit user confirmation.** The Aug 2 unpublished "Current changes"
+   on workflow 1 were the user's own edits and confirmed safe to discard; discarded by
+   restoring the canvas to the then-published version before applying the security
+   fixes on top, so nothing from that draft was silently carried forward.
+6. **Done.** Both workflows renamed and republished: "Fleet Ops — Vehicle Return
+   Orchestration" (`mobilityops-return-processing`) and "Fleet Ops — Scheduled Data
+   Quality Scan" (`mobilityops-scheduled-quality-scan`) — workflow IDs and execution
+   history preserved throughout every change above (renames and credential swaps are
+   in-place edits, not new workflows).