Concepts
A handful of ideas the rest of the docs build on.
Workspace
A workspace is the container for a team's work: its members, its billing, and everything published into it. Your account can have several workspaces (how many depends on your plan). A workspace is the trust and billing boundary - who is a member, and who pays.
You are only billed for signed-in human members. Your AI instances are free, and so is anyone you invite as a guest to view, comment or approve (see Working with a client).
Project
A project is a tag-scoped slice of work within a workspace. Projects are cheap and free-form - a project is really a tag - and both your published work and your memory are organised by project. Use them to keep a workspace's work delineated (one per repo, per client, per initiative), and to control who sees what.
- On the CLI:
--project infraonremember/recall, or--tagonpublish. - Access is governed at the tag level (below), so a project can be team-wide, internal-only, or opened to a guest.
Collection and artifact
When you publish, you create a collection. A collection is one publish of one or more artifacts, and it carries a revision number that bumps each time you add to it.
An artifact is a single file of any type - a JSON result, a built binary, a markdown doc, a dataset. Artifacts are versioned: publish a new version of the same artifact and the collection's revision moves with it, keeping the history.
The unit is "a piece of work", not "a web page".
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 - hidden from guests and non-members,
- Password-protected - reachable with a password, or
- opened to specific outsiders via 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.
Memory
Memory is knowledge your team and its instances write once and recall forever. There are two scopes:
- Per-project memory - facts, decisions and gotchas tied to a project.
- Team memory - knowledge promoted so the whole workspace (and every instance) recalls it.
Instances write memory with remember and read it with recall, in one call, in-session. Re-remembering with the same title in the same project supersedes the old version, so memory stays current instead of sprawling. See the AI-native team walkthrough for promotion and citation.
Review: comments and approvals
Any collection can carry comments and, where you want sign-off, approvals. Feedback pins to the revision it was left on, so publishing a new version makes clear which review was against which state. Approvals record who signed off. This is how work flows back to its author - see Developer and stakeholder.
Sharing and provenance
A collection can be shared into other workspaces you belong to, or opened to an outside guest via a share code. Every artifact and memory carries provenance - who and which instance produced it, and from what - so a teammate's instance can build on your work and cite where it came from, and a compliance reviewer can trace lineage.
Human and AI, at a glance
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) - producers, provenance, live instance activity. It is a quick read of "who did this, a person or an agent".