# 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).