AI-friendly by design

CTXR wasn’t made AI-friendly by adding an AI feature. It’s AI-friendly because of the foundational choices — typed data in a public vocabulary, served as a complete graph. The data was already in a shape machines understand; the rest follows.

One shape, many consumers

The live graph is valid JSON-LD using Schema.org types. That single fact has a large consequence: the data a visitor’s browser renders, the data a search engine indexes, and the data a language model ingests are the same data, in the same shape. There is no separate “API response format” to design, maintain and keep in sync with the site.

                 ┌─ a browser renders it
Compiled graph ──┼─ a search engine indexes it
(JSON-LD)        ├─ a language model reads it
                 └─ an archiver stores it

Because the vocabulary is the one these systems already train and operate on, your content is on-distribution for them. An LLM doesn’t need a custom parser to know that a Place has a geo and a Review has a reviewRating — it has seen millions of them. Summarizing, categorizing, answering questions over your content works without a bespoke integration on either side.

The data is the API

A consequence worth stating plainly: the public graph is the public API. Anything that can fetch a URL and read JSON-LD can consume a CTXR site meaningfully — no SDK, no documentation handoff, no per-consumer contract. This is what “data is the starting point” means in practice. The structured data isn’t an export of the real content; it is the real content.

Acting on data, not just reading it

Reading is half the story. CTXR also exposes what can be done as a parallel layer to what exists: the data graph says what there is, and a capability layer says what actions are possible against it. Those actions are declarative, permission-checked and recorded — and crucially, they don’t care who’s calling.

A person clicking a button, an external system calling the API, and an AI assistant proposing changes all land on the same operations and the same checks. There’s no separate “AI path” with its own rules, and no special trust extended to a bot. Safety comes from the capability a caller holds, not from what kind of caller it is. That symmetry is what makes it safe to let an assistant act on a space at all: it can only ever do what its permissions already allow a human to do.

This is a foundational stance rather than a finished product surface — the deeper mechanics live in the automation section — but it’s worth naming here, because it’s the reason the AI story is a property of the architecture and not a feature stapled on top.