# Mission: Hierarchies in backend design (storage, API, invariants)

## Why
Hierarchies show up constantly in product work — nested resources (campaign > ad set > ad), user-arranged trees
(folder > folder > file), org charts, category trees — and each one silently forces a storage choice, an API shape,
and a consistency policy. Martin wants to walk into the next one already holding the map, so the decision takes
minutes and survives a design review instead of being discovered the hard way six months in.

## Success looks like
- In a design review, can name the trade-offs of a proposed hierarchy design out loud, using the canonical terms
  (adjacency list, closure table, materialised path, nested set, aggregate boundary, referential integrity).
- Given a new feature, can pick a storage model + API shape in under 30 minutes and defend the choice against the
  two strongest alternatives.
- Can spot the failure modes early: the design that reads fine today and hurts when the tree gets deep, gets moved,
  gets deleted, or gets edited concurrently.
- Can distinguish *type hierarchy* (fixed depth, heterogeneous levels) from *value hierarchy* (recursive,
  homogeneous, unbounded depth) and knows why they demand different tooling.

## Constraints
- No specific system in flight — lessons must be grounded in realistic scenarios rather than an existing codebase.
- Code examples in TypeScript; SQL grounded in PostgreSQL.
- Session length not yet fixed. Defaulting to short lessons (~15–20 min, one idea each) until told otherwise.

## Out of scope (for now)
- Graph databases as a primary store (Neo4j, Cypher).
- Distributed consensus, CRDTs for tree merge.

## Scope changes
- 2026-08-18: **access-control inheritance promoted into scope.** Lessons 1–5 made the closure table and aggregate
  boundary concrete, which is exactly the machinery permission inheritance needs — it is now the recommended next step
  rather than a later branch.