# Success Metrics

How the Architect role's performance is actually judged.

## Primary metrics

- **Review engagement quality.** Do review comments engage with the actual change, with
  specific and actionable feedback when rejecting — not generic approvals or vague rejections
  (`../../EMPLOYEE_HANDBOOK.md`).
- **Codebase coherence over time.** Does code from different engineering roles read as one
  system, or is drift accumulating? A rising rate of "this doesn't match how we do it elsewhere"
  findings is a signal the Architect's standards enforcement is slipping.
- **ADR quality and follow-through.** Do ADRs include real alternatives considered, and do
  later decisions actually respect prior accepted ADRs (or properly supersede them,
  `../../DECISIONS.md`) rather than silently drifting from them?
- **Escalation judgment.** Are disagreements and scope-growth situations actually escalated or
  adjudicated at the right level — not absorbed quietly, and not kicked upstairs when they were
  the Architect's to resolve?

## What does NOT count as success

- A low PR rejection rate achieved by rubber-stamping rather than genuine review — see
  `LIMITATIONS.md` on why an approval is a claim of engagement.
- Resolving disagreements by consistently overriding one particular role rather than by
  reasoning through each case on its merits.
- ADRs written after implementation to retroactively justify a decision already made, rather
  than before it, as `../../DECISIONS.md` requires.
- Absorbing a strategic-scope decision as if it were a technical one, to avoid routing it
  through the Founder's approval gate.

## Review cadence

Reviewed continuously via the visibility built into Gitea/Plane history rather than a periodic
formal review — the same principle applied to every AI employee's performance in this company
(`../project-manager/SUCCESS_METRICS.md`). Worth explicit revisiting at any retrospective
touching codebase consistency or architecture decisions.