> ## Documentation Index
> Fetch the complete documentation index at: https://docs.engineeringframework.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Core Concepts: Organizations, Departments, Projects

> The three-level hierarchy and how permissions cascade through it

Engineering Framework organizes everything around a simple three-level
structure: **Organizations** contain **Departments**, and both Organizations
and Departments can own **Projects**. Access follows this same structure, so
a permission granted higher up automatically applies to everything beneath
it.

## The hierarchy

### Organization

Your company or team, as a whole. Every person, department, and project
belongs to exactly one organization. An organization also holds its own
settings:

* **Role templates** — reusable bundles of permissions you can hand out to
  people (see [Roles Management](/roles-management))
* **Project phases** — the lifecycle stages your projects move through (see
  [Project Phases](/project-phases))
* **Custom checklist content** — your own categories, items, and templates on
  top of the built-in framework checklist, typically managed through
  [GitHub Sync](/github-sync)

### Department

A sub-unit of your organization — a team, a business unit, whatever grouping
makes sense for you. Departments help you organize people and projects
without needing a separate organization for every team. Not everyone needs
to belong to a department; it's optional. Deleting a department doesn't
delete the people in it — they simply become unassigned to any department.

### Project

The actual unit of work. A project belongs to one organization and,
optionally, one department. Every project also has:

* **Members** — who's involved, and in what role (e.g. tech lead, product
  manager, SRE)
* **A checklist status** — how far along the project is against each
  applicable framework checklist item
* **A current phase** — see [Project Phases](/project-phases)
* **An optional connection to a code repository**, if you want planning
  artifacts linked to where the actual work happens

## How permissions cascade

Access in Engineering Framework flows downhill: if you're granted
administrative access at the organization level, you automatically have that
same access over every department and project underneath it — you don't need
to be granted access separately at each level.

* **Department access** follows from organization access. An org admin can
  manage every department without being added to each one individually.
* **Project access** works the same way. An org admin can view, edit, and
  manage every project in the organization without being added as a member
  of each one.

In other words: granting someone admin access on the organization is enough
for them to administer everything underneath it. More targeted access — like
adding one person to a single project — is granted directly on that project
instead.

For the full breakdown of what each role can actually do, see
[Permissions & Roles Explained](/permissions-explained).