Orgs, workspaces, projects

Three words that sound interchangeable and are not. Getting them straight early saves an unpleasant migration later.

Organization

The tenant. One company, one billing relationship, one set of members and roles.

Everything else lives inside it, and nothing crosses between two of them. An organization is the boundary that SSO maps into, that SCIM provisions into, and that privacy export and erasure operate over.

Workspace

A connected surface that produces events. In practice: one Slack workspace, one GitHub organization, one Jira site, or a grouping you choose that matches how a department actually works.

A workspace owns:

• its connections and triggers;
• its event log;
• its people and their resolved identities;
• its policies, packs and environments;
• its permalink base URLs (slack.workspaceUrl, jira.baseUrl).

Almost everything in the console is scoped to a workspace, which is why the workspace switcher sits at the top of every screen.

Project

A repository is not the unit of governance, a project is.

A frontend and a backend that belong to one product are one project. They share one policy scope and one decision memory, and an audit query spans both.

The identifier is declared, never inferred. Two repositories, two policy files, one project:. The rules differ; the scope does not.

# web/memnox.policies.yaml
version: 1
project: acme-checkout
policies:
  - name: payment-ui-review
    match:
      targets: ["src/payment/*"]

# api/memnox.policies.yaml
version: 1
project: acme-checkout
policies:
  - name: migration-approval
    match:
      targets: ["migrations/*"]

cd web && npx memnox setup --project acme-checkout   # starts the runtime
cd api && npx memnox setup --project acme-checkout   # joins it, adds its rules

The editor reports its working directory, Memnox walks up to the nearest policy file, and reads the project from it. Two repositories that say acme-checkout resolve to one scope; anything else stays separate.

Rules that must be identical everywhere belong in a shared pack, not copy-pasted into every repository.

memnox audit --project acme-checkout   # spans both repositories

Environments

Inside a workspace, an environment is a named deployment target, production, staging, whatever you actually call them. Policies match on them, and packs are applied per environment, so the same pack can be enforcing in staging and observing in production while you build confidence.

How they nest

Organization (the tenant, billing, members, SSO)
└── Workspace (connections, events, people, policies)
    ├── Environment (production, staging, …)
    └── Project (one product, possibly several repositories)

Projects are declared in code and workspaces are configured in the console, one of them belongs in a diff, and the other belongs to whoever administers the tools.