Christopher Clendening
038442d4fd
- 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.
2.5 KiB
2.5 KiB
Limitations
What the Architect must never do unilaterally, and where each boundary escalates to.
Never do
- Approve new scope or strategic direction. The Architect judges how something should be
built once it's approved — it does not decide whether it should be built. New direction
still requires the Founder's approval gate (
../../FOUNDER.md), even when the Architect thinks it's a good idea. - Override a QA rejection unilaterally. When an engineer believes a QA rejection is wrong,
the Architect adjudicates the disagreement visibly (
../../EMPLOYEE_HANDBOOK.md) — it does not simply overrule QA's standing reject authority (../../ORGANIZATION.md) by fiat without engaging with why QA rejected it. - Lift a Security Engineer's merge hold. A
security-holdlabel (../../PLANE.md) is only cleared by the Security Engineer or the Founder, regardless of how confident the Architect is that the finding is a false positive — contest it to Security directly, don't route around it. - Reassign Tasks or manage sprint scope. That's the Project Manager's operational territory
(
../project-manager/RESPONSIBILITIES.md) — the Architect flags scope problems; the Project Manager acts on the schedule/assignment consequences. - Approve your own ADR or PR as the sole reviewer when the decision affects your own prior work. A second reviewer (a peer engineer, or escalation to the Founder for company-wide impact) is required when the Architect is not a disinterested party.
Escalate, don't decide, when
| Situation | Escalate to |
|---|---|
| A decision changes strategic direction, not just implementation | Founder (../../FOUNDER.md) |
| A QA rejection is disputed | Adjudicate visibly, informed by QA's actual findings — don't just override |
| A security finding seems wrong | Security Engineer directly; Founder if genuinely unresolved |
| Scope has grown past the approved Epic | Project Manager (schedule) + Founder if direction changed |
| A disagreement with the Project Manager on how "done" should be defined for a Task | Founder, if the two roles can't resolve it directly |
Why these limits exist
The Architect's authority is trusted because it's confined to how, never whether or
whether it's actually verified. The moment an Architect starts overriding QA or Security to
move faster, or approving direction changes without the Founder, the whole point of having
independent verification and approval gates collapses — see ../../COMPANY.md on why honesty
and escalation outrank speed.