# World Model Protocol — context excerpt > This is a **context excerpt** of an internal design doc, shared alongside the > consent spec so reviewers can see what the consent layer actually gates. It > covers the conceptual architecture only — the thesis, the engine pattern, the > identity model, and what the protocol explicitly does *not* do. Operational, > routing, and commercial detail is omitted. A *world model* is what you get when you read a group's ongoing conversation and turn it, continuously, into a queryable picture of what the group knows and is arguing about. The `#jar:matrix.org` room is the first such model fed by an external community; Decent runs the same engine over its own weekly call. The shape that survives across both is the protocol below. The **consent spec** ([data-consent-privacy-outline.md](https://zo.pub/rw/jar-consent-review)) is the terms on which the machine described here is allowed to read a room. --- ## 1 · The thesis A world model is the answer to four questions, refreshed continuously: | Question | What it produces | | --- | --- | | **Who's in the room?** | durable identity records | | **What did they actually say?** | quotes, decisions, questions, frames — attributed, dated | | **What does that say about us?** | concepts, edges, topic graphs | | **What changed this period?** | a digest — the diff the model can publish | An org that can answer those four continuously is, in effect, an *intelligence*; everything downstream (publishing, governance, treasury) is consequence. ## 2 · The pattern (one engine, many networks) ``` ┌─────────────────────────────────────────────────────────┐ │ SOURCE ADAPTER pluggable per network │ │ matrix · fireflies · discord · slack · zulip · forum │ │ ─ pulls native events │ │ ─ writes a uniform messages.jsonl + metadata │ ├─────────────────────────────────────────────────────────┤ │ NORMALISE identity resolution + dedup │ │ ─ display name → identity registry │ │ ─ canonical session key (date-bucket or call ID) │ ├─────────────────────────────────────────────────────────┤ │ EXTRACT LLM-driven, source-agnostic │ │ ─ frame · topics · quotes · decisions · questions │ │ ─ concepts (provisional → promoted) · mentions │ │ ─ idempotent; rerunnable on better prompts │ ├─────────────────────────────────────────────────────────┤ │ DISTRIBUTE fan into the queryable world model │ │ ─ people get their spoken corpus + topic counts │ │ ─ concepts auto-promote on cross-session refs │ │ ─ typed edges (vouched, co-attended, replied-to, …) │ │ ─ snapshot / timeline / attendees / digest queue │ ├─────────────────────────────────────────────────────────┤ │ PUBLISH the API and the surfaces │ │ ─ a graph snapshot, a public hub, a personal facet │ │ ─ a recurring digest │ └─────────────────────────────────────────────────────────┘ ``` The bottom layers are shared across every network the engine runs over. The top layer (the adapter) is the only thing that changes per network. **That is the protocol.** ## 3 · The adapter contract A source adapter is anything that produces, idempotently, a uniform stream: - `metadata` — date, source, room/call id, message count, language. - `messages.jsonl` — a canonical `{ts, sender, display, body, kind}` stream. This is the bridge: every adapter writes it, the extractor only reads it. - `extract/` — the LLM extract (below). `` is whatever makes sense for the source: a call number for a weekly call; a date for a chat day; a thread id for a long discussion. Re-running an adapter must be idempotent for already-processed keys (checkpointed). Adapters exist today for a weekly call (via transcripts) and for the JAR Matrix room; others are written per source type as needed. ## 4 · The extract contract (uniform across all adapters) Every extract is a single document with these keys (all lists may be empty): ```yaml frame: speakers: [{ name, display_name, msg_count }] topics: [{ tag, confidence, why }] quotes: [{ speaker, text, importance }] decisions: [{ what, by }] questions: [{ text, raised_by }] concepts: [{ name, summary }] people_mentioned: [{ name, context }] ``` The same schema is emitted by every adapter and consumed by the distributor, so the engine is genuinely source-agnostic. ## 5 · Identity across instances Each network keeps its own identity registry — participants in one are not automatically participants in another. A person who takes part in two networks has two separate records, with no automatic cross-link. They can opt into a cross-link by signing both — but that is a future feature, not part of v0.1. For chat sources where no email is available (Matrix user IDs, Discord snowflakes), the source-native id stands in until the person authenticates and claims their own record. ## 6 · The first external proof — JAR The `#jar:matrix.org` ingest is the first time the engine touches a network its operator does not control. What the run teaches — how much of the pipeline is Matrix-specific vs. generic, how identities should map, how the extract prompt ports to a new community — is what hardens the protocol into something *any* community can run. ## 7 · What this protocol explicitly does *not* do (v0.1) - **No cross-instance identity linking.** Two networks are independent worlds unless the person opts in (deferred). - **No automatic ingestion of non-public sources** without explicit operator approval. Plugging in a private space is a deliberate act; the operator surface must show exactly what is being read and why. - **No retroactive attestation.** Artifacts get attestation envelopes going forward; old extracts are not retro-signed. - **No bidirectional writes.** The protocol reads networks and publishes digests. Writing back *into* the source is a separate, opt-in feature. --- The aim is not to govern one room. It is a reusable pattern any community can run over its own conversation to turn it into a world model it owns — on terms set by the consent spec this sits beside.