Why Schema.org and JSON-LD Are Not Enough for AI Handoffs

The most common pushback I get when introducing CORDspec to a technical audience is the same. We already use Schema.org. We already use JSON-LD. Why is that not enough.

This post is the answer. The short version is that Schema.org and JSON-LD are foundational layers and necessary, but they do not address the contract problem between AI systems. The long version is below.

What Schema.org Does

Schema.org is a vocabulary. It defines types like Organization, Person, Product, Service, Event. Each type has properties. The vocabulary lets a publishing system describe the structure of its data in terms a consuming system can recognize.

An Organization has a name, a URL, a logo, a number of employees, a founding date. A Product has a SKU, a price, an availability status, a brand. Schema.org provides the shared vocabulary that makes structured data interoperable between systems.

This is genuinely useful. Schema.org is on ten million sites. Search engines depend on it. Many AI engines consume it as a signal during inference. If you are not using Schema.org for the parts of your data that fit its vocabulary, you should be.

None of that addresses the AI handoff contract problem.

What JSON-LD Does

JSON-LD is a serialization format. It carries Schema.org or other vocabulary terms in a JSON-shaped payload. It adds context (the @context field) that tells consumers which vocabulary the payload uses. It allows linked data graphs to be represented in a format that JSON parsers can handle without specialized libraries.

JSON-LD is great for what it does. It does not add semantic guarantees beyond what the underlying vocabulary provides. It does not provide lineage. It does not provide fidelity measurement. It is a transport layer with a context annotation.

The Five Things Schema.org and JSON-LD Do Not Cover

One. Schema versioning for evolving AI outputs. Schema.org evolves slowly. AI model outputs evolve quickly. When a model version changes its output distribution, the JSON-LD that describes the output does not change. A receiving system reads the same JSON-LD shape and consumes the new outputs as if they were the old outputs. The semantic drift is invisible to the schema layer.

Two. Confidence and uncertainty annotation. Schema.org has no native concept of confidence. An AI system that produces a "Person" record with 0.2 confidence and an AI system that produces a "Person" record with 0.99 confidence emit identical Schema.org structures. The receiving system has no way to distinguish them. The contract layer should preserve confidence. Schema.org does not.

Three. Provenance and lineage. JSON-LD has the dcterms:source property and similar provenance fields. These are optional. They capture immediate source but not the full chain. A four-system pipeline produces an output whose Schema.org annotation might name the immediate predecessor system, but not the system that produced that system's inputs, or the model version, or the timestamp, or the upstream contract version. The lineage chain decays at every hop.

Four. Required claim contracts. Schema.org describes structure. It does not describe what must be preserved. A producing system has no way, in Schema.org, to declare "this Organization record must preserve the employee count, the founding date, and the headquarters location if you transform it." The receiving system has no way to verify whether those facts survived. The contract is absent.

Five. Fidelity measurement. Schema.org has no measurement layer. There is no equivalent of an Envelope Fidelity Score. A receiving system cannot tell whether the transformation it just applied preserved the meaningful content or destroyed it. The producing system cannot audit the chain to see where its content degraded.

What This Looks Like in a Real Pipeline

Consider a B2B sales intelligence system. Three AI components.

Component A. A model that extracts company information from public sources. It emits Schema.org Organization records with JSON-LD context. Field-level validation passes. Names, URLs, employee counts, founding dates.

Component B. A model that scores each company for fit against a target buyer profile. It consumes the Organization records and emits enriched records with a fit score added.

Component C. A model that drafts personalized outreach for high-fit companies. It consumes the scored records and produces email drafts.

Every handoff between A, B, and C is valid Schema.org JSON-LD. Every field type matches. Every shape conforms.

What breaks. Component A updates its extraction model. The new model produces employee counts that are interquartile estimates rather than current-employee headcount. The number 287 used to mean "Company has 287 current employees." Now it means "Company likely has between 240 and 340 current employees." Same field. Same type. Different meaning.

Component B does not know. It scores the company the same way. Component C does not know. It drafts emails referencing the headcount as a specific fact. The recipient knows their company has 412 employees and concludes the sender did not do their research.

The Schema.org layer was intact through every handoff. The contract layer was not.

Where Schema.org and CORDspec Coexist

I want to be specific about this because it is the most common misunderstanding.

CORDspec does not replace Schema.org. Every CORD envelope can carry a Schema.org JSON-LD payload. The CORD layer wraps the Schema.org payload with the additional contract metadata that Schema.org does not provide. Schema versioning. Confidence annotation. Lineage. Required claims. Fidelity measurement.

A system reading the envelope can extract the Schema.org payload and use it for the things Schema.org is good for. The same system can also consult the CORDspec metadata to know whether the payload's meaning has drifted, where it came from, what was supposed to be preserved, and whether the transformation chain has maintained fidelity.

Both layers do their jobs. Neither tries to do the other's job.

The Honest Limits

Three things I want to name directly so this post does not read as an overclaim.

CORDspec does not make Schema.org obsolete. If your data fits Schema.org's vocabulary and you do not yet publish JSON-LD on your site, you should add it before considering CORDspec. The foundational layers come first.

CORDspec adoption today is early. The protocol works. The validator runs. CORD-AEO has been recognized by four major engines. The number of production AI-to-AI pipelines using CORDspec's contract features at scale is still small.

The benefit of CORDspec compounds. A pipeline that uses CORDspec between two AI systems gets some value. A pipeline that uses CORDspec between five AI systems gets more than five times the value because the lineage and fidelity measurement layers become more useful as the chain lengthens.

What This Means for Architectural Decisions

Three things to consider if you are designing an AI pipeline today.

One. If you only need single-handoff AI integration and the handoff is between systems you control end-to-end, JSON-LD with Schema.org is probably sufficient. Add CORD when the pipeline grows.

Two. If your pipeline has more than two AI components handing off to each other, you already have the contract problem. JSON-LD does not solve it. The cost of retrofitting CORDspec increases with every new component you ship without a contract layer.

Three. If your AI systems will eventually need to interoperate with vendor AI systems, partner AI systems, or external AI services, the contract layer becomes non-negotiable. Without it, every integration is bespoke. With it, the protocol does the integration work.

Where the Series Goes Next

The next post in the series is the failure mode catalog. Five specific patterns that break AI pipelines without contract layers. Each one is a thing I have watched happen in production. Each one is preventable with a CORDspec envelope.

If you are reading this and recognizing failure patterns in your own pipelines, my calendar is open for advisory conversations. The work is helping you think about the architecture before the failures force a retrofit. Not selling a fix.

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.