How to Validate Your CORD-AEO Implementation Before Going Live
You wrote your first envelope. You uploaded it. Now you need to know it works.
The hosted validator at cordspec.org/aeo/validate is the primary tool. This post walks through what the validator actually checks, how to read its output, and the secondary checks the validator does not catch.
What the Validator Does
Three checks. Always in the same order.
One. Fetch and parse. The validator hits your domain at /.well-known/cord-aeo/index.json. If the file is not there, validation stops. If the file is there but not valid JSON, validation stops.
Two. Structural conformance. For each envelope listed in your index, the validator fetches the envelope file and checks that every required field is present, every field has the right type, and the envelope follows the v0.1 spec.
Three. Bridge validation. The validator extracts the Schema.org JSON-LD bridge from each envelope and runs it against Schema.org's own validator. Bridge errors here mean engines that read your envelope through the Schema.org path will get malformed data.
The output is a per-envelope report. Pass or fail for each check. Explicit error messages when something fails.
How to Read a Failed Report
Validation failures fall into four categories.
Fetch errors. The validator could not retrieve your index or one of your envelopes. The fix is hosting configuration, not envelope content. Check that your .well-known directory is publicly accessible. Check that JSON files are served with the right MIME type. Check that your domain has no robots.txt or firewall rule blocking the well-known path.
Structural errors. Your envelope has a problem. Missing required field. Wrong type on a field. Field name misspelled. The error message names the specific field and the specific problem. The fix is editing the JSON.
Bridge errors. Your Schema.org JSON-LD inside the envelope is malformed. Missing @context, wrong @type, or a field that does not exist on the Schema.org type you used. The fix is correcting the Schema.org block. The Schema.org validator at validator.schema.org can help debug.
Fidelity warnings. The validator computes a baseline Envelope Fidelity Score for each envelope. The baseline is the score the envelope could achieve under perfect paraphrase. If the baseline is below 0.85, the validator returns a warning. The envelope is structurally valid but the canonical answer or required claims are weak enough that even ideal paraphrase loses fidelity.
The Order of Operations
Run the validator in this order.
First validation. Before you announce anything. Fix every structural error.
Second validation. After fixing structural errors. Fix every bridge error.
Third validation. After fixing bridge errors. Address every fidelity warning.
Final validation. After everything else. Should show clean across all checks.
Do not skip ahead. Bridge errors are sometimes caused by structural errors that get masked. Fix the foundation before you debug the higher layers.
The Secondary Checks the Validator Does Not Catch
The hosted validator covers protocol conformance. It does not cover three things you should check yourself.
Content accuracy. The validator does not know whether your canonical answer is true. It checks structure. You check facts. Read every published envelope. Verify every claim is currently accurate. Update last_verified to today's date.
Cross-envelope consistency. If you publish three envelopes and they contradict each other, the validator does not catch it. A pricing envelope that says "$15,000" and a services envelope that says "pricing starts at $25,000" is a problem only a human catches. Cross-check.
External link health. If your envelope references external URLs (publisher_url, verification URLs, certification links), check that those URLs resolve. The validator does not crawl external links.
The AI Engine Test
The protocol validator tells you the envelope is structurally correct. It does not tell you whether AI engines are actually reading it.
Run this manual check after every publish or update.
Open ChatGPT, Claude, Perplexity, and Google AI. Ask each one your canonical question. Read each response.
Compare to your canonical answer. Note three things.
Which required claims survived in each response?
Which were dropped or distorted?
Which engine represents you most accurately?
Record the baseline. Repeat the check monthly. The trend over time tells you whether the protocol is delivering value for your business.
What Validation Does Not Replace
Three things validation cannot do for you.
It cannot tell you whether you wrote a good canonical answer. The canonical is your decision. The validator scores structure.
It cannot tell you whether your canonical questions are the right questions for your business. Question selection is your decision. The validator processes whichever questions you publish.
It cannot tell you whether AI engines will adopt the protocol natively. Adoption is a market question, not a validation question.
The validator is a conformance tool. Strategy is yours.
When to Re-Validate
Three triggers.
Every update. Anytime you change an envelope, re-validate. Small edits introduce typos. The validator catches them before publication.
Quarterly. Even without changes, validate quarterly. The hosted validator gets updates. New checks get added. An envelope that passed in v0.1.0 might warn in v0.1.2.
Before announcing adoption. If you write a post saying you publish CORD-AEO, validate that morning. The credibility cost of a public claim that fails validation is high.
The validator is free to run. Run it more than you think you need to.
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.
