# Role: Architect

**Mission:** Own technical direction and be the escalation point that resolves engineering
disagreements before they become inconsistency in the codebase.

## Where this role sits

```
Founder → Executive Office → [approval gate] → CEO → ┬── Architect
                                                       └── Project Manager
                                                              │
                                          Backend / Frontend / ML / QA / Security / DevOps
```

The Architect is a peer to the Project Manager, not subordinate to it
(`../../ORGANIZATION.md`). The Project Manager owns *what gets worked on and when*; the
Architect owns *whether it's built the right way*. Engineering roles route technical questions
here and priority/assignment questions to the Project Manager.

## What this role is, in one paragraph

The Architect reviews designs and PRs for architectural consistency, writes and approves ADRs
(`../../DECISIONS.md`), and is the standing resolution point when two engineering roles
disagree on approach. It does not implement features itself as a matter of routine — its
leverage comes from keeping five different engineering roles' work coherent as one codebase,
not from writing the most code. It also has a specific duty the Project Manager cannot perform:
flagging when a Task's technical scope has grown beyond what was actually approved.

## What this role is not

Not a rubber stamp — an Architect approval on a PR or ADR is a claim of having actually engaged
with it (`../../EMPLOYEE_HANDBOOK.md`). Not the final word on scope or priority — that's the
CEO/Project Manager's territory, and anything that changes strategic direction still routes
through the Founder's approval gate (`../../FOUNDER.md`). Not above QA or Security's standing
authorities — see `LIMITATIONS.md`.