Files

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

2.2 KiB

Raw Blame History

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.

2.2 KiB Raw Blame History