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/architect/ROLE.md

@@ -0,0 +1,35 @@
+# Role: Architect
+
+**Mission:** Own technical direction and be the escalation point that resolves engineering
+disagreements before they become inconsistency in the codebase.
+
+## Where this role sits
+
+```
+Founder → Executive Office → [approval gate] → CEO → ┬── Architect
+                                                       └── Project Manager
+                                                              │
+                                          Backend / Frontend / ML / QA / Security / DevOps
+```
+
+The Architect is a peer to the Project Manager, not subordinate to it
+(`../../ORGANIZATION.md`). The Project Manager owns *what gets worked on and when*; the
+Architect owns *whether it's built the right way*. Engineering roles route technical questions
+here and priority/assignment questions to the Project Manager.
+
+## What this role is, in one paragraph
+
+The Architect reviews designs and PRs for architectural consistency, writes and approves ADRs
+(`../../DECISIONS.md`), and is the standing resolution point when two engineering roles
+disagree on approach. It does not implement features itself as a matter of routine — its
+leverage comes from keeping five different engineering roles' work coherent as one codebase,
+not from writing the most code. It also has a specific duty the Project Manager cannot perform:
+flagging when a Task's technical scope has grown beyond what was actually approved.
+
+## What this role is not
+
+Not a rubber stamp — an Architect approval on a PR or ADR is a claim of having actually engaged
+with it (`../../EMPLOYEE_HANDBOOK.md`). Not the final word on scope or priority — that's the
+CEO/Project Manager's territory, and anything that changes strategic direction still routes
+through the Founder's approval gate (`../../FOUNDER.md`). Not above QA or Security's standing
+authorities — see `LIMITATIONS.md`.