The content graph

One graph, addressed by identity

An asset is a reference with a stable identity, and a published version of it is immutable — addressed by content, so a reference to a specific version means the same bytes on every machine that resolves it. A world's history is a DAG of commits; branches and tags name points in that history. Publishing is a commit: it adds to the graph, and what was published before stays reachable.

Types are part of the graph

An asset type is authored and published like any other asset, and authoring a type constructs new behaviour — structure, templates, creation workflows, runtime integration (the asset guide teaches this in depth). Because types are themselves published assets, the graph carries every type anyone has defined, and each piece of content declares the type it conforms to. Search works along both axes: find a type, or find the content made with it, the same way you find a module or a material. The taxonomy of what exists grows from creators, release by release of their worlds.

Installing pulls a closure

Installing an asset from another world brings the asset and everything it depends on into your world, under /source/deps/<owner_world>/. Transitive dependencies resolve automatically — a package that depends on another world's package resolves the whole chain — and each installed piece is the exact published version its author committed. Your world's dependency closure is the set of everything reachable this way.

Publishing validates references

When a commit is created, the references the engine understands — module requires, asset paths, typed asset fields in configs — are resolved against the commit itself plus your world's dependency closure. A commit publishes when every reference resolves; unresolved references surface as a structured problem list to repair first, and references to local assets you authored but haven't committed yet are offered into the commit alongside it. This is the property that makes installing a stranger's content safe: what works in the author's world works in yours, by construction rather than by convention.

Staying current

Installed content stays at the version you installed — an author publishing a new version changes your world only when you choose to update. When you do, the newer version fetches from its origin world, and your next commit re-validates every reference, so an update that would break something surfaces at publish time, in your session, where you can fix it.

Forks, and changes flowing back

Editing your copy of installed content makes it a fork. zm.forkStatus() shows how your copies diverge from their origins, and zm.contribute() opens a pull request carrying your improvement back to the asset's origin world. Provenance is transitive: a fix that travelled through several worlds before reaching the origin is attributed to the person or agent who wrote it. The same applies to you — improve something you installed, contribute it, and the next world to install that asset gets your fix with your name on it.

Worlds branch, merge, and review

Within a world, branches carry independent working trees and merge three-way with conflict markers (the development guide). Between collaborators, pull requests connect branches with review threads, and conflict resolution is drivable end-to-end from a session: fetch the conflict markers, resolve on your branch, merge. Multiple agents can work the same world on separate branches and reconcile through a reviewed merge.

Surveying the graph

Before authoring something sizable, find out whether a fit already exists — the ZeroMind search tools query the whole published graph semantically, by kind, by capability, and by conforming type, and library.* explores what a world already pulls in. When a fit exists, install it or fork it as a base; when it half-exists, install the parts and author the glue; and when you publish your result, the graph grows for the next builder — that is the hivemind working as designed.