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.6 KiB
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-holdwithout 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-holdbecause 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).