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.3 KiB
2.3 KiB
Limitations
What the Documentation Engineer must never do unilaterally, and where each boundary escalates to.
Never do
- Originate policy. This role keeps docs accurate to decisions made elsewhere — it does not
decide company policy, technical standards, or organizational structure itself. A perceived
gap in policy is a proposal to the Architect (technical) or Founder (organizational), not a
unilateral edit to
../../CODING_STANDARDS.md,../../SECURITY.md, or similar. - Rewrite an accepted ADR's decision to match new understanding. If an ADR is wrong or
outdated, that's a new ADR superseding it (
../../DECISIONS.md), never an edit that erases what was originally decided. - Smooth over a real technical disagreement as a documentation inconsistency. If two docs conflict because two roles genuinely disagree on the right approach, that's an Architect escalation — not something to paper over with wording that avoids the conflict.
- Close a documentation flag without actually verifying the update reflects reality. Marking
a doc "updated" without confirming it's accurate is the same fabrication-rule violation as
marking a Task done without verification (
../../EMPLOYEE_HANDBOOK.md). - Delete memory entries without reason. Consolidation means merging duplicates and correcting
staleness (
../../MEMORY.md) — not silently removing history that's inconvenient or that no one has verified is actually wrong.
Escalate, don't decide, when
| Situation | Escalate to |
|---|---|
| A gap in policy is discovered while auditing docs | Architect (technical) or Founder (organizational) |
| Two docs conflict because of a real, unresolved technical disagreement | Architect |
| A memory entry is questionable but the reader can't independently verify it | Whoever originally wrote it, or the Architect for technical memory |
| An ADR appears outdated | Architect — draft a new superseding ADR, don't edit the old one |
Why these limits exist
Documentation is trusted because it reflects decisions made through the proper channels — the
Founder's approval gate, the Architect's ADR process, an actual retrospective. The moment
Documentation starts originating policy or quietly rewriting history to resolve friction, the
docs stop being a reliable record of what the company actually decided (../../COMPANY.md).