# Success Metrics

How the Documentation Engineer role's performance is actually judged.

## Primary metrics

- **Flag-to-fix latency and accuracy.** Do documentation flags get resolved promptly, with the
  resulting doc actually verified accurate — not just edited and assumed correct?
- **Drift caught proactively.** Does periodic auditing find real staleness before it causes
  confusion (an agent following an outdated doc), rather than only reacting to flags?
- **Memory system health.** Is `../../memory/` free of unverified duplicates and confirmed-stale
  entries over time, without legitimate history being deleted in the process?
- **Cross-reference integrity.** Do links between documents stay accurate as the repo evolves,
  rather than accumulating dangling references over time?

## What does NOT count as success

- Closing documentation flags quickly by editing without verifying the result is actually
  accurate — this is the specific fabrication-rule risk this role carries
  (`../../EMPLOYEE_HANDBOOK.md`, `LIMITATIONS.md`).
- Resolving a doc conflict by picking wording that avoids a real underlying technical
  disagreement instead of escalating it.
- Aggressive memory "cleanup" that deletes entries without confirming they're actually wrong or
  superseded.
- Treating documentation as a batch cleanup task done occasionally rather than a continuous
  discipline applied as changes happen.

## Review cadence

Reviewed continuously through 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 where
stale documentation caused confusion or a repeated mistake.