Proof, not promises
Thirteen million claims. Two hours. Sixteen workers.
The EDI engine speaks X12, not one industry’s dialect. This page is the public measurement: a two-hour large-file soak on 30 June 2026. A private customer walkthrough is not included.
13,443,911
Claims processed
10,210/s
Sustained
48,330/s
Peak
120 min
16 workers
7,617 files. 100% success on the tiers that ran. Sixteen worker containers at 4 GB. PostgreSQL tuned — shared buffers 4 GB, max WAL 8 GB — on fastpool, a 16K-recordsize SSD mirror. The earlier single-file check still stands: a 517 KB file of 3,100 claims parses, validates, and projects in 0.0475 seconds.
THE SOAK
Load test 3
Claims per second in cyan, cumulative claims in amber, across 120 minutes as file size climbed. Throughput holds through the dense files, then the large single-file tiers stop the line. That stop is the finding, not a hidden miss.
Download the one-page summary
Three tests, same direction
Tests 2 and 3 are two-hour soaks. Test 1 is a single pass of about 28 minutes. The corpora differ — test 3 is weighted toward large files — so read this as a direction, not a controlled benchmark.
| Test | Workers | Claims | Throughput | Notes |
|---|---|---|---|---|
| 1 | 4 | 1.06 M (28 min) | ~622 /s avg | Baseline, mixed sizes |
| 2 | 8 | 6.10 M | ~910 /s loop · ~5,700 /s dense | Before Postgres tuning |
| 3 | 16 | 13.44 M | 10,210 /s sustained · 48,330 peak | After Postgres + fastpool |
What each tier did
| Tier | In the corpus | Processed | Note |
|---|---|---|---|
| 10 MB | 100 | 100 | Full tier. Clean at high throughput. |
| 50 MB | 100 | 80 | Dense files. This tier drove the peak. |
| 512 KB | 400 | 400 | Full tier. |
| 1 KB | 100,000 | 7,037 | Small-file tail. Bound by per-file overhead. |
| 100 MB | 100 | 0 | Did not run. One file, one message, too large. |
| 200 MB | 100 | 0 | Did not run. Same ceiling, larger. |
The ceiling is architectural
Ten- and fifty-megabyte files process cleanly at high throughput. A 100 MB or 200 MB file is base64-encoded into one message — about 140 MB and 279 MB — and parsed entirely in worker memory, on the order of 3–6 GB for 250–500 thousand claims. That overwhelms the broker and the per-worker budget no matter how many workers you add. Next unlock: chunk the file at the interchange boundary before enqueue, for files past roughly 50–70 MB.
01
Government-grade X12 validation
Integrity through implementation-guide checks, a loop-aware parser, and machine acknowledgments. Every issue is anchored to its segment, element, and loop.
02
Coverage and coding scrub
NCCI, NCD/LCD, modifier relationships, sequencing, eligibility, and duplicates — driven by versioned rule tables, not rules welded into the code.
03
FHIR R4, both directions
CARIN and Da Vinci profiles between legacy transactions and modern resources. The bridge, not a rewrite of the last thirty years.
04
Tiered AI, supervised
A fast path for conforming work. Harder cases go to scored tiers and specialist agents under a supervisor policy. Confidence and trigger reasons are recorded for replay.
05
Tamper-evident provenance
Deterministic record identity and an append-only Merkle journal. When “trust us” is not good enough, the math is.
Port it for your stack
EDI is not one industry’s problem. Shipping and logistics operators who want this engine on their own transaction sets get the same rigor, in their formats.
If your operation runs on EDI, say soOpen guardrails
Local-81 is the public deploy and runbook control plane: dry-run first, compliance and hardening reports included. Commercial provenance internals stay private. That split is the strategy.