> Source: https://wexa.ai/docs/concepts/tenancy

# 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](/docs/concepts/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](/docs/concepts/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](/docs/concepts/where-your-data-goes).