Your largest customers exchange EDI. Everyone else sends PDFs, spreadsheets, and emails. Semantic EDI turns those documents into the same structured transactions. Adaptive parse reads what each document means: a deterministic parser first, the model only where the parser cannot settle it. Deterministic software decides what happens next.

Your largest customers and suppliers exchange EDI. The long tail sends PDFs, spreadsheets, and emails, and someone keys them in by hand.
Our Approach: Accept every partner's documents as they are and produce the same structured transaction.
Template-based capture needs a new template for every sender and fails when a sender changes their layout.
Our Approach: Adaptive parse reads meaning, not character positions, so a new layout is not a new project.
When an AI system posts a wrong line item, nobody can say why it happened or what else it touched.
Our Approach: Deterministic validation and a traceable record from source document to posted transaction.
A revised quantity or date arrives by email, and the original order, the promise date, and the customer confirmation all go out of date.
Our Approach: Changes handled as changes, with dependent commitments surfaced for review.
Adaptive parse works like the front end of a compiler: it turns messy human documents into a precise intermediate form, using the model only where the deterministic parser cannot. Everything after that is deterministic.

Adaptive parse
A deterministic parser reads what it can and the model reads only what the parser cannot settle, extracting parties, items, quantities, prices, dates, and terms.
Typed record
The result is a structured, EDI-grade transaction with a fixed shape, not free text.
Deterministic validation
Rules check the record against your items, prices, customers, and policies. Exact matches outrank AI guesses.
Exception routing
Anything that fails a check goes to a person with the source document and the reason attached.
System of record
Validated transactions post to your ERP. Corrections made by your team feed back into the process.
Any process where a standard format exists but partners still send documents.

Most order automation handles the first document well and the second one badly. A revised quantity, a new ship date, or a cancelled line arrives by email, and everything built on the original values goes out of date: the order lines, the promise date, the customer confirmation.
We design for that case from the start. A change is parsed as a change to an existing transaction, and the commitments that depended on the old values are surfaced for review rather than left to go stale.
Every automated decision runs through our code-deterministic stack: rules, a trained System 1, a disagreement cascade, an LLM, and a person with the final word, with every verdict fed back as a label.
Semantic EDI turns business documents that arrive in any format (PDF purchase orders, spreadsheets, email bodies, scanned forms) into structured, EDI-grade transactions. A deterministic parser reads what it can, AI reads only what the parser cannot settle, and deterministic software validates the result and posts it to your systems. Your trading partners keep sending what they send today.
Traditional EDI requires both trading partners to exchange documents in an agreed format such as X12 or EDIFACT. That works for large partners and excludes everyone else. Semantic EDI accepts the documents partners already produce and converts them into the same structured result, so the partners who will never implement EDI still flow through an automated process.
Adaptive parse (AdaptiveParse) is the first stage of semantic EDI: a deterministic parser first, the model only when the parser cannot settle a field. It extracts the business meaning of a document you have never seen before into a typed record, and adaptive parsing adapts to each sender instead of relying on a fixed template per sender.
No. AI is used only to read what the deterministic parser cannot. Validation against your prices, items, customers, and business rules is deterministic code, and anything that fails a check is routed to a person with the source document attached.
Changes are where order automation usually breaks. We treat a change as a change to an existing transaction, not as a new order, and we design the downstream checks so that commitments built on the old values are surfaced for review instead of silently going stale.