Texas SET, as chains rather than files.
Conduit sends and receives the full ERCOT document inventory and correlates every leg into the chain it belongs to, so a switch reads as one customer arriving rather than seven files that arrived on different days.
Off your desk
You stop paying an EDI vendor to hand you files that someone then has to match against accounts by hand.
Without this
What this looks like today.
The usual arrangement is an EDI vendor who delivers files. They are correct files, on time — and then somebody on your team has to work out which account each one is about, whether the chain it belongs to is complete, and what to do about the ones that are not.
That matching is invisible until it fails. A 814_04 that never arrived, a 867_04 that came for an ESI ID nobody recognises, an enrollment sitting in a state neither side thinks it owns. None of these announce themselves; you find them when a customer calls, or at the end of the month when the numbers do not add up.
The other failure is time. A rejection you see the same morning is a fixable data problem. The same rejection found three weeks later is a lost customer and, sometimes, an inadvertent gain to unwind.
How it works
Market transactions, in detail.
The full ERCOT document inventory, sent and received, with every chain tracked end to end.
The whole document inventory, not a subset
All 44 Texas SET 5.0 transaction types across the eight families — 650, 810, 814, 820, 824, 867, 997 and the T-series. Every type is modelled with the fields its own workflow requires, so a document is a structured record you can query and not a blob with a parser in front of it.
Legs correlated into a chain
A switch is not one transaction. It is a request out, ERCOT's notification to the TDSP, the TDSP's response, the acceptance, the historical usage, the initial read, and eventually a delivery invoice and a payment. Conduit correlates all of them onto one chain against one ESI ID, so where an enrollment has got to is a thing you can look at rather than reconstruct.
Move-ins, move-outs, drops and holds — not just switches
The same chain model covers a move-in, a move-out, a customer-requested drop, a transaction rejected as unexecutable and a move-in held pending permit. These are the paths that generate the exceptions, so they are modelled as first-class rather than as a switch that went wrong.
Failure is a queue you can work
A transaction that fails retries automatically. What survives the retries lands in a dead-letter queue you can inspect, correct and replay yourself. There is no state in which a document has silently disappeared and the only route to it is a support ticket with your vendor.
A simulated market to test against
Conduit ships a market simulator. Run a switch, a move-in, an enrollment rejection, an unexecutable or a permit hold, and watch the chain play out against test accounts — before a real customer is enrolled, and afterwards whenever you want to reproduce something odd.
At a glance
- All 44 Texas SET 5.0 transaction types across the eight families — 650, 810, 814, 820, 824, 867, 997 and T-series
- Inbound and outbound legs correlated into one chain, so a switch reads as a story rather than a log
- Automatic retries with a dead-letter queue you can inspect and replay, not a support ticket
- A simulated market for testing: run a switch, a move-in, a rejection or a permit hold before you go live
Connected
What this leans on.
Nothing here is a separate product with an integration between it and the rest. These are the capabilities this one shares a record and a ledger with.
Questions
The ones we actually get.
Does Conduit replace our EDI vendor?
Yes. Market transactions are part of the core platform rather than an integration to a third party. That is the whole point of the design: the enrollment, the meter read and the delivery invoice all land against the same account, so none of them has to be matched up afterwards.
Which version of Texas SET is supported?
Texas SET 5.0. All 44 transaction types across the 650, 810, 814, 820, 824, 867, 997 and T-series families are modelled, each with the fields its workflow requires.
What happens when a transaction fails?
It retries automatically. If it still fails, it lands in a dead-letter queue that you can inspect, correct and replay yourself. Nothing is silently dropped, and recovering a document does not require a ticket to a vendor.
Can we test against the market before going live?
Yes. The simulated market lets you run switches, move-ins, rejections, unexecutables and permit holds end to end against test accounts. It stays available after go-live, so reproducing an odd chain does not mean experimenting on a real customer.
How do you handle a chain that is missing a leg?
The chain shows the leg as outstanding with what it is waiting on, rather than showing a complete-looking record. Legs that pass their expected window surface as exceptions to be worked instead of waiting to be discovered.
The rest of the platform
One customer record, one ledger, one audit trail.
See it against your own book.
Bring a month of real transactions and a TDSP invoice. Market transactions is easier to judge against data you already argue about than against a demo tenant.