Stedi went to healthcare. The supply-chain layer is open ground.

Written for ED-1 — the supply-chain ISV / traceability-vendor engineering org — the VP Engineering / CTO reading the field before a build-vs-buy or embed decision.

One thesis: the strongest engineering company ever to work developer EDI pivoted wholly to healthcare while leaving its X12 reference live and free, and our own dated audit of the remaining developer-EDI field found no EPCIS product at any vendor — so the layer this site occupies, EDI compiled to conformant event records, is verifiably unoccupied ground.

A methodological note before the claims: everything below is cited to primary sources — vendor pages, funding announcements, direct HTTP checks — and the negative findings are stated as our search results with dates, not as market facts. Absence of evidence is reported as exactly that.

The pivot, from primary sources

Stedi announced "Stedi Healthcare: the only API-first clearinghouse for health tech companies" on May 6, 2024; the post makes no mention of the prior general-EDI business. The accelerant is a matter of public record — the February 2024 Change Healthcare cyberattack, into which Stedi shipped a drop-in clearinghouse replacement within days. The funding trail confirms the commitment: a $70M Series B co-led by Stripe and Addition (September 2025, "to build the only AI-enabled clearinghouse"), then a $50M Series C led by Addition (March 2026) — $142M total raised, positioning as "the only healthcare clearinghouse for agentic RCM." Their July 2026 changelog runs at one to two shipped entries per day, essentially all healthcare claim edits. This is not a company winding down; it is a company shipping ferociously at a different industry.

The general EDI platform was never sunset — no deprecation notice exists that we could find (2026-07-31, stated as a search result) — but its marketing page now reads "Health tech runs on Stedi," and the documented use cases are payer claims, ERAs, and 834 enrollment. Retail and logistics have vanished from the product surface. Supply-chain EDI was not discontinued; it was abandoned as a market while the machinery stayed up.

What stayed up: the reference, verified live

The part every supply-chain integrator should care about: Stedi's public X12 reference is live, free, and stable. Verified by direct HTTP check on 2026-07-31: edi.stedi.com 308-redirects to stedi.com/edi/, preserving old deep links, and the transaction-set pages return 200 across the supply-chain sets — 850, 856 (in 004010 as well), 810, 846, 940, 945, 214, 997. The footer states the reference "is provided for marketing purposes and is free of charge." It remains the canonical public X12 reference, published under Stedi's negotiated license with X12 — which is why this site links it for all segment-level detail and republishes none of it. Credit where it is owed: it is the best EDI reference on the internet, and it belongs to a healthcare clearinghouse now.

The field audit: five vendors, zero EPCIS

The rest of the developer-EDI field, audited against their own public surfaces (2026-07-31):

• Orderful — active, a16z-backed, launched "Mosaic" AI-native mapping in December 2025. GS1 surface: GS1-128/UCC-128 label generation. No EPCIS.
• Zenbridge — active, the purest EDI-as-API play, public pricing. No EPCIS or GS1-standards angle found.
• Cleo — active, PE-backed, "AI-native orchestration" release December 2025. Visibility rhetoric throughout; no EPCIS or GS1-standards product found.
• SPS Commerce — public company, the retail network incumbent. GS1 surface: GDSN data-sync content. No EPCIS product found.
• TrueCommerce — active, "agentic AI" platform announcements April 2026. No EPCIS product found.

Five vendors, every one AI-rebranded within the last twelve months, and the GS1 surface across all five stops at barcode labels and GDSN content. Nobody compiles a business document to an EPCIS event. The adjacent vacuum — MCP servers for EDI that stop at parse — is its own census.

These are our search results, run with intent, dated 2026-07-31. A vendor could ship tomorrow; the finding is that as of the date on this post, the EDI-to-events layer has no occupant we could find.

What open ground obligates

An empty field is only an argument if occupying it means doing something harder than the incumbents chose to do. The obligation this layer accepts is that the output is not JSON-ified EDI — every vendor above already sells that — but a conformant event record: documents compiled onto core CBV fields, every emitted event validated against the pinned official EPCIS 2.0 schema, superset context riding along and conformant always, with byte-exact fidelity on the wire side and published, adjudicated ground truth underneath. The one-sentence version: the field's incumbents modernized how EDI is moved; the unoccupied work is what EDI means on an event spine.

For the team that built on Stedi's platform and now reads its roadmap with a frown, the Guide JSON bridge is the practical door. For the CTO deciding whether to build this layer in-house, the maintenance-tax argument is in the harness post. The access flow is at /get-access/ — it asks which document sets are on your wire and who owns the trading-partner map, which is how the open ground gets sequenced.

---

818 words. The access flow is at /get-access/; the family's event door is epcis.dev.