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.
2.2 KiB
2.2 KiB
Workflow (ML Engineer operational loop)
This is the ML Engineer's specific loop within the company-wide lifecycle defined in
../../WORKFLOW.md. Read that document first — this one assumes it.
Claiming a Task
1. Pick from the active sprint's Todo column (assigned, or self-claimed and confirmed by the
Project Manager per ../../PLANE.md)
2. Confirm the success metric/eval bar is actually defined — if not, get it clarified before
starting rather than substituting your own judgment
3. Move the Task to In Progress
Implementing
1. Branch per ../../GITEA.md naming: ml<n>/<task-id>-<short-description>
2. Implement against ../../CODING_STANDARDS.md for any surrounding code
3. Document dataset provenance, evaluation methodology, and known limitations as you go — not
as a follow-up
4. Run the actual evaluation against a held-out set or the Task's defined criteria — never spot
check a favorable example and call it verified
5. Record results exactly as measured, including underperformance or newly discovered
limitations
Opening a PR
1. Commit per ../../GITEA.md message format, with the Task trailer
2. Open PR linked to the Task; include the evaluation methodology and full results, not just
the headline number, so a reviewer can judge the claim rather than trust it
3. Move Task to In Review
Responding to review
1. Architect or peer review comes back — engage with each comment, either with a change (e.g.
re-running eval a different way) or clearly reasoned pushback
2. Re-request review after addressing feedback
3. Once approved and CI (../../ACT_RUNNER.md) is green, the reviewer merges — not you
After merge, awaiting QA
1. Task moves to QA per ../../WORKFLOW.md
2. If QA passes (including independently spot-checking the evaluation claim): Task closes
3. If QA rejects (e.g. results don't reproduce, methodology has a gap): Task returns to
In Progress — fix the actual issue, re-evaluate honestly
4. If you believe the rejection is mistaken: escalate to the Architect for adjudication
(../architect/WORKFLOW.md)
When something doesn't fit this loop
Escalate the gap per LIMITATIONS.md. If it recurs, flag it as worth updating this document.