Why I Created CORD

This is the story of how CORD came to exist. Not the technical documentation. Not the spec sheet. The actual reason it had to be built.

It started in automotive

I spent the better part of a year building ACP, the Automotive Commerce Protocol. The goal was straightforward. Dealership AI systems were having rich conversations with customers, capturing detailed context about what they wanted, and then losing almost all of it when the data moved into a CRM or DMS. I wrote about that problem extensively.

ACP solved it for automotive. It wrapped every interaction into a structured envelope that carried intent signals, trade-in details, payment targets, deal stage, and conversation transcripts through every system in the stack. It worked. Dealerships using it stopped losing context between systems.

But then something happened that I did not expect.

The same problem showed up everywhere

I started talking to people outside of automotive. A friend running a healthcare startup described the exact same pattern. Their AI was generating nuanced clinical notes, and the EHR system on the other end had a dropdown menu. The AI would produce three paragraphs of carefully reasoned assessment. The EHR would accept one selection from a predefined list. Everything else got discarded.

Then I heard it from someone in commercial real estate. Their AI was analyzing property data and producing structured recommendations with confidence scores and supporting evidence. The CRM they fed it into stored a single text field. All the structure collapsed into a paragraph of plain text.

Then HR tech. Then financial services. Then insurance.

The same story, over and over. AI produces something rich and structured. A legacy system accepts something flat and simple. In between, meaning falls on the floor. Nobody logs it. Nobody measures it. Nobody even has a word for it.

I started calling it structured data loss. And once I had a name for it, I could not stop seeing it.

Why fixing it per industry does not scale

My first instinct was to build an ACP equivalent for each vertical. An ACP for healthcare. An ACP for real estate. An ACP for HR. Each one would define the specific fields and structures that industry needed to preserve during translation.

I got about two weeks into that approach before I realized it was wrong.

The problem was not that each industry needed its own field definitions. The problem was that there was no universal mechanism for wrapping structured AI output, translating it for a legacy system, and measuring what survived the translation. The fields change by industry. The translation problem is identical everywhere.

What I needed was not ten industry-specific protocols. I needed one universal protocol that any industry-specific implementation could build on top of.

That was the moment CORD became necessary.

What CORD actually is

CORD stands for Canonical Object for Relational Data. It is a domain-agnostic open protocol that does three things.

First, it wraps any AI-structured output into a standardized envelope before that output touches a legacy system. The envelope is the container. The contents can be anything. A clinical note. A customer interaction. A property analysis. A candidate assessment. The envelope does not care about the domain. It cares about the structure.

Second, it defines how that envelope gets translated when it enters a legacy system that cannot accept the full structure. Every legacy system has constraints. Field limits, type restrictions, missing relationship support. CORD maps the translation explicitly so you can see exactly what is being preserved and what is being dropped.

Third, and this is the part I think matters most, it measures the fidelity of that translation with a score.

The Envelope Fidelity Score

I call it the Envelope Fidelity Score, or EFS. It is a single number that tells you how much of the original AI output survived the handoff into a legacy system.

An EFS of 0.95 means 95% of the structured data made it through. An EFS of 0.41 means more than half was lost. The score is not a guess. It is calculated by comparing the original envelope against what the receiving system actually accepted, field by field, relationship by relationship.

This matters because right now, every company deploying AI against legacy infrastructure is experiencing structured data loss and has no way to quantify it. They cannot manage what they cannot measure. EFS gives them the number.

Think of it like uptime percentages for infrastructure. Nobody questioned whether uptime mattered. They just needed a way to measure it before they could put it in contracts and hold vendors accountable. EFS does the same thing for data fidelity in AI-to-legacy translations.

How ACP sits on top of CORD

Once CORD existed as the universal layer, ACP became a vertical implementation of it. ACP defines the specific fields that matter in automotive commerce. Intent signals, trade-in data, deal stage, payment targets, appointment context. But the envelope architecture, the translation mapping, and the fidelity scoring all come from CORD.

This is the relationship between the two. CORD is the foundation. ACP is the first building built on that foundation. Someone else could build the healthcare equivalent, the real estate equivalent, the HR equivalent, all using CORD as the underlying protocol. The domain-specific fields change. The translation infrastructure stays the same.

That was the architectural decision that made the whole thing work. Build the universal layer first, then build the vertical implementations on top of it. Not the other way around.

Why I made it open

CORD is released under the Apache 2.0 license. Anyone can use it, extend it, build on it. This was a deliberate choice and some people have asked why I would give away something I spent a year building.

The honest answer is that data standards only work if they are adopted. A proprietary translation protocol that only my products use is not a standard. It is a feature. For CORD to solve the structured data loss problem at scale, it has to be available to every company building AI-to-legacy integrations, regardless of what vendor they use or what industry they operate in.

The value I capture is not in licensing the spec. It is in being the person and the company that defined the standard and built the most advanced implementations on top of it. That is a different kind of competitive advantage. It compounds over time in ways that proprietary lock-in does not.

What this means for anyone deploying AI

If you are deploying AI in any enterprise context, you have a translation problem whether you know it or not. Your AI is producing structured output. Your legacy systems are accepting a subset of it. The difference between those two things is the silent tax you are paying on every transaction, every interaction, every decision that flows through your stack.

CORD does not fix your legacy systems. It does not replace them. It sits between your AI layer and your legacy layer and does two things: it preserves as much structure as possible during translation, and it tells you exactly how much was lost.

That is the whole idea. Not to eliminate the gap between modern AI and legacy infrastructure. That gap is going to exist for a long time. But to make the gap visible, measurable, and manageable.

I built CORD because I needed it. Then I realized everyone deploying AI needs it too. The spec is open. The problem is universal. And someone had to name it before anyone could fix it.

More at cordspec.org.