the model

One data space, many clients

Start with the data. Give each thing an address, describe what it means, and let the pod decide what each caller can do. Apps and agents can then work with the same knowledge through a common interface.

Resources have web addresses

An event, task or place has a URI. Request it over HTTP and the pod returns the description you may read, usually as JSON-LD. Follow a link and you reach another resource, potentially on another pod.

The identifier belongs to the data. A new client can use it without asking the previous app to translate its private IDs.

Shared vocabulary gives the data meaning

RDF describes things through statements and links. An event can use schema.org's Event, name and startDate terms. A calendar, website and agent can recognize the same facts and use them for different tasks.

An app developer can work with JSON-LD or a graph library. The useful property is the shared meaning underneath those representations.

The pod authorizes every operation

The current specification uses Contexts, RDF named graphs, as its permission boundary. Each statement belongs to exactly one Context. Grants allow reading, writing or managing a Context; the pod resolves them server-side on each request.

Context creation and deletion belong to an optional module. The broader vision also considers access without Context setup, with more freedom in how a pod applies policy. That generalization is proposed; it is not the current normative contract or Kotlin 0.2 behavior.

Queries respect the same boundary

SPARQL lets a client ask about the graph directly. The server limits the query to readable Contexts. Naming a private graph does not give the caller authority to read it.

The current contract supports read-only SPARQL. Writes use HTTP CRUD and name their target Context explicitly. The CRUD guide explains the resource and write boundaries.

Agents use an optional client surface

A pod may expose MCP tools for finding resources, following their links and querying the graph. Those tools use the same authorization decisions. An agent gets the access granted to its connection.

A hosted MCP service can connect one agent to several pods. Each pod still controls its own data. Read MCP over pods.

The contract leaves room for different implementations

The specification owns the protocol. sempods-kotlin provides one reference implementation and building blocks for clients and servers. Their versions advance independently; a Kotlin release does not release the specification.

The development specification already defines requirements. Its governance records how changes are adopted and which guarantees apply before publication. Passing a repository build does not establish product conformance.

Try the model Follow the retrieval loop Read the development specification Read governance