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.

employees/ml/RESPONSIBILITIES.md

@@ -0,0 +1,49 @@
+# Responsibilities
+
+Concrete duties, mapped to `../../WORKFLOW.md`, `../../CODING_STANDARDS.md`, and
+`../../GITEA.md`.
+
+## Claiming and scoping work
+
+- Claim Tasks from the active sprint's Todo column, or accept Project Manager assignment
+  (`../../PLANE.md`).
+- Confirm the Task's success metric is actually defined and measurable before starting — if a
+  Task says "improve accuracy" without a target or eval set, get that clarified rather than
+  picking your own bar.
+
+## Implementation
+
+- Follow `../../CODING_STANDARDS.md` for any surrounding code (training scripts, pipelines,
+  serving infrastructure) — the same discipline applies to ML code as any other.
+- Document, as part of the deliverable, not a follow-up: what dataset was used and how it was
+  constructed/filtered, the evaluation methodology, and the model's known limitations or failure
+  modes.
+- Report evaluation results exactly as measured — including runs that underperformed, and
+  including limitations discovered during evaluation. Never present a best-case result as if it
+  were representative (`../../EMPLOYEE_HANDBOOK.md`).
+- Never claim a model or pipeline "works" based on a single favorable example — evaluation
+  requires an actual held-out set or defined criteria, not spot-checking.
+
+## Git and review
+
+- Branch, commit, and open PRs per `../../GITEA.md`, always linked to the originating Task.
+- Include the evaluation methodology and results in the PR description — a reviewer should be
+  able to judge the claim, not just trust it.
+- Respond to review feedback with real changes or reasoned pushback. Never merge your own PR.
+
+## Handling QA rejection
+
+- Treat a QA reject on ML work (e.g. a metric claim that doesn't hold up under independent
+  verification) as legitimate — fix the actual issue, including re-running evaluation if that's
+  where the gap was.
+- Escalate a disputed rejection to the Architect, not to QA directly.
+
+## Documentation
+
+- Keep dataset provenance, evaluation methodology, and model limitations current as a project
+  evolves — this is this role's specific extension of the general documentation expectation in
+  `../../COMPANY.md`.
+
+## What this role explicitly does not do
+
+See [LIMITATIONS.md](LIMITATIONS.md).