The whole model in one page. Everything else in these docs builds on these eight ideas.
Workspace
A workspace is the container for a team's work: its members, its billing, and everything published into it. It's the trust and billing boundary - who's a member, and who pays. Your account can belong to several.
You're only billed for signed-in human members who can write. Read-only viewers are free, your AI instances are free, and so is anyone you invite as a guest to view, comment or approve.
Every member holds a role: owner, admin, member or viewer. Owners and admins manage membership, billing, settings and the workspace guide; members publish and recall; viewers read. More in Workspaces, members and roles.
Project
A project is a tag-scoped slice of work inside a workspace. Projects are cheap and free-form - a project is a tag, of a distinguished project kind - and both published work and memory are organised by them. One per repo, per client, per initiative.
Access is governed at the tag level, so a project can be team-wide, internal-only, private to named members, or opened to a guest. See Projects and tags.
Collection and artifact
When you publish, you create a collection: one publish of one or more artifacts, carrying a revision number that bumps whenever a member artifact gets a new version.
An artifact is a single file of any type - a JSON result, a built binary, a markdown doc, a dataset - and artifacts are versioned, so the history is kept. The unit is "a piece of work", not "a web page". See Publishing your work and Versions and revisions.
Memory
Memory is knowledge your team and its instances write once and recall forever. Two scopes:
- Per-project memory - facts, decisions and gotchas tied to a project.
- Team memory - knowledge promoted so the whole workspace, and every instance in it, recalls it.
Instances write memory with remember and read it with recall, in one call, mid-session. Re-remembering with the same title in the same project supersedes the old version, so memory stays current instead of sprawling.
Memories can carry a light type (decision, how-to, gotcha, reference - free text), aliases, and [[wikilinks]] to other memories. The same [[Title]] links work inside published documents too - a document can point at a sibling in its collection, another collection, or a memory. See Memory, Linking memory, Publishing and Recall.
Wiki
A wiki is a tree of pages your team reads: a handbook, a runbook, a knowledgebase you hand a customer. A workspace can hold as many as it needs.
It isn't a third store. A page is a collection carrying one markdown body, so the permalink, the versions, the comments and the block feedback all work on a page exactly as they do on anything else you publish. A wiki's access rides on a tag, so private membership, passwords and share links come with it.
Pages are draft until published: a draft is visible only to people who can edit the wiki, and is in no search, no recall and no timeline. Publishing is the moment a page exists for a reader - and optionally needs an approval first. See Wikis.
Tags and access control
Tags do two jobs: they delineate projects, and they govern access. A tag can be:
- open to the whole workspace (the default),
- internal-only - excluded from every anonymous view,
- password-protected - reachable by anonymous viewers who have the password,
- private to named members - only they see its work and memory,
- opened to a specific outsider with a share code - a pseudo-identity that lets a named guest view, comment and approve without an account.
Because memory and collections share the same tag model, controlling a project's access controls both its work and its memory in one place.
An author can also keep an individual item private to themselves. Owners and admins keep an audit-logged oversight view of hidden content, so nothing is truly invisible to the workspace's stewards.
Summaries inherit their sources' restrictions. When an instance reads restricted content and then writes a memory from it, that memory carries the same restriction rather than becoming visible to people who couldn't read the source. If it drew on a single private project you belong to, the memory is scoped to that project; otherwise it's kept private to you. Recall never returns a memory to someone who couldn't have read what it summarises. Hosted applies this by default; self-host operators switch it on with memory_provenance (Self-hosting).
Review
Any collection can carry comments and, where you want sign-off, approvals. Feedback pins to the revision it was left on, so a new version makes clear which review was against which state, and approvals clear when the work moves on. Markdown artifacts can also be reviewed block by block - a comment against a specific paragraph, which survives a re-publish where that paragraph didn't change.
Promoting a memory into a team workspace goes through the same gate: the target's instances don't apply it until an owner approves. See Review, Block-level feedback and Promoting memory.
Provenance
Every artifact and memory records who and which instance produced it, and what it drew on. That's what lets a teammate's instance build on your work and cite where it came from, and a compliance reviewer trace lineage.
Throughout the product, the human side shows in Ember (coral) - approvals, presence, who wrote a comment - and anything an AI instance did glows Iris (indigo). A quick read of "person or agent".