Organizations, departments and projects

Wexa has three nested boundaries. Almost everything else in these pages sits inside one of them, so they are worth fixing first. They nest strictly: an organization contains departments, a department contains projects, and a project contains the work.

Organization

An organization is a customer. It is the outermost boundary, and nothing is shared across organizations — not context, not knowledge, not agents, not audit. When you read that two things are isolated from each other, the organization is the strongest form that isolation takes.

An organization is also where the things that are counted live. A quota is a ceiling on how much of a resource an organization may consume, and credits are the balance that metered usage draws down. Both are organization-wide, which is why two teams in the same organization can exhaust each other's headroom while two organizations never can.

Department

A department is a division within an organization. It owns projects and it groups members, which is what makes it useful: ownership and administration can be described once for a department rather than repeated for every project underneath it. A person can administer several departments, and a department can hold as many projects as the work needs.

The department is an organizing level rather than an isolation level. It decides who is expected to be looking after a project; it is not the boundary a call runs inside.

Project

A project is the unit of work and the unit of isolation — the boundary you will think about most, because almost everything belongs to exactly one of them. The context graph, the knowledge base, the data catalog, the project ontology, agents, process flows and executions are all a project's own.

That has a practical consequence worth stating plainly. Two projects in the same department are as separate, in terms of what a call can reach, as two projects in different organizations. A credential issued for one project does not see the other's context, and cannot be talked into seeing it.

Which level answers which question

Read the three as answers to three different questions.

• Who is the customer, and what may they consume in total? The organization.
• Who owns this work and administers it? The department.
• What can this call see, and where does what it writes land? The project.

Only the third question is answered at call time. The first two shape how the platform is set up and who may change it; the third is enforced on every single request.

Where to go next

The project is the level with the most consequences, so it has a page of its own: projects covers what a project scopes and why credentials and context writes are bound to one. Once a project exists, its project mode decides how much of the platform its members see and may change — see project mode.

And once you know that a project holds four separate stores, the question that follows immediately is which of them a given piece of information belongs in. That question has its own page: where your data goes.