I Built an Open Protocol so AI Engines Can Quote your Business Correctly

A few weeks ago I noticed something that bothered me.

I asked four different AI engines the same question about a friend's business. I got four different answers. None of them were wrong exactly. None of them were quite right either. Outdated pricing. A product that had been sunset. A founding story remixed from two different sources. The kind of mistakes that do not look like mistakes until you know the truth.

This is happening to every business right now. Schema.org exists for general structured data. The llms.txt convention exists for crawler hints. But no protocol exists that says, here is the exact short answer to this exact question, here are the claims that must survive any paraphrase, here is when it was last verified.

So I built one. It is called CORD-AEO, and as of this week the v0.1 specification, both reference validators, and the conformance test suite are open source under Apache 2.0.

What Is CORD-AEO?

CORD is the open protocol I authored earlier this year for translating AI-generated structured data into legacy systems without losing fidelity. It stands for Canonical Object for Relational Data. The full spec lives at cordspec.org.

CORD-AEO, short for Answer Engine Optimization, is the first published profile of CORD. It does one specific thing. It lets a business publish machine-readable canonical answers to common questions about itself, in a way AI engines can fetch, verify, and quote faithfully.

How Does It Work?

The mechanism is simple. You serve a directory at /.well-known/cord-aeo/ on your website. Inside that directory you put one JSON file per canonical question. What does our company do. What is our pricing model. Who founded this. Whatever questions matter for your business.

Each file contains five things.

The question. And common variants of how the same question gets asked.

The canonical short answer. The way you want it quoted.

The required claims. The facts that must survive any paraphrase.

The verification metadata. When it was published, when it was last verified, how long it should be trusted.

A Schema.org JSON-LD bridge. So today's crawlers can read it natively while the protocol is gaining adoption.

How Is Fidelity Measured?

The fidelity is not a vibes-based thing. There is a metric. The Envelope Fidelity Score (EFS). It is a number between 0 and 1 that quantifies how much of your canonical answer survived when an AI engine paraphrased it.

You can score an engine's response against your canonical answer. Over time, you can tell which engines represent your business well and which ones do not. That is data you can act on. Without a protocol layer, that data did not exist.

Why This Is Bigger Than It Sounds

The thing that makes Schema.org work for search is that everybody uses it. The thing that has to happen for CORD-AEO to work for AI engines is the same. Adoption beyond me.

I want to be careful here. As of today, the production deployment count for CORD-AEO is exactly one. My own site, jamilashkar.com, is the live testbed. That is a credible architecture demonstration, not market traction.

But the building blocks are in place for it to spread. The spec is published. The reference validators in Python and PHP are both at byte-for-byte parity on 33 conformance fixtures, with CI enforcing that parity on every commit. The Python validator installs with one command. pip install cord-aeo-validator. There is a hosted web validator at cordspec.org/aeo/validate where anyone can paste a domain and get a conformance report. Anyone. No registration. No API key. No licensing fee.

If you are a business that is tired of watching AI engines describe you inaccurately, you can publish CORD-AEO envelopes today. The publishing kit is in the GitHub repo with a sample .htaccess, an llms.txt template, and a Schema.org bridge generator.

What I Am Not Claiming

A few things this post is deliberately not saying.

I am not claiming AI engines consume CORD-AEO natively yet. They do not. Today, the protocol's value comes from the Schema.org JSON-LD bridge that every CORD-AEO envelope carries inline. That is what crawlers can read right now. Protocol-native consumption is what happens when at least one major engine commits to fetching .well-known/cord-aeo/ directly. That is a real conversation to start, not a foregone conclusion.

I am not claiming this is a finished standard. v0.1 means v0.1. It is stable enough to build on, but the spec process is open. Pull requests welcome. Discussion threads welcome. The conformance gate, any change has to keep both reference implementations in parity, keeps the door open without being chaotic.

I am not claiming this is the only way to do this. It is one structured way. The alternative is leaving it to scrapers and prompt engineering forever, which is the current default and which I think will increasingly look unacceptable as the cost of AI misrepresentation goes up.

Why I Am Not Keeping This Proprietary

I thought about whether to keep this private. The answer is no, and the reason matters.

The value of an open protocol is that everyone can use it. The value of being the author of an open protocol is that you become the person the industry talks to when questions come up. Schema.org is not owned by anyone in particular, and yet Dan Brickley and the Schema.org working group have shaped how the web describes itself for fifteen years. JSON Schema is not owned by anyone either, and yet its authors are who you call when the spec needs to evolve.

I want CORD-AEO to be the way the answer-engine layer of the web gets organized. That goal is incompatible with charging for the spec. It is also incompatible with hiding the implementation. The validators are reference implementations precisely so other people can build their own and check them against the conformance suite. The hosted validator is free because the validator is the thing that makes the protocol enforceable.

What I am building privately is the work that sits on top of the protocol. Products that help businesses generate, deploy, monitor, and improve their CORD-AEO envelopes over time. Open spec, open validators, proprietary tooling for serious users. That is the same pattern Red Hat used for Linux, MongoDB used for the database, HashiCorp used for Terraform. It is a model that works because the open layer creates the gravity that makes the commercial layer valuable.

What Happens Next

I want to be honest about where this is on the maturity curve. We are at the beginning. Here is what I think the next twelve months look like if this goes well.

A second publisher unrelated to me ships CORD-AEO envelopes on their site. That is when it stops being Jamil's format and becomes a spec.

At least one analyst names the category in a public note. I have a few I am in conversation with.

One AI engine signals interest in native consumption. The bridge architecture means the protocol works without that, but it is the moment that changes the trajectory.

The v0.2 spec ships, incorporating feedback from real adopters.

Where to Look

If you are a builder, a business owner, an analyst, or just someone who finds this kind of infrastructure interesting, here is where to look.

• Specification: cordspec.org
• AEO profile: cordspec.org/aeo
• Live testbed: the /.well-known/cord-aeo/ directory on this site
• Hosted validator: cordspec.org/aeo/validate
• GitHub: github.com/cord-spec/cord-spec

If you want to talk about implementing CORD-AEO for your own business, or if you have feedback on the v0.1 spec, my email is in the contact section of this site. I read everything.

This is the kind of thing that either becomes infrastructure or does not. The work going forward is to make sure it does.

Structure before tools. Strategy before speed. Systems before scale.

The AI Operator Framework is the methodology for designing, governing, and scaling AI operations inside a business. Explore the full framework at JamilAshkar.com/framework. Start with the free course at JamilAshkar.com/course.