# Core Concepts (/docs/core-concepts)



Factory OS models the real-world factory hierarchy as a tree of resources.

## Hierarchy [#hierarchy]

```
Organization (tenant)
  └─ Factory (physical site)
       ├─ Machine (CNC, press, oven, ...)
       ├─ Production Order (work order)
       ├─ Product
       ├─ Production Method (routing)
       └─ Shift
```

Every resource below the organization inherits access rules from it. A user invited to `[org-slug]` sees every factory under `[org-slug]`, but nothing else.

## Slugs, not UUIDs [#slugs-not-uuids]

URL path params use **slugs** for human readability:

```
GET /api/factories/[factory-slug]/machines
                   ^^^^^^^^^^^^
                   factories.slug, not uuid
```

Resource bodies still return UUIDs in `id` fields — use those for joins and updates.

## Multi-tenancy [#multi-tenancy]

Every row in every table carries an `organization_id`. Row-level security in Postgres enforces that queries only see rows your JWT's org can access. The API adds a second layer of role-based checks on top.

## Audit log [#audit-log]

Every mutation is recorded in the audit log with the user, timestamp, resource, and old/new values. Query it via the [Audit API](/docs/api-reference/audit).

## Key resources [#key-resources]

<Cards>
  <Card icon="<Building2 />" title="Organizations" href="/docs/api-reference/organizations">
    The tenant boundary. Contains factories, users, and billing.
  </Card>

  <Card icon="<Factory />" title="Factories" href="/docs/api-reference/organizations">
    Physical sites. Own machines, shifts, and production.
  </Card>

  <Card icon="<Cpu />" title="Machines" href="/docs/api-reference/machines">
    Any physical asset producing telemetry or work.
  </Card>

  <Card icon="<ClipboardList />" title="Production Orders" href="/docs/api-reference/production-orders">
    The unit of work — what to make, how much, when.
  </Card>
</Cards>
