1. Inward — what we connect to
MCP servers, attached in Studio, scoped to containers. A member (or a Builder acting for an organization) connects an MCP server and attaches it to a specific relationship, guild, alliance, or organization — the container is the scope. A scheduling server attached to an alliance serves that alliance’s work and nothing else; a payments tool attached to an organization acts only inside its treasury rules. The running list of interesting servers is maintained as wisdom (a living, curated inventory by category — payments and commerce, calendars and scheduling, docs and storage, social and messaging, web and search, creative tooling, dev tools) rather than frozen in this spec.
Local agents on the member’s own machine — the package protocol. Studio interoperates with Claude Cowork / Claude Code and OpenAI Codex running locally over a defined package-passing protocol, modeled on the dispatch protocol we run between our own sessions: Studio hands out a self-describing package (context, the ask, constraints, where to return), the coding agent works it in its own environment, and the result returns as a package Studio unpacks into the graph — the exchange recorded like any other work. The member’s machine stays theirs; the ally coordinates, it doesn’t colonize.
The first Institution integration: Lightbrush. The working pattern for bringing an outside stack in (Institutions): Lightbrush LLC’s creative agents and tooling (Dowbot, Zhowbot, Digital Dolly, RenderDeck, the audio system) integrate into The Ceremony Machine with Elias as forward-deployed engineer — Lightbrush’s IP stays Lightbrush’s, the integration work is ours, and usage-based distributions flow from the duna’s treasury per its recorded configuration. Every future Institution integration should be recognizable from this shape.
Channels are integrations too. Telegram, Bluesky, email, the browser (Express) — one system presence per channel (Orchestration §3), thin adapters, identity and permission held in the middle tier.
2. Outward — building on the Kidunaverse
Our own API and our own MCP server. Every action the system can perform is already a registered graph command (Actions); the outward surface exposes those commands as an API and as MCP tools — so Claude Code, Codex, and any MCP-capable client can operate the parts of the Kidunaverse a member grants them. New apps, new websites, new tools, or just more features: all of it builds against the same commands the first-party products use.
No privileged path. Outside callers are permission-checked by the graph service exactly like internal ones: the four levels, the grants, instructions-only-from-your-own-member, structural recusal, the receipt rule — all of it holds whether the caller is our Flutter app or someone’s weekend project. The one account everything needs is kidunaverse.com: third-party apps authenticate against it, and their actions trace in the same audit trail the protocol browser walks.
Creators and Builders open doors deliberately. Opening part of the Kidunaverse to an outside tool is a grant like any other — scoped, stated, revocable in one sentence, and disclosed where it acts.
3. The rule that keeps it safe
One sentence, both directions: an integration is a tool under grants, never a party with standing. It cannot vote, cannot hold sovereignty, cannot receive instruction-weight from anyone but the member who granted it, and everything it does is traced. If a proposed integration can’t live inside that sentence, it isn’t an integration — it’s a membership question, and those go through Roles and Protocol.
Changes in v5.2: the Studio↔︎Claude Code/Codex package-passing protocol specified; Lightbrush recorded as the first Institution integration. v5.0: track created. Full history: versions.