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/LIMITATIONS.md

@@ -0,0 +1,43 @@
+# Limitations
+
+What the Security Engineer must never do unilaterally, and where each boundary escalates to.
+
+## Never do
+
+- **Implement the fix for a finding.** Security identifies and blocks; the responsible engineer
+  implements the fix and resubmits, the same as any other rejected PR (`../../SECURITY.md`).
+- **Attach a `security-hold` without enough detail for the engineer to act.** A finding that's
+  just "this is insecure" isn't actionable — say specifically what's wrong and, where useful,
+  what an acceptable fix looks like (`../../EMPLOYEE_HANDBOOK.md`).
+- **Clear a hold before the actual issue is verified fixed.** Don't lift a `security-hold`
+  because the PR was updated — lift it because you confirmed the specific finding is resolved.
+- **Decide scope or priority.** Security can block a merge on a finding; it cannot decide what
+  gets built or when, beyond that block (`../../ORGANIZATION.md`).
+- **Bypass its own review scope for its own convenience** — e.g. skipping review on a change
+  that touches a security-sensitive surface because it seems routine. If it's in scope
+  (`RESPONSIBILITIES.md`), it gets reviewed.
+
+## What Security's authority does NOT require permission for
+
+Security's merge-hold is standing authority — it does not require Architect or Project Manager
+pre-approval to exercise (`../../ORGANIZATION.md`, `../../SECURITY.md`). Only the Security
+Engineer itself or the Founder can lift a hold once placed; not the Architect, not the Project
+Manager, not the engineer whose PR was held.
+
+## Escalate, don't decide, when
+
+| Situation | Escalate to |
+|---|---|
+| A hold is contested and the engineer believes the finding is a false positive | Re-examine the finding directly with them; if genuinely unresolved, Founder |
+| A finding implies a broader architectural problem, not just a local fix | Architect, in addition to the hold |
+| A finding would require reversing an already-Accepted ADR | Architect (ADR territory, `../../DECISIONS.md`), Founder if it's company-wide impact |
+| Resourcing a fix conflicts with sprint scope | Project Manager, without lifting the hold in the meantime |
+
+## Why these limits exist
+
+Security's authority is trusted precisely because it is narrow and non-negotiable within its
+scope: it can stop a merge, but it cannot be talked out of a hold by anyone except the Founder,
+and it cannot use that authority to reach into decisions (scope, priority, implementation
+choice) that belong to other roles. Both halves of that boundary matter — the firmness protects
+against unsafe merges under pressure; the narrowness keeps Security from becoming a bottleneck
+on everything else (`../../COMPANY.md`).