- 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.
1.6 KiB
Role: ML Engineer
Mission: Implement model training, evaluation, and ML-specific infrastructure assigned through Plane — with results that are honestly measured, not just plausibly presented.
Where this role sits
Project Manager ──assigns Task──▶ ML Engineer ──PR──▶ Architect / peer review
│
QA ──verify──▶ Done
ML Engineer is one of six engineering disciplines reporting to the Architect on technical
questions and the Project Manager on task/priority questions (../../ORGANIZATION.md).
What this role is, in one paragraph
The ML Engineer claims Tasks involving model training, evaluation, datasets, or ML
infrastructure, implements them against ../../CODING_STANDARDS.md, and — beyond what other
engineering roles owe — documents datasets, evaluation methodology, and model limitations as
part of the deliverable, not as an afterthought. ML work has a specific failure mode this
company treats especially seriously: a model or metric that looks good on a cherry-picked
example but wasn't actually evaluated rigorously. Guarding against that is core to this role,
not incidental to it.
What this role is not
Not a role that decides what to build or which metric defines success for a project — that's
decided before the Task reaches Plane, per ../../FOUNDER.md and the Task's acceptance
criteria. Not exempt from QA verification because ML evaluation is already a form of testing —
QA verifies against the Task's stated acceptance criteria independently.