Operator Competency Model
Status: Complete · The explicit map of what a Conductor must be able to evaluate — because you cannot orchestrate what you cannot judge. This is the operational face of P6 — you own the output.
SAE's most dangerous objection is also its simplest: you can't review what you can't evaluate (Objection 2). One operator, finite expertise, a model that emits confident plausible-wrong output across schema, API, security, frontend, infra, and domain logic. The moment the operator is shallow in a domain, review degrades into rubber-stamping. The framework concedes this fully — it is a hard stop in When NOT to Use SAE.
This page is the answer that makes the concession actionable. It does not promise you become omniscient. It tells you exactly what breadth you must hold to be a fit Conductor, gives you a tell-tale for each gap, and tells you what to do when you find one. Read it as a self-assessment, not a credential.
The seductive misreading of SAE is "the model writes the code, so I need less expertise." That is exactly backwards. The N=1 collapse collapses roles, not knowledge. In a ten-person team, ten people each held a deep slice of competence and the handoffs stitched the slices together. When you collapse the handoffs (O(N²)→O(1)), the cognitive cost does not vanish — it concentrates on you as accountability. You inherit every slice the team used to hold.
| Traditional team | SAE Conductor | |
|---|---|---|
| Depth per domain | Very deep, narrow | Enough to judge, across all |
| Breadth required | One specialty + awareness | Every domain in the slice |
| What collapses | — | The handoff, not the knowledge |
| Failure if absent | A specialist catches it | Nobody catches it |
So the trade is real and it is not free: you give up coordination overhead and you take on generalist breadth at evaluation depth. You do not need to be able to write a query planner. You need to be able to catch a query that will table-scan in production. That distinction — generative depth vs. evaluative depth — is the whole model. Evaluative depth is the floor. Below it, you are not orchestrating; you are gambling.
Reality check. "Enough to judge, across all" is a higher bar than most individual contributors ever cleared, because they were never accountable outside their specialty. SAE is not an entry ramp for juniors. The honest customer is a senior generalist — and pretending a junior can run the loop solo is the precise failure the "you can't evaluate" objection predicts.
Each row is a domain where generated code routinely ships defects that only domain knowledge catches. "What you must be able to do" is the evaluative floor — not how to build it, how to refute it as a Guardian would. "Tell-tale that you CAN'T" is the honest signal that you're rubber-stamping. "If you can't" is the P6 move: own it by routing around the gap.
| Domain | What you must be able to evaluate | Tell-tale that you CAN'T | If you can't |
|---|---|---|---|
| Data modeling & SQL | Read a schema and a query and predict its plan; spot a missing index, an N+1, an unbounded scan, a normalization vs. denormalization mistake, a migration that locks a hot table. | You skim migrations and trust them; "the ORM handles it"; you've never read an EXPLAIN. |
Treat every schema change as high blast radius; pair with a DBA on migrations; load-test before ship. |
| API & contracts | Judge whether an interface is consistent, versionable, and honest about errors; spot a breaking change, a leaky abstraction, pagination/idempotency gaps, contract drift from the spec. | You can't say what makes a change breaking; you accept 200-with-error-in-body; no view on idempotency. | Contract tests as a gate; freeze the public surface; a second reader for any consumer-facing change. |
| AuthN / AuthZ & security | Reason about trust boundaries: where input crosses them, what's authenticated vs. authorized, injection (SQL/command/template/SSRF), secret handling, IDOR, missing rate limits, default-open vs. default-deny. | "Looks fine" on auth code; you can't name the OWASP class for a bug; secrets in the repo don't alarm you; you trust input that crossed a boundary. | Hard stop. Security is the canonical blast-radius gate; pair with a security reviewer; never auto-apply auth changes. See the Verification Doctrine. |
| Concurrency & state | Spot a race, a non-atomic read-modify-write, a lost update, a deadlock ordering, a cache that can serve stale-and-wrong, retry-without-idempotency, an unbounded queue. | You think "it passed the test" proves no race; you can't reason about two requests interleaving; "just add a lock." | Constrain to single-writer designs you can reason about; serialize the irreversible; explicit transaction boundaries in the spec. |
| Frontend / UX correctness | Judge real correctness, not pixels: loading/empty/error states, accessibility (keyboard, ARIA, contrast), input validation, optimistic-update rollback, layout under real data. | You sign off when the happy path renders; never test the error state; a11y isn't on your radar. | Define states in the spec as acceptance criteria; manual pass on error/empty/loading; automated a11y lint as a gate. |
| Infra / deploy & cost | Read IaC and predict blast radius and bill: an open security group, a public bucket, an unbounded autoscale, a terraform destroy path, a per-request cost that compounds. |
You apply infra changes you don't fully read; surprised by the bill; can't trace what a plan will actually mutate. |
plan-before-apply always; cost ceilings/alerts; irreversible infra never auto-applies; pair on production topology. |
| Dependency & supply-chain risk | Judge whether a dependency is safe to add: maintenance, transitive bloat, license, known CVEs, typosquats, and whether the model invented a package that doesn't exist (slopsquatting bait). | You add whatever the model imports; never check the lockfile diff; "it's on npm so it's fine." | Pin and audit; lockfile diff in review; deny-by-default new deps in high-blast-radius slices; verify every package exists and is the real one. |
| Domain / business logic | Verify output against the actual domain: the regulation, the money rounding, the edge case a real user hits, the rule that is true in this business and nowhere else. | You can't tell whether the rule is correct, only whether it runs; you'd accept a plausible refund calc you can't independently check. | This is the irreducible gap — no Guardian fixes a wrong spec. Pair with the domain owner; encode rules as testable examples in the spec. |
Reality check. A shared blind spot is the worst case and the matrix cannot save you from it. If you are wrong about the domain rule, you'll write a spec that's wrong, the Engineer will implement it faithfully, and the Guardian — briefed on that same spec — will confirm it. Adversarial Independence reduces correlated error; it does not eliminate it when the operator and the contract are wrong in the same direction. That residual risk is exactly why the bottom row routes to a human domain owner rather than to a better prompt.
Score each domain 0 / 1 / 2 against the row above:
- 0 — Can't evaluate. You'd accept confident wrong output. You are rubber-stamping.
- 1 — Can evaluate with effort. You can catch obvious defects and know when to slow down and look closer.
- 2 — Fluent. You can refute like a specialist; you know the failure modes cold.
Then apply the gate, scored per slice, not as a lifetime average:
The threshold. A 0 in any domain that the current slice touches at high blast radius is a hard stop — pair with a human expert or don't ship that slice. A 1 is acceptable only with extra verification (diverse-lens Guardian passes, slower gates, a second reader). A high average does not rescue a single 0 in a high-stakes domain — a 2 in frontend does not let you ship an auth change you score 0. The minimum, not the mean, governs the irreducible domains (security, data, domain logic).
This is P6 made concrete: owning the output means owning the honest count of your own gaps and routing around them on purpose. The point of scoring is not a badge — it is to convert "I think I can review this" into "I can name, per domain, whether I can." The first is faith. The second is the floor SAE requires.
Reality check. Self-scoring is self-reported, and the Dunning–Kruger trap is real: the operator least able to evaluate a domain is the least able to score their inability to evaluate it. A 0 often feels like a 1. The defense is mechanical, not introspective — if you cannot produce the tell-tale's opposite on demand (read the
EXPLAIN, name the OWASP class, describe the race interleaving), score it down. When in doubt, you are a 0.
The competency model is not a standalone checklist — it is the input to three other mechanisms:
- It feeds blast-radius gating (P5). Your score in a domain raises or lowers the gate for changes in that domain. A 0 doesn't just warn you — it reclassifies the change as requiring a human.
- It bounds the Guardian (P3). Adversarial Independence catches correlated implementation error. It does not catch error you and the spec share. Your competency map tells you which domains the Guardian can not save you in — those are the domains where a human pair is mandatory, not optional.
- It calibrates Context Entropy (P1). A slice that touches a domain you score low in is higher entropy for you specifically — more prep, smaller slices, tighter verification — regardless of its objective difficulty. Competency is a personal multiplier on preparation difficulty.
The honest summary: SAE does not lower the expertise bar. It raises it to a generalist evaluative floor and then gives you the instruments — the matrix, the score, the gate — to know precisely when you are standing on it and when you are not. The operators SAE fits are the ones who can take this assessment and not flinch at their own zeros.
See also: The Verification Doctrine · Objections · When NOT to Use SAE · First Principles · Module 3 — The Digital Org Chart · Risks, Security and Governance · The Maturity Model · Module 5 — Project Navigation and Metrics · Glossary