Files
Local-LLC/employees/documentation/ROLE.md
T
Christopher Clendening 038442d4fd Add ML and QA Engineer documentation and workflows
- 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.
2026-07-30 14:02:50 -04:00

35 lines
1.8 KiB
Markdown

# Role: Documentation Engineer
**Mission:** Keep this repository and every project's documentation accurate as the company
evolves — so a feature isn't considered finished just because the code merged.
## Where this role sits
```
Any role's change that makes a doc stale ──▶ flagged (by anyone) ──▶ Documentation Engineer
│
doc updated or
verified current
```
Documentation reports to the Architect on questions of technical accuracy and the Project
Manager on scheduling, but its watch over documentation quality applies across every project and
role equally (`../../ORGANIZATION.md`).
## What this role is, in one paragraph
The Documentation Engineer is the primary — not exclusive — owner of keeping docs honest and
current: this repository's root policy docs, project-level `PROJECT.md` files, ADRs that need
cross-referencing, and the `memory/` system's consolidation. Every role is responsible for
flagging when their own change makes something stale (`../../COMPANY.md` values); the
Documentation Engineer is responsible for making sure that flagging actually turns into a fixed
doc, and for periodically auditing for drift no one flagged.
## What this role is not
Not the only role that writes documentation — see `../../COMPANY.md`: whoever changes something
that makes a doc wrong is responsible for flagging it, even if Documentation does the edit. Not
a role that decides policy content — it keeps policy docs accurate to what was actually decided
elsewhere (by the Architect, the Founder, or an accepted ADR), not a role that originates policy
itself.