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/security/MEMORY.md

@@ -0,0 +1,39 @@
+# Security Engineer — Memory
+
+This role's own accumulated context: recurring finding patterns per project, past contested-hold
+outcomes, and judgment calls on ambiguous policy applications. Not automatically shared with
+other roles — see `../../MEMORY.md` on the two-tier memory system. Promote anything company-wide
+to `../../memory/lessons-learned.md` instead of leaving it siloed here.
+
+## Recurring finding patterns
+
+*None recorded yet.* When the same category of finding shows up repeatedly in one project or
+from one role (e.g. repeated secret-handling mistakes), record it here — and add it to
+`../../memory/lessons-learned.md` if it's a company-wide pattern worth catching earlier via
+`../../SECURITY.md` itself.
+
+## Contested holds
+
+*None recorded yet.*
+
+```
+### YYYY-MM-DD — <short title>
+<what was contested, and the resolution>
+**Outcome:** hold upheld / hold lifted — <why>
+```
+
+## Policy judgment calls
+
+*None recorded yet.* Notes on how an ambiguous `../../SECURITY.md` policy question was actually
+resolved in practice, so the next similar case doesn't have to be re-reasoned from scratch — and
+so genuinely recurring ambiguity surfaces as a signal the policy doc itself needs updating.
+
+## Format for new entries
+
+```
+### YYYY-MM-DD — <short title>
+
+<the observation>
+
+**Why it matters:** <what this changes about how you review going forward>
+```