A Field Name Is a Rumor

Give a capable model two schemas and ask it to align them. It will produce a clean mapping table in seconds: name to full_name, status to state, created to one of the four fields called date. Most rows will be right — which is what makes the output dangerous. A mapping that is mostly right ships, and the rest becomes a data-quality incident with excellent grammar.

The instinct is to blame the model. The actual cause is the input. A bare JSON key carries no identity, so a field name is a rumor: evidence of what someone once meant, with no way to check. Faced with rumor, any reasoner — human or machine — substitutes statistics for semantics. JSON-LD was designed to remove exactly that ambiguity, which is why it matters more in the agent era than in the era it was invented for.

Identity is the fix, and it has to survive

JSON-LD's founding move is that identifiers are global. A property is not "name"; it is https://schema.org/name, compacted through the document's @context. Two schemas that both reference that IRI are not probably about the same thing. They are about the same thing, by construction.

The trick is making that identity survive the rest of the stack. When a JSON-LD vocabulary is imported into CoreModels, every node's @id is lifted into a mapsTo annotation on the Type, Element or Taxonomy it creates — identity becomes part of the governed model rather than decoration on it. An agent working against that project does not have to infer what an element means from its label; the element declares its own lineage, machine-readably. And the declaration travels: a JSON Schema encoded from the same model carries the schema.org URI as an x-maps-to annotation on the property, which our test suite asserts rather than assumes.

That changes the alignment problem from a similarity contest into a lookup. Our explicit mapping guides support automatic matching on shared mapsTo identity, so two schemas descending from the same vocabulary align on IRIs instead of string distance. Where an agent used to guess that two fields called name correspond, it can now verify that both are https://schema.org/name — or discover that one is actually a product title, before the mapping ships rather than after.

Consult the model; do not recall it

The second failure mode is confabulation. Asked about your model, an unassisted agent describes a plausible one: schema.org as it half-remembers it, your project as it imagines it — fluent, internally consistent, unfalsifiable in the moment.

CoreModels closes that gap over the Model Context Protocol. Our MCP server exposes read-only tools at an endpoint like https://coremodels.example.com/mcp, protected by OAuth — spec-compliant clients discover the resource metadata, register dynamically and complete the authorization flow without hand-configured credentials. An agent connected there does not recall your schema. It consults it. list_projects and get_project_summary establish what exists; search_nodes locates specific nodes; validate_json checks a document against the project's stored JSON Schema.

For this topic the verbs are precise. transform_schema accepts jsonld as both a source and a target format, so an agent can decode a partner vocabulary, re-emit a schema it holds as a vocabulary, or convert JSON-LD into JSON Schema, SQL, Avro, OWL, ShEx, LinkML and the rest of the set in one stateless call — nothing written, everything returned. For linked-data exports of project content, fetch_json_ld_import_profiles lists a project's configured profiles and export_json_ld runs one: graph-based across the project, or tree-based from exactly one root node, with an optional space filter. Every answer is grounded in the governed project as it exists right now, not as it existed in a training corpus.

Tools that declare what they touch

Grounding is necessary but not sufficient. Agents also need tools that tell the truth about themselves, because a tool's honesty is what lets a supervising human decide before the call rather than audit after it.

Every CoreModels MCP tool declares whether it is read-only, and the annotations are candid about open-world behavior. transform_schema advertises that its optional AI mapping mode sends schema content to an external model provider server-side, and that mode requires Editor or Admin membership rather than mere read access. The public endpoint serves read-only tools only; write tools live behind a separate admin endpoint, and the enforced boundary is the per-project role check rather than which URL a token came from.

The response shape is built for agent reasoning too: a transform returns the produced schema, the executed plan as a replayable artifact, and a lossiness ledger — a typed list of everything the transformation could not preserve, each entry with a path and a plain-English explanation. An agent that reads the ledger can say "the enumeration had no home in the target and the allowed-value constraint was relaxed" instead of presenting a silently degraded artifact as success. Agents are bad at noticing what is missing; the ledger removes the need to notice.

Propose, then let a person decide

The last failure mode is authority: an agent that can write is an agent that can redefine your terms, and the fix is not a better prompt but a gate.

When an agent proposes a mapping, including through the AI mapping mode, the proposal passes the same validation gate as a human-authored guide, with at most one repair attempt and no relaxation of the rules. Self-reported confidence is advisory; the gate does not read it. The mapping call itself writes nothing, so the artifact an agent hands a human is a plan plus a ledger — reviewable, replayable, and inert until an Admin applies it through the gated import path.

The same division of labour governs semantic enrichment. An agent can call suggest_ontology_terms to search the public EMBL-EBI Ontology Lookup Service for candidate identities for a schema node, and that tool is advisory only: it never writes, and it says so in its own response. Binding a chosen term is a separate, explicit, Admin-gated act that writes exactly one mapsTo value — the very carrier the JSON-LD coder reads on import and reverses into compact prefixed names on export. The agent does the research; a human confirms the meaning; the confirmed meaning then travels through every format the model is projected into.

That is the quiet thesis of JSON-LD in the agent era. You do not make agents reliable by asking them to guess better, but by giving them a governed model whose elements know what they are, tools that let them consult that knowledge instead of reconstructing it, and a gate that keeps the last word with a person.

To connect an agent, see the MCP quickstart in the CoreModels docs.