Skip to content

The SAE Guide

Sanjeev Azad edited this page May 29, 2026 · 1 revision

The SAE Guide

Status: Complete · SAE Guide v1.0 — the canonical definition of the Sovereign Architect-Engineer Framework; see Governance, Versioning & Stewardship.

This Guide is the single source of truth. Every other page in this wiki — the Manifesto, the Modules, the playbooks — elaborates what is stated here. Where elaboration and Guide disagree, the Guide governs. It is deliberately terse and deliberately complete.


Definition

SAE (Sovereign Architect-Engineer) is a framework for one accountable operator to take software from intent to production by treating a versioned specification as the source of truth, generating code from it, and verifying that code in a fresh adversarial context. It exists for one reason: when the marginal cost of generating code approaches zero, the binding constraint stops being syntax and becomes clarity — and clarity, verification, and accountability did not get cheaper. SAE competes on discipline and measurement, not speed. It collapses the hand-off, not the headcount: coordination cost drops from O(N²) to O(1); cognitive cost is conserved as accountability.


The Theory

Generation is now free; specification is not. The cost of a system has migrated entirely upstream — into deciding what should exist and why — so the unit of work is no longer keystrokes but the difficulty of pinning down intent before a line is written. Everything in SAE falls out of taking that one observation seriously.


The Roles

Four conceptual roles. They may be four tools, or one model wearing four hats across four prompts — the separation of concerns is what matters, not the tool count.

  • Conductor — the human; the sole accountable owner; frames, specs, primes, rules on every diff, closes every loop.
  • Visualizer — generative UI; turns product intent into semantic interface components.
  • Engineer — repo-aware code generation; turns the spec into a vertical slice (schema → API → state → UI).
  • Guardian — fresh-context adversarial QA; reviews the diff to refute, not approve; never judges its own output.

The Operating Loop

Ten phases. The loop is spec-centric: every change re-enters at Spec, never at the code.

# Phase One line
0 Frame State the intent, rate its entropy, name the blast radius.
1 Spec Write the bounded-context spec, including edge cases.
2 Prime Load the agent with only the context it needs.
3 Generate Produce the vertical slice from the spec.
4 Review Confirm the diff matches the spec; reject structural drift.
5 Guard Adversarial verification in a fresh context.
6 Reconcile Fold every fix back into the spec; restore spec ⇄ code sync.
7 Ship Push through the Zero-Ops pipeline to production.
8 Observe Route production telemetry back to the operator.
9 Maintain Turn every incident or change request into a spec amendment → re-enter at 1.

The Artifacts

  • The spec. The Markdown specification is the supreme artifact and the source of truth. Code is a build output of the spec. specs/ is versioned in the same commit as src/, and drift between them is a tracked defect, not an accepted fact.
  • .cursorrules. The standing constitution that primes every agent context — the constraints, conventions, and bounded-context contracts the Engineer and Guardian must obey before they read a single spec.

The First Principles

The canonical imperatives (P1P7). Cite by number; the First Principles page carries the full derivation.

# Imperative
P1 Clarity is the binding constraint — optimize for clarity, not speed.
P2 The spec is the source of truth — write the spec; generate the code; never the reverse.
P3 The writer never judges its own work — verify in a fresh, adversarial context.
P4 Isolate bounded contexts — any slice must be changeable without reading the rest.
P5 Gate the irreversible by blast radius — a human decides what cannot be undone.
P6 You own the output — "the AI wrote it" is not an explanation an operator gets to give.
P7 Honest by construction — every bold claim ships with a named Reality Check.

The Unit of Work

The unit of work is Context Entropy: the preparation difficulty of a task — how hard its intent is to pin down before generation — scored 1–13 before work begins. Ceremony scales with entropy. High-entropy work earns more spec, smaller slices, and tighter verification; low-entropy work earns less. Entropy, not story points or hours, is what SAE estimates and measures.


What SAE Deliberately Omits

SAE has no mandated calendar ceremonies, no fixed role roster beyond the four conceptual roles, and no certification gate. These are omissions by design, not gaps awaiting a future version.

  • No mandated ceremonies. A single accountable operator has no hand-offs to synchronize; standups, fixed-cadence planning, and retrospectives exist to coordinate a team that SAE does not have. Ceremony scales with Context Entropy, not the calendar.
  • No fixed roles beyond the four conceptual ones. The four roles are functions, not headcount. Mandating a person per role would re-import the O(N²) coordination cost SAE exists to collapse.
  • No certification. Competency is demonstrated by shipped, verified, owned output — measured by the Operator Competency Model and KPIs — not conferred by a credential. A certificate measures attendance; SAE measures outcomes.

Definition of "SAE"

A workflow is SAE only if it holds all five of the following. Break one, and what you are running is not SAE — it is something else borrowing the name.

  1. The spec is the source of truth. Code that disagrees with the spec is a bug in one of them, reconciled immediately. (P2)
  2. The writer never judges its own work. Verification comes from a fresh, adversarial context tasked to refute. (P3)
  3. The irreversible is human-gated. Auth, payments, deletion, schema drops — a human decides, never auto. (P5)
  4. Bounded contexts are isolated. Any slice is understandable and changeable without reading the rest. (P4)
  5. One operator owns the output. Accountability is named and non-transferable. (P6)

This Guide is intentionally short and intentionally complete. If a question about what SAE is is not answered here, the answer is on this page in a form you have not yet read — or it is an elaboration, and belongs elsewhere. The definitions above do not hedge; the honest hedging lives as Reality Checks on the elaboration pages, exactly as P7 requires.

See also: Governance, Versioning & Stewardship · First Principles · The End-to-End Lifecycle · Framework at a Glance · The SAE Test.

Clone this wiki locally