Why I Authored CORD-AEO: The Gap I Could Not Stop Seeing

The moment I knew this protocol had to exist was a Tuesday afternoon in early 2026.

I was helping a friend run her three-person consultancy through a positioning exercise. We were checking how AI engines described her business. We asked ChatGPT, Claude, Perplexity, and Google's AI the same question. What does Northgate Advisory do?

We got four different answers. None of them were wrong exactly. None of them were quite right either.

One had her pricing model from two years ago. One mentioned a service line she had retired in 2024. One mixed her bio with the bio of another consultant whose name was similar. One was clean on her services but invented a client roster that did not exist.

She had no way to correct any of it. She could update her website. She could publish more blog posts. She could rewrite her about page. None of that would tell the model: here is the canonical answer. Quote this. Stop guessing.

That is when I started building CORD-AEO.

What CORD-AEO Actually Is

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

CORD-AEO is the first published profile of CORD. AEO stands for Answer Engine Optimization. The profile 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.

It works simply. A business serves a directory at /.well-known/cord-aeo/ on its website. Inside that directory, the business publishes one JSON file per canonical question. The file holds five things. The question. The canonical short answer. The required claims that must survive any paraphrase. The verification metadata. A Schema.org JSON-LD bridge so today's crawlers can read it natively.

That is the protocol. Five things in a file. The complexity is in the design decisions, not the format.

Why Existing Standards Were Not Enough

The first thing I did when I saw the gap was check whether someone had already solved it. Three things came close. None of them did the actual job.

Schema.org. Schema.org is incredible work. It is the reason structured data exists on the web. Dan Brickley and the Schema.org working group built infrastructure that has shaped how the web describes itself for fifteen years.

But Schema.org is built for general structured data. Organization, Person, Product, FAQPage, and so on. It tells a search engine what something is. It does not tell an AI engine the canonical answer to quote when asked. The closest type is FAQPage. It gives you question-answer pairs. It does not have required claims. It does not have a fidelity score. It does not have verification metadata. It does not tell the engine, this is the truth, do not paraphrase it past these boundaries.

llms.txt. The llms.txt convention is useful. It gives crawlers a hint about what content to focus on when they index a site. But llms.txt is a hint about what to read. It is not a structured contract about what to say. A model that reads an llms.txt file still has to interpret the prose underneath. The interpretation is where the fidelity is lost.

Robots.txt and sitemap.xml. Older infrastructure. Tells crawlers what to index. Tells nothing about how to represent the indexed content.

The gap was specific. There was no protocol for a business to say, here is the exact canonical answer to this exact question, here are the claims that must survive any paraphrase, here is when it was last verified, here is how to score whether your reformulation preserved the truth.

So I built that protocol.

The Principle Underneath

The principle behind CORD-AEO is the same principle behind CORD core. Fidelity is something you design, not something you wish for.

CORD core solves fidelity in one direction. AI-generated data leaves a model in rich, structured form. It passes through legacy systems. By the time it lands, fields are dropped, types are coerced, context is stripped. CORD wraps that data in an envelope that preserves structure across the trip and measures what survived with an Envelope Fidelity Score.

CORD-AEO solves fidelity in the other direction. Information about a business sits on its website in rich, prose form. An AI engine reads it. It builds an internal representation. By the time the engine answers a user's question, facts are dropped, positioning is flattened, context is stripped. CORD-AEO wraps that information in the same envelope. Same fidelity preservation. Same score. Calculated for answer fidelity instead of data fidelity.

Same principle. Two directions. One protocol architecture.

That symmetry was the moment I knew the profile pattern was the right way to extend CORD over time. Each domain gets its own profile. The core spec stays universal. The profiles solve specific fidelity problems with the same underlying envelope structure.

Why I Made It Open

I thought about whether to keep CORD-AEO proprietary. The answer was no. The reason matters.

The value of a closed protocol is small. The value of an open protocol is large because adoption multiplies the value. Schema.org is not owned by anyone in particular and yet it is the structured data layer of the entire web. JSON Schema is not owned by anyone either and yet it is the validation layer of every modern API.

The value of being the author of an open protocol is that you become the person the industry talks to when questions come up. Brickley shaped Schema.org. The JSON Schema authors shape that spec. The CORD authors shape CORD.

If I kept CORD-AEO proprietary, the protocol would have been a feature in a product. As an open spec, it can become infrastructure.

That is a much larger outcome.

The Honest Status

I want to be precise about where CORD-AEO is right now.

The v0.1 specification is published. The reference validators in Python and PHP are at byte-for-byte parity on 33 conformance fixtures. The Python validator installs with pip install cord-aeo-validator. The hosted validator at cordspec.org/aeo/validate is live. The GitHub repository is at github.com/cord-spec/cord-spec.

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.

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 also not claiming this is a finished standard. v0.1 means v0.1. It is stable enough to build on. The spec process is open. Pull requests welcome. The conformance gate keeps both reference implementations in parity, which keeps the door open without being chaotic.

Why I Am Writing This Post

Last week I published the CORD-AEO announcement. The next obvious post would have been the implementation guide. I wrote the implementation guide. It is the next piece in this series.

But before the how, I wanted to write the why. The reason matters because protocols that catch are protocols that solve problems people already know they have. CORD-AEO solves a problem most businesses have not named yet. Their AI engine descriptions are wrong, they cannot fix it, and they have decided that is just how the new world works.

It does not have to be.

If you read your own AI engine answers and felt that something was off but could not name what, this protocol is for you. If you have not read your AI engine answers, that is your first move. Open ChatGPT. Ask what your business does. Read the answer. Tell yourself the truth about how much of it is right.

The next post in this series walks through how to implement CORD-AEO on your own site, step by step. The post after that gives you a complete sample envelope you can adapt for your business.

This protocol exists because I could not stop seeing the gap. If you can see it too, it exists for you.

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, including the data and citation fidelity layers most companies skip. Explore the full framework at JamilAshkar.com/framework. Start with the free course at JamilAshkar.com/course.