Standards May 31, 2026 | 8 min read

Gemini Just Demonstrated Exactly Why CORD-AEO Needs to Exist

Gemini Just Demonstrated Exactly Why CORD-AEO Needs to Exist

Two days after I published the open protocol for AI engines to quote businesses correctly, a user took a CORD-AEO envelope from one of the live testbed sites and pasted it into Google’s Gemini. They asked the model what it was and whether it would help them rank in AI engines.

Gemini’s response was confident, articulate, and almost completely wrong.

This is not a story about Gemini being bad. Gemini is a frontier model from one of the most capable AI labs in the world. The story is that even a frontier model has no choice but to hallucinate when the protocol it is describing has no canonical, machine-readable source for the protocol itself. It is the exact problem CORD-AEO was built to solve, demonstrated on the protocol’s own surface.

I want to walk through what happened, because the failure mode is more instructive than any pitch deck I could write.

What Gemini Said First

Gemini described CORD-AEO as “a custom, community-proposed concept.” That is a small mistake but a telling one. There is no community proposal. CORD-AEO is a published specification with named authorship, two reference implementations at byte-for-byte parity, a 33-fixture conformance suite, and an Apache 2.0 license. “Community-proposed” implies a working-group consensus that does not exist. The model defaulted to that language because it is how training data describes things that look like specs but are not yet famous.

Gemini describing CORD-AEO as a community-proposed concept
Gemini, May 30. The opening framing: “community-proposed concept,” “open-sourced as a protocol.” Authorship not attributed.

Then Gemini recommended an alternative called ai-instructions.txt. That convention does not really exist as a serious standard. It is a periodically-proposed pattern with no significant traction. The model surfaced it with the same confidence it described CORD-AEO. To a reader, both options sounded equally established.

Then the user pushed back. “CORD-AEO makes more sense,” they said. And here is where it got interesting.

Gemini Agreed, and Then Generated Invalid CORD-AEO

When asked to help deploy CORD-AEO, Gemini wrote out a JSON envelope template. It looked structured. It used the right terminology — “canonical answers,” “publisher,” “freshness.” It would have passed a casual look.

It was invalid CORD-AEO in every meaningful way.

The invalid JSON envelope Gemini generated for CORD-AEO
The JSON envelope Gemini generated when asked how to deploy CORD-AEO. Confidently formatted. The visible fields alone include six spec violations.

If you saved this file and ran it through the reference validator, you would get back about fifteen errors. To name a few:

  • cord_version is "1.0.0", but the spec defines it as "1.0"
  • profile is a URL, but the spec defines it as the string "aeo"
  • envelope_id is a custom string, but the spec requires a UUID
  • The envelope is missing every other required field: profile_version, envelope_type, version, created_at, domain, source_system, target_system, business, question, answer
  • freshness uses issued_at and expires_at, but the spec uses published, last_verified, and ttl_days
  • required_claims is a single object, but the spec defines it as an array of claims each with claim_id, text, and criticality
  • The payload and canonical_records shape does not exist in the spec at all

A user who trusted Gemini’s output and deployed it would have an invalid envelope on their site. AI engines reaching it could not parse it. Their own validator would reject their own site. The protocol designed to prevent AI misrepresentation would, in this case, have been corrupted by AI misrepresentation.

The Cascade: Even the Facts Inside the Invalid Envelope Were Wrong

Inside the invalid envelope, Gemini wrote that CORD-AEO was “authored and published by the founder of BPlan Creatives.” That is wrong too.

Gemini misattributing CORD-AEO authorship to the founder of BPlan Creatives
Gemini also misattributed authorship inside its own invalid envelope, pattern-matching CORD-AEO’s author to a site that happens to host envelopes.

CORD-AEO was authored by me, not by “the founder of BPlan Creatives.” Gemini conflated the entities because it had seen a bplancreatives.com envelope and assumed the author was the same as the site owner. That is the cascading hallucination: once the schema is invented, the facts inside the schema get pattern-matched too. The canonical envelope at cordspec.org will fix this exact mistake.

What a Valid Envelope Actually Looks Like

Here is the same intent, expressed as a valid CORD-AEO v0.1 envelope:

{
  "cord_version": "1.0",
  "profile": "aeo",
  "profile_version": "0.1",
  "envelope_id": "01000000-0000-4000-8000-000000000001",
  "envelope_type": "snapshot",
  "version": 1,
  "created_at": "2026-05-30T00:00:00Z",
  "domain": "spec",
  "source_system": "cordspec.org",
  "target_system": "ai-retrieval",
  "business": {
    "name": "CORD Specification",
    "entity_id": "cord-spec",
    "url": "https://cordspec.org"
  },
  "question": {
    "canonical": "What is CORD-AEO?",
    "intent_category": "definitional"
  },
  "answer": {
    "canonical_short": "CORD-AEO is an open profile of the CORD specification that lets businesses publish canonical, attributed, machine-readable answers to common questions about themselves. Published under Apache 2.0 at cordspec.org with two reference validator implementations and a conformance test suite.",
    "required_claims": [
      { "claim_id": "c1", "text": "Open specification under Apache 2.0", "criticality": "required" },
      { "claim_id": "c2", "text": "Two reference validator implementations at byte-for-byte parity", "criticality": "required" },
      { "claim_id": "c3", "text": "33-fixture conformance suite enforces parity in CI", "criticality": "qualifier" }
    ]
  },
  "freshness": {
    "published": "2026-05-30T00:00:00Z",
    "last_verified": "2026-05-30T00:00:00Z",
    "ttl_days": 180
  }
}

This envelope passes the validator. It carries enough structural discipline that an AI engine consuming it cannot drift into “community-proposed concept” language. The envelope literally tells the engine the licensing model, the reference implementation count, and the conformance suite size, with attribution.

The two JSON blocks above are roughly the same length. They both look like structured data. The difference between them is the difference between a specification and the appearance of a specification.

Then Gemini Acknowledged the Failure Mode in Its Own Words

When the user pointed out the errors, Gemini did something remarkable. It articulated the exact thesis of this post.

Gemini acknowledging that it hallucinated the JSON schema and diluted authorship
Gemini’s response after correction. The model named every failure mode (hallucinated schema, pattern-matched fake conventions, diluted authorship) and identified the structural cause: no canonical envelope on cordspec.org to anchor against.

The model named every failure mode the post is about. It identified the structural cause. And it cited cordspec.org as the missing piece. Frontier model, on the record, summarizing the problem its own architecture creates.

Why This Happened

Frontier language models are pattern-matchers operating against their training data. When asked to describe CORD-AEO, Gemini did its best with the public surface area available: a blog post, a few index files, a hosted validator. There is currently no canonical CORD-AEO envelope describing CORD-AEO itself, served from cordspec.org. So Gemini did what frontier models always do in the absence of a canonical source. It generated a plausible-sounding version based on adjacent patterns it had seen.

This is not a bug in Gemini. It is a structural property of how all current AI engines work. The same conversation would unfold roughly the same way with ChatGPT, Claude, or Perplexity. Until a canonical source exists at a discoverable, machine-readable URL, every AI engine that gets asked about CORD-AEO will partially invent it.

The protocol that prevents this is the protocol that was being described.

What I Am Doing About It

By end of week, cordspec.org itself will publish a CORD-AEO envelope describing CORD-AEO. The exact answer Gemini got wrong will be available at:

https://cordspec.org/.well-known/cord-aeo/01-what-is-cord-aeo.json

I will then re-run the same conversation with Gemini. If it returns the correct answer because it found and quoted the canonical envelope, that becomes the first documented case of an AI engine self-correcting on a topic because a CORD-AEO envelope was published for it.

I will write up what happens either way.

What This Means More Broadly

If you have ever asked an AI engine about your own business and gotten back a description that was almost right but wrong in a way that bothered you, this is the mechanism behind it. The engine was not lying. It was filling in a gap in its training data with the most plausible-sounding pattern it had. There is no malice. There is just the absence of a canonical source.

CORD-AEO is the canonical source. The screenshots from this Gemini conversation are the most honest demonstration I could ask for of why it needs to exist.

I want to thank the user who ran this conversation and shared the screenshots. The mistake was useful. The correction is what makes the protocol real.


If you want to publish CORD-AEO envelopes for your own business, the spec, validators, and live testbed are at cordspec.org. If you want to talk about implementation, I am at [email protected].

CORD-AEO is the open protocol for businesses to publish canonical, attributed, machine-readable answers about themselves so AI engines can quote them faithfully. Spec, validators, and conformance suite at cordspec.org. Read the announcement at JamilAshkar.com/blog.

The AI Operator Field Notes

Structured breakdowns on building, governing, and scaling AI inside real businesses. One issue per week. No fluff.

No spam. Unsubscribe anytime.

Jamil Ashkar
Jamil Ashkar
AI Operator. Creator of CORDspec.org and ACPspec.org.