CORD (Canonical Object Relational Data) and ACP (Automotive Commerce Protocol) are two open standards I authored to fix how artificial intelligence moves structured data through real businesses. CORD is universal. It defines a canonical object shape that AI outputs can travel through without silent truncation or loss. ACP is domain-specific. It standardizes the data exchange between automotive dealers, OEMs, and the AI systems sitting between them. Together they close the silent gaps that kill most AI deployments in production.
I did not set out to write open standards. I set out to ship AI products that actually worked.
What I learned across four products is that the hardest part of operating AI in a real business is not the model. It is the data layer underneath it. AI outputs would arrive clean. Three integrations later they would be missing fields, truncated values, or silently reshaped. Nothing crashed. Nothing alerted. The data just got worse.
I went looking for an existing standard that handled this. There was not one. So I wrote CORD. Then I wrote ACP for my own industry. This post explains what they are, why they exist, and why every business operating AI at scale will eventually need both.
What Is CORD?
CORD stands for Canonical Object Relational Data. It is an open standard for representing AI-generated structured data so that the data can travel through any system without silent loss.
The problem CORD solves is what I call structured data loss. AI models produce clean, rich, structured output. That output then has to travel through CRMs, marketing platforms, internal databases, and reporting tools. At every hop, fields can be dropped, types can be coerced, and arrays can be flattened. Most legacy systems were never built to preserve the shape of the data passing through them.
CORD defines a canonical object shape with three things. First, a stable schema that any system can validate against. Second, a fidelity score that travels with the object, so any consumer can tell at a glance whether the data has been degraded. Third, a versioned envelope so that the shape itself can evolve without breaking downstream readers.
You can read the full specification at CORDspec.org.
The intellectual ancestor: Claude Shannon
The conceptual root of CORD goes back to Claude Shannon and his 1948 paper on information theory. Shannon proved that signals degrade as they pass through channels, and that you can measure the degradation. He gave the world a way to think about the difference between signal and noise.
CORD applies the same idea to structured business data. Every system an AI-generated object passes through is a channel. Every channel introduces loss. Before CORD there was no way to measure the loss. CORD makes it measurable. That is the whole point.
What Is ACP?
ACP stands for Automotive Commerce Protocol. It is an open standard for how data moves between automotive dealers, original equipment manufacturers (OEMs), and the AI systems sitting between them. ACP is patent pending and domain-specific to automotive retail.
Anyone who has worked in automotive knows the data layer is broken. Dealer Management Systems do not talk cleanly to CRMs. CRMs do not talk cleanly to OEM portals. OEM portals do not talk cleanly to anyone. Each integration is bespoke. Each integration silently drops information.
Now layer AI on top of that mess. The AI produces clean structured output. The output has to travel through three or four broken integrations before it lands somewhere useful. By the time it arrives, half the value is gone.
ACP standardizes that exchange. It defines the object types automotive AI needs to move (leads, vehicles, deals, service events, customers) and how those objects should be shaped, versioned, and validated as they cross system boundaries. You can read the full specification at ACPspec.org.
Why CORD Is Universal and ACP Is Not
CORD is universal because the problem it solves is universal. Every industry has structured data loss. Healthcare has it. Finance has it. Logistics has it. Retail has it. The specifics differ. The pattern is identical.
ACP is domain-specific because automotive has its own object types, its own regulatory environment, and its own century of legacy systems that have to be accommodated. You cannot write a generic standard that captures what a vehicle deal looks like in retail automotive. You have to write a specific one. That is what ACP is.
The two standards are complementary. ACP defines automotive object shapes. CORD defines how any object shape, including ACP objects, travels through systems with its fidelity intact. ACP rides on top of CORD in automotive deployments.
This pattern is going to repeat. Healthcare will need its own ACP equivalent. Finance will need its own. The universal envelope (CORD) stays the same. The domain-specific shapes change. That is the architecture.
Why I Wrote CORD
I wrote CORD because I got tired of debugging the same problem. Every AI deployment I shipped hit the same wall. The model produced great output. The output got worse the further it traveled. Nobody on the integration side could tell me where the loss was happening because nobody had ever measured it.
The breaking point was a deployment where the AI was tagging leads with rich attributes: intent score, vehicle interest, financing readiness, preferred contact method, urgency. The CRM accepted the lead. By the time the BDC agent saw it, only two of those five fields had survived. The AI looked broken. It was not broken. The data layer between the AI and the human had quietly thrown away three fields.
That was the day I decided the data layer needed to be specified. Not assumed. Not bolted on. Specified at the same level of rigor as the model itself.
Why I Wrote ACP
I wrote ACP because the automotive industry is going to be one of the first places AI gets deployed at real scale, and the existing data infrastructure is not ready for it.
Dealers run on a combination of DMS, CRM, marketing platforms, OEM connections, and increasingly AI tools. Every one of those systems has its own data model. None of them agree. When AI tries to sit across all of them, the AI is the one that gets blamed when the data is wrong, even though the AI did its job.
ACP gives the industry a shared shape. Once dealers, OEMs, and AI vendors agree on what a lead looks like, what a vehicle inquiry looks like, what a service event looks like, the AI stops being the scapegoat for upstream data problems. The data layer becomes accountable.
The other reason is the obvious one. I have spent twenty years in automotive. I know where every bolt is buried. If anyone was going to write this standard, it had to come from someone who had actually sold cars, run a dealership, and shipped automotive software. That is me.
What Is Structured Data Loss?
Structured data loss is the silent degradation of structured information as it passes through systems that were not designed to preserve its shape. It is the problem CORD exists to solve.
Here is what it looks like in practice. The AI outputs a JSON object with twelve fields. The object hits the first integration. The integration only knows about eight of those fields. It silently drops the other four. The object continues to the next system. That system flattens an array because its database schema does not support nested objects. The object reaches its final destination with seven fields and a flattened array.
Nothing crashed. Nothing alerted. The data just got worse. This is happening in every AI deployment that does not have an explicit data layer standard.
I have written about this extensively. The original explainer is What Is Structured Data Loss. The companion piece on why CORD solves it is here.
What Is the Envelope Fidelity Score?
The Envelope Fidelity Score is a number that travels inside every CORD object. It represents the percentage of the original object that survived intact through every system it passed through. A perfect fidelity score is 100. A degraded object might arrive with a fidelity score of 73, meaning roughly a quarter of its information was lost or coerced in transit.
The reason fidelity has to be a number, not a flag, is that loss is rarely binary. Sometimes one field is dropped. Sometimes a numeric field gets cast to a string. Sometimes a nested object gets flattened. None of those crash. All of them degrade the data. A score captures the cumulative effect.
Once you have a fidelity score, you can do something with it. Set thresholds. Block low-fidelity data from reaching critical systems. Alert when fidelity drops below a baseline. Most importantly, prove to leadership that your AI is not the problem. The data layer is.
How Does ACP Standardize the Dealer-to-OEM Exchange?
ACP defines a canonical set of automotive object types and a canonical way to move them between systems. The dealer side, the OEM side, and any AI vendor sitting between them all agree to the same object shapes.
A lead in ACP has a defined shape. A vehicle inquiry has a defined shape. A service event has a defined shape. Each one has required fields, optional fields, validation rules, and a version. Any system implementing ACP knows exactly what it is going to receive and exactly what it must produce.
This is not new in concept. The auto industry already has data standards for other purposes. ADF for lead exchange. STAR for service. What it does not have is a standard built for the AI era. AI-generated objects are richer, more nuanced, and more easily destroyed by legacy integrations than anything previous standards anticipated. ACP is built for that reality.
Why existing automotive standards are not enough
ADF was written for a world where leads were sent by email parsing. STAR was written for a world where service data moved between two systems at a time. Neither was built to carry AI-generated metadata. Neither has a fidelity layer. Neither survives the modern AI workflow without modification.
ACP picks up where they left off. It can wrap ADF and STAR payloads where backward compatibility matters. It adds the AI-specific shape and the CORD envelope on top. Old standards keep working. New standards make AI accountable.
How Does CORD Apply Outside Automotive?
CORD is industry-agnostic. The principles apply anywhere AI is producing structured output that has to travel through legacy systems.
In healthcare, CORD can wrap clinical AI outputs so that downstream EHR systems either preserve the full object or surface the fidelity loss. In finance, CORD can wrap AI-generated risk scores and trade rationales so that they do not get silently truncated on their way to compliance systems. In logistics, CORD can wrap AI-generated routing decisions so that delivery systems can validate the shape of what they received.
The universal piece is the envelope. The fidelity score. The versioned schema. None of that is industry-specific. Every industry needs it. Most industries do not know they need it yet.
Why Open Source the Standards?
I open-sourced both standards because closed standards do not become standards. They become vendor lock-in.
For CORD and ACP to do their job, every system in the chain has to implement them. That only happens if the spec is free to read, free to implement, and free to extend. If I tried to keep these proprietary, every vendor would either refuse to support them or build a half-compatible version. The data layer would stay broken.
Open also means the standards can be improved by the community. I am not the only person who has seen these problems. Other operators have run into the same walls. Open-sourcing the spec lets them contribute, fork, and push the standards forward in ways I could not do alone.
The patents on ACP exist for protection of the original architecture, not to restrict implementation. The reference implementation is open. The spec is open. Anyone can build on it.
How CORD and ACP Work Together
CORD is the envelope. ACP is the contents.
In an automotive AI deployment, an AI-generated lead is shaped as an ACP Lead object. That object is wrapped in a CORD envelope with a fidelity score, a version, and a schema reference. The wrapped object travels through systems. Each system reads the CORD envelope to know what shape to expect. Each system updates the fidelity score if it had to coerce or drop anything. The final consumer receives the ACP Lead with a CORD envelope that tells the full story of what happened in transit.
That is the model. Domain-specific contents. Universal envelope. Together they make AI-generated data trustworthy across system boundaries.
What Does Adoption Look Like?
Adoption of an open standard is never linear. It happens in three phases.
Phase one. Reference implementations. A handful of operators implement the standard in their own products to prove it works. This is where CORD and ACP are now. My own products use them. A small number of early implementers are running them in production.
Phase two. Ecosystem pickup. Vendors start implementing the standard because their customers ask for it. This is when the standard starts to compound. Each new implementer makes the standard more useful for everyone else already on it.
Phase three. Default state. The standard becomes the assumed shape. New systems are designed around it from day one. Legacy systems get retrofitted because the cost of not supporting it exceeds the cost of supporting it.
The goal is phase three. The work right now is phase one to phase two. That is why I am writing publicly about both standards, opening the specs, and shipping reference implementations inside my own products.
What Does This Mean for AI Operators?
For anyone running AI in a real business, here is the practical takeaway.
If you are operating AI and you do not have an explicit data layer standard, you are losing value at every system hop and you do not know how much. Pick a standard. Use CORD if your domain is general. Use a domain-specific standard like ACP if one exists. Build one if it does not.
The standards layer is not optional. It is the difference between AI that compounds value and AI that decays it.
Where to Go From Here
Read the specs. CORDspec.org for the universal envelope. ACPspec.org for automotive object types. Both are open. Both are versioned. Both can be implemented today.
If you want the operating context for why these standards matter, read The AI Operations Playbook for the larger system around AI. Read What Is Structured Data Loss for the specific failure mode CORD addresses.
The data layer is the thing nobody wants to look at. It is also the thing that decides whether your AI deployment compounds or decays. Look at it. Specify it. Make it accountable.
Final Thought
AI gets all the attention. The data layer gets none. That is going to flip in the next two years. The companies that win will be the ones that fixed the data layer while everyone else was distracted by the model. CORD and ACP are my contribution to that fix. Use them. Improve them. Or write something better. The point is to stop pretending the problem does not exist.
Want the full system? The AI Operator Playbook ($499) is the operating manual I use to deploy AI across real companies. Structure, governance, and scale documented end to end.
Structure before tools. Strategy before speed. Systems before scale.
Ready to operationalize AI inside your business?
The AI Operator Framework is the system I use to design, govern, and scale AI for real companies. Start with the AI Operator Playbook ($499) or apply to work with me directly.
