These sixteen principles are the operating rules of DoCoDeGo. If your team follows them, the framework is working. If they routinely violate them, something in the adoption needs to change.
Each principle is violable in a specific way; each violation is observable. Click any to read the principle, the detail, and the most common way teams break it.
Never exceed specification. Refine intent; do not patch symptoms.
When AI builds the wrong thing, the fix is never to patch the code. The fix is to refine the intent that generated it. Hotfixes without spec updates create hidden divergence between intent and implementation — the most dangerous kind of technical debt, because it reappears on every regeneration.
Every interaction begins with a structured, approved specification.
No task assigned to an AI agent without a corresponding spec section covering it. Verbal agreements, Slack messages, and meeting notes are not specs — they are inputs to spec writing. The format scales with complexity; the requirement to have a spec does not scale down.
AI produces correct output when context is complete. Ambiguity causes defects.
When AI generates wrong output, the diagnostic question is "what in the specification was ambiguous enough to produce this?" — not "what is wrong with the AI?" A payment-service spec that uses "appropriate error handling" without defining retry behaviour, idempotency, or timeout thresholds reliably produces an implementation that double-charges on network failure.
Complexity in a specification signals unclear intent. Simplify before proceeding.
If you cannot express it simply, you do not understand it well enough to specify it. A simple spec is not a vague spec — it is a precise spec expressed at the right level of abstraction. Complex acceptance criteria often indicate that the requirement is actually multiple requirements that need to be separated.
Preserve logic, not syntax. Regenerate from improved intent.
Code generated from a spec can be regenerated from an improved spec. The code is not the artefact — the spec is. The corollary: if you cannot regenerate a system from its specification, the specification is incomplete. System invariants (business rules, data contracts, API contracts) are not regenerable — they must be explicitly protected.
Design for reconstruction. Rebuilding is safer than maintaining brittle systems.
A resilient system has clear specifications that allow reconstruction if it fails catastrophically. A robust system has defensive code trying to handle every failure mode, creating complexity AI struggles to reason about. When failure happens, the expected recovery path is: identify the spec gap, update the spec, regenerate the affected components.
Human defines structure before agents begin. AI implements within the architecture, not instead of it.
Before any agent is assigned a composition task, the Composition Lead defines overall system structure, component boundaries, integration points, and non-negotiable constraints. Agents given architectural freedom will make architectural choices — those choices accumulate into systems the human cannot understand or own.
If you cannot evaluate what was built, you cannot be accountable for it.
Technical depth is a governance requirement, not a personal preference. Composition Leads maintain hands-on implementation skills through regular practice separate from production work. A reviewer who rubber-stamps AI output without comprehension has not fulfilled the CO role — they have abandoned it.
Changes demonstrate as fast as validation permits. No artificial delay.
After composition, the next step is validation and demonstration — not a scheduled review, not a fixed release window, not a process gate that does not reduce real risk. Improving validation speed is a legitimate investment. The gate is validation confidence, not the absence of gates.
Deployment telemetry informs the next specification cycle.
Every demonstration cycle generates information. That information must return to the DO phase to improve the next spec. Feedback that is not fed back into DO is waste — it represents learning that will be repeated as a mistake. The Flow Steward aggregates telemetry and flags drift.
You cannot govern what you cannot see. Every demonstrated output includes telemetry.
Every demonstration includes acceptance test results, performance telemetry, error rate monitoring, and behavioural drift indicators. Observability is part of the specification — every acceptance criterion has a corresponding observable metric. Demonstration without observability is release into the unknown.
The unit of delivery is the specification: all or nothing.
A single demonstrated delivery corresponds to one approved specification, fully implemented and validated. Multiple specifications may not be bundled into a single delivery unit — each spec must be independently validated. When demonstration fails mid-stream, automatic rollback to last known-good state.
Humans govern what AI produces. Primary skill: clarity of thought.
The most valuable thing a human brings to an AI-era team is the judgment to decide what to build, the clarity to specify it precisely, and the accountability to own the consequences. Stewardship requires technical depth — engineers who stop practising implementation skills lose the calibration needed to evaluate AI outputs.
Every agent produces auditable reasoning traces. No black boxes.
When agent output is unexpected, the first step is examining the reasoning trace — not re-running the agent with a different prompt. Agents that cannot produce reasoning traces should not be assigned autonomous tasks. Without transparent reasoning, governance is reactive; with it, governance becomes preventive.
Every specification includes a threat model. No exceptions.
Every spec has a Threat Model section with top failure modes, their consequences, and recovery paths. Security acceptance criteria are part of the spec and must pass before demonstration. Security reviewed only after composition is the common failure mode that "security by design" prevents.
No demonstration without governance validation at its required maturity level.
Governance does not slow demonstration by checking boxes — it defines the criteria that define "ready". Meeting those criteria is the demonstration pipeline's job. At Stage 4: acceptance tests pass, confidence threshold met, reasoning trace reviewed, no drift indicators.
Each violation in the most-common-violation field is a point where accountability slips. The statutes exist to make that slip visible before it compounds.
DoCoDeGo is in Alpha. The framework is documented, the practices are battle-tested at small scale, and the next release is being shaped in public.
If it produces anything, it should produce engineers and teams who think more clearly about what they are building and why.
Discord is where specs are debated, the framework gets sharper, and decisions land in writing. The conversation is the artefact.