Dispatch Guard — data-to-dispatch control room

OPEN THE CONTROL ROOM Open the dispatch-guard-control-room.html attachment below to run the Control Room in a browser. The single file contains the interactive scenarios, source ledger, decision trace and recorded reference evidence; it needs no server or account. The controls execute a local JavaScript model. Python/SQLite results are separately recorded. Reproducible Python source is an optional supporting attachment.

DISPATCH GUARD / CONTROL ROOM Every row. Every decision. Every failure.

THE PROBLEM Six imperfect records enter a workflow. A duplicate business ID can inflate a total, an unknown amount can disappear behind a zero, and an ambiguous relationship can attach the wrong person. Even a correct audit can fail later: a correction invalidates an approval, a double-click repeats an intent, or a worker exits after the receiver commits.

THE CONNECTED SOLUTION The standalone Control Room joins data validation, version-bound approval, a stable request identity and recoverable dispatch in one inspectable journey. Three records are accepted and three are quarantined. Legitimate equal-value records remain distinct. USD 240.00 and EUR 45.00 remain separate; unknown amounts stay unknown. A source correction preserves the old approval for inspection and blocks it from becoming a fresh intent.

EXPLORE THE WORKING INTERFACE Use four guided scenarios or change the event order yourself. Inspect the source ledger, decision trace and separately recorded Python/SQLite evidence. Crash after receiver commit, change data after approval, change data after a dispatch attempt, or remove the verified receiver contract. Recovery produces one recorded delivery when the mock receiver contract is verified; otherwise the workflow holds the retry for reconciliation. The browser executes a JavaScript contract model, not Python or SQLite.

PROOF THAT CAN BE INSPECTED 51 Python tests pass: the original 35 dispatch tests plus 16 data-to-dispatch integration tests. Four integrated reference cases agree with the browser model on source revision, local state, receiver delivery count, fencing token and approved totals. A separate model exploration checks 19,608 state nodes against conservation and delivery invariants; these are model checks, not production traffic or a performance benchmark. The original seven recorded experiments remain embedded in the HTML demo, including threaded contention and an actual child-process exit with code 17.

THE BOUNDARY An outbox alone cannot guarantee one external delivery. Safe replay depends on a retained receiver key, payload binding and receipt. A data change after claim can still race remote delivery. Unknown outcomes remain visible. No live provider, multi-host network partition, power-loss, authentication or production deployment is claimed. The standalone HTML was opened from its native Contra attachment and all four guided cases were exercised. Model parity and DOM behavior were checked separately.

ORIGIN AND SOURCE This is original self-initiated work by Simone Santia, developed with AI assistance using synthetic fixtures. It demonstrates Python, SQL, data quality, workflow reliability and evidence-led interaction design. It is not commissioned client work. The optional source bundle includes both the browser model and the actual Python/SQLite reference, tests, run commands, evidence and checksums. The original 35-test dispatch-only source below remains its earlier snapshot.

DISPATCH GUARD | SELF-INITIATED PYTHON/SQL FAILURE LAB Make ambiguity visible and retries inspectable. This original local module tests request-side reliability across two independent SQLite databases: a sender outbox and a mocked idempotent receiver.

Seven executed synthetic scenarios cover stale approvals, repeated submissions, competing workers, a process exit after receiver commit, old-worker acknowledgments, bounded ambiguous retries and a late-message race. Thirty-five regression tests pass. In one run, 48 submissions across eight threads create one queued request and 47 replays; 16 worker claims across eight threads grant one live lease.

THE CRASH WINDOW A worker process exits deliberately with code 17 after the separate mock receiver commits, before the local acknowledgment. After lease expiry, a restarted worker acquires a new token. The receiver replays its persisted receipt, adds zero deliveries, and the local outbox becomes SENT. Direct SQL counts confirm one request, one sent outbox row, one receiver delivery and zero foreign-key errors.

A BOUNDARY WE TEST, NOT HIDE An inbound arriving after claim can still race delivery. Local revision checks protect acceptance and claim; they cannot guarantee that the conversation remains current at a remote receiver. Old-token fencing protects local acknowledgment, while safe retry depends on receiver-side idempotency. Ambiguous exhausted retries remain UNKNOWN and require reconciliation.

INSPECT THE SOURCE The downloadable source archive includes the original implementation, 35 tests, the controlled crash worker, an executable scenario runner, actual evidence JSON, test output, a state-machine walkthrough and checksums. Run the demo command in its README with Python 3.12 standard library only. All messages and reviewed drafts are synthetic fixtures. Development is AI-assisted. No real human approval flow, authentication, AI provider or live message delivery is implemented; production requirements would be designed and validated separately.