First Principles
Status: Complete · The seven principles SAE is derived from. This is the canon — every other page cites these numbers instead of restating its own variant.
Most frameworks are a pile of tactics with no spine. SAE has a spine. Everything else — the Manifesto creed, the Four Pillars, the Best Practices non‑negotiables, the Digital Org Chart roles — is a consequence of these seven, derived from a single observation:
When the marginal cost of generating code approaches zero, the binding constraint stops being syntax and becomes clarity. Syntax cost collapsed. Clarity, verification, and accountability did not.
Read that twice. The rest of SAE is just what falls out when you take it seriously. The principles are numbered so they can be referenced precisely (P1–P7). When another page says "see P3," this is where it points.
Optimize for clarity, not speed. Speed is now free; the scarce resource is a precise, unambiguous statement of what you actually want.
Why it follows. If generating code is near‑free, then the cost of a system migrates entirely upstream — into deciding what should exist and why. The bottleneck is no longer typing; it is the Context Entropy of the work: how hard the intent is to pin down before a single line is generated. That preparation difficulty is the unit of work and the moat.
In practice. You score a task's preparation difficulty (1–13) before you start. High‑entropy work gets more spec, smaller slices, and tighter verification — not more keystrokes. You measure where time actually goes and find it is in disambiguation, not generation.
→ Deeper: Module 5 — Project Navigation and Metrics · The 12 Layers of Friction
Write the spec; generate the code. Never the reverse. The Markdown specification is the supreme artifact. Code is a build output of the spec.
Why it follows. If clarity is the constraint (P1), then the artifact that holds clarity must be authoritative — not the code, which is a lossy, syntactic shadow of intent. Spec‑Driven Development is not ours; the prior art is real (GitHub Spec Kit, AWS Kiro). Our delta is the instrumentation: we don't just write specs, we measure drift between spec and code and treat divergence as a tracked defect.
In practice. Bugs and changes are fixed in the spec first, then regenerated. specs/ is versioned in the same commit as src/. Drift is monitored, not assumed away.
Reality check. "Never edit code directly" is the ideal that keeps the spec authoritative. Under pressure you will hand‑fix a one‑liner. The discipline is to fold it back into the spec the same day — a stale spec is worse than none, because everyone (including the agents) trusts it.
→ Deeper: Module 2.3 — Spec‑Driven Development · SDD Spec Template
Verification must come from a fresh, adversarial context whose job is to refute, not approve. This is Adversarial Independence — a co‑equal moat alongside Context Entropy.
Why it follows. Clarity (P1) is worthless if you cannot confirm it was achieved. A context that just generated code is the worst possible judge of it — it shares every assumption it made. So verification is delegated to a separate Guardian with a clean context, briefed to find what's wrong (grey‑box refutation), not to bless what's right.
In practice. The Guardian reviews the diff, not its own output. It uses diverse lenses for high‑stakes changes instead of repeating one identical check. Confirmation is not a pass; an unrefuted change is.
→ Deeper: Module 3 — The Digital Org Chart · Operator Techniques
Engineer the codebase so any one slice can be understood — and changed — without reading the rest. Strict, self‑contained vertical slices with narrow contracts.
Why it follows. Clarity (P1) degrades with scope. Both humans and models lose precision across sprawling, loosely‑coupled code; a fresh context can hold a small cohesive slice but hallucinates across a 1,000‑line monolith. Isolation is how you keep the clarity per unit of context high enough to reason and verify reliably.
In practice. A self‑documenting features/<slice>/ layout. Files target a single responsibility (~100 lines as pressure, not law). The test: can a fresh context understand this file without opening six others?
→ Deeper: Module 2.2 — High‑Context Modular Design · Best Practices
The cost of a mistake — not its likelihood — decides how much human gating it gets. Auth, payments, deletion, and schema drops never auto‑apply.
Why it follows. Near‑free generation (P1) means near‑free mistakes at scale. You cannot verify everything to the same depth, so you triage by consequence: reversible changes flow fast; irreversible ones stop at a human gate. This is how SAE stays fast without being reckless — speed on the cheap‑to‑undo, friction on the impossible‑to‑undo.
In practice. A blast‑radius classification on every change. High‑blast‑radius operations require explicit human authorization and an independent (P3) review before they touch production.
→ Deeper: Risks, Security and Governance · KPIs and Metrics
The operator is accountable for everything shipped — no agent, vendor, or model absorbs that. Accountability does not delegate.
Why it follows. This is the honest core of the thesis: coordination cost drops (handoffs collapse, O(N²)→O(1)), but cognitive cost is conserved and concentrated — onto one accountable operator as judgment and liability. "Collapse the handoff, not the headcount." The model is a force multiplier on clarity, never a substitute for ownership of the result.
In practice. Generated code is read, understood, and signed off — never shipped on faith. The N=1 Architect‑Engineer collapse is a consequence of the principles, not a goal, and it is the least defensible claim: it concedes a real bus‑factor risk. The mitigation is P2 — the spec is the succession plan.
Reality check. Concentrating accountability on one person is a single point of failure. SAE does not pretend otherwise. The bet is that a rigorously maintained spec (P2) lets a successor reconstruct intent — which is only true if you actually keep the spec current.
→ Deeper: Module 1 — The Sovereign Paradigm Shifts · When Not to Use SAE
Every bold claim ships paired with a named Reality Check. Honesty is a first‑class feature, not a disclaimer.
Why it follows. If clarity is the product (P1), then self‑deception is the primary defect. A framework that oversells — "execution collapsed," "skip testing," "headcount goes to zero" — corrupts the very clarity it claims to protect. So SAE competes on discipline and measurement, not hype: a claim without its honest limitation is treated as incomplete.
In practice. Reality Check callouts sit beside the strong claims throughout this wiki. Projections are labeled as projections; measured results are labeled as measured. Limitations are stated up front, not buried.
→ Deeper: The SAE Manifesto · Objections · FAQ
Other pages express these principles in their own idiom — but they all reduce here:
| Where you'll see it | What it is | Derives from |
|---|---|---|
| The Manifesto creed | The emotional, declarative form | All seven |
| The Four Pillars | The structural how | P2, P3, P4 |
| Best Practices non‑negotiables | The standing Do/Don't rules | P2–P5, P7 |
| The Digital Org Chart | Roles that enforce them | P3, P5, P6 |
| KPIs and Metrics | What we measure to prove them | P1, P5, P7 |
If a practice elsewhere in the wiki cannot be traced back to one of P1–P7, treat it as suspect — it is either a tactic that needs a principle, or a principle that needs deleting. Cite the number; don't restate the rule.
See also: The SAE Manifesto · Framework at a Glance · Module 2 — Core Pillars · Best Practices · Evolution and Positioning · Objections · Glossary