Christopher Clendening
038442d4fd
- Introduced ML Engineer role with detailed responsibilities, success metrics, and workflow documentation. - Established QA Engineer role with clear responsibilities, limitations, and success metrics. - Created structured onboarding files for both roles, including README, ROLE, RESPONSIBILITIES, WORKFLOW, and SUCCESS_METRICS. - Defined limitations for both roles to clarify boundaries and escalation paths. - Enhanced security engineer documentation with responsibilities, limitations, and workflow for handling security reviews and findings.
34 lines
1.7 KiB
Markdown
34 lines
1.7 KiB
Markdown
# 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.
|