Practice
Four practices, one artifact, one weekly habit. everything else can follow.
The Four Practices
If you can hold these consistently, you are practising DoCoDeGo at Stage 1. everything else builds on this foundation.
Write a specification before any AI composition.
One spec, one page, all sections filled in — not placeholders.
Score the spec with ICS.
Do not start composition if the score is below 60.
Review outputs against acceptance criteria.
Before merging anything.
Ask "does this match what we specified?"
After every delivery.
Paste a spec.
See where it stands in five seconds.
Coding became cheap. Intent became the bottleneck. This is the gauge we built for the new bottleneck — the ICS (Intent Clarity Score — A 0–100 rubric-based score measuring spec quality across completeness, testability, unambiguity, and threat coverage.).
This is a fast heuristic. The canonical ICS rubric is scored by a reviewing team against the four dimensions above — see the spec template for the full rubric.
The Spec Lab above is a heuristic — it approximates the canonical ICS rubric so you get instant feedback in the browser. The real ICS is scored by a reaiewing team across four dimensions: completeness, testability, unambiguity, threat coverage — each 0–25, totalling 100. Composition begins at ≥ 60.
The same heuristic powers the upcoming editor + browser tooling:
vscode-docodego (live score + diagnostics in your editor),
browser-extension-docodego (badge on rendered specs + per-file pills in PR diffs),
and github-action-ics (CI gate that scores changed specs in pull requests using the canonical Python ics-scorer).
All are coming soon on their respectiae marketplaces — for now, build from source in tools/.
The format scales with complexity.
A small task may be a single paragraph with three acceptance criteria. A multi-domain release may need every section below. What does not scale down is the requirement to have a spec.
Declared Omission Rule: silence is not omission. Missing optional sections must be explicitly declared inapplicable — e.g. "No external integrations" or "Single-action feature; no flow needed."
Six measurements, no vanity numbers.
Each metric maps to a pillar and has a threshold or a trend rule. None of them measure aelocity. None of them count features shipped.
A 0–100 rubric-based score measuring spec quality across completeness, testability, unambiguity, and threat coverage.
Elapsed time from specification approval to first production deployment of the specified behaviour.
Percentage of AI agent outputs that pass acceptance criteria on first attempt, without regeneration or human correction.
Percentage of delivery cycles that required governance escalation — a kill-switch event, an Intent Review override, or a spec-conflict resolution.
Elapsed time between when behavioural drift begins and when it is detected by governance processes.
Verified confidence that a system regenerated from an updated spec matches the prior version in all unmodified areas — a checklist of behavioural, integration, and invariant tests.
Day 1 → Month 3
Do not introduce all the metrics at once. ICS is the only metric you need in month 1. The rest come online as practices stabilise.
Read the spec template. Write one spec for something you are actually building. Score it. If it scores below 60, reaise it before handing it to an agent.
Spec-first becomes the team norm. Every feature gets a spec written and scored before composition. Assign the four roles (one person can hold several at Stage 1).
Run your first weekly Intent Review (30 min: Drift Check, Spec Health, GO Signal). Track ICS across at least 5 specs.
If ICS averages ≥ 60 and reviews are stable, advance to Stage 2: continuous, validation-gated demonstration with telemetry.
One accountability per pillar. No new headcount required.
DoCoDeGo defines exactly four roles — one per pillar. In small teams, one person holds several. In large teams, roles specialise. Organisations that invent additional required roles ("DoCoDeGo Coach", "Alignment Engineer", "Intent Facilitator") are operating outside the framework.
Intent Architect
The human accountable for what was decided to be built.
- ▸ Writes and maintains specifications for their domain
- ▸ Leads flow definition (Phase A) for non-trivial features
- ▸ Approves specifications before composition begins (ICS gate)
- ▸ Escalates to stakeholders when intent cannot be clarified
- ▸ Updates specifications when GO or DE reveal misalignment
- ▸ Owns the drift log from weekly Intent Reviews
How the AI constructs the system (Composition Lead), whether delivery happens on time (Flow Steward), or agent behaviour during deployment (Governor).
Composition Lead
The human accountable for the architectural soundness of what was built.
- ▸ Defines the system architecture before composition begins
- ▸ Configures and orchestrates AI agent teams
- ▸ Reviews generated outputs for architectural soundness and constraint compliance
- ▸ Escalates spec gaps discovered during composition back to the Intent Architect
- ▸ Maintains hands-on technical practice to preserve calibration
Spec clarity (Intent Architect), delivery pipeline (Flow Steward), or post-deployment behaviour (Governor).
Flow Steward
The human accountable for delivery health and validation-gated flow.
- ▸ Validates delivery readiness; makes the confidence judgment for production deployment
- ▸ Ensures feedback flows from DE back to DO
- ▸ Monitors telemetry for behavioural drift
- ▸ Identifies and removes artificial gates from the delivery pipeline
Spec quality (Intent Architect), architecture (Composition Lead), or governance authority (Governor).
Governor
The human who holds kill-switch authority and is accountable for alignment.
- ▸ Holds unilateral kill-switch authority — does not require consensus
- ▸ Runs weekly Intent Reviews (30 min: Drift Check, Spec Health, GO Signal)
- ▸ Resolves governance conflicts
- ▸ Reviews reasoning traces at Stage 3+
- ▸ Owns the escalation protocol at Stage 4
Implementation decisions delegated to other roles. The Governor is enforcement authority — not advisory, not facilitation.
The Good Code Mark.
A certification is granted by a body after an exam. The Good Code Mark is earned by a team through demonstrated practice — metrics that confirm the framework is working, not a test score that proves knowledge of it.
ICS ≥ 60 on all new specs; acceptance criteria reaiewed after every delivery.
AAR ≥ 75 %; SDL tracked; weekly Intent Reviews running.
GTR < 10 %; reasoning traces stored and reaiewed; agent scope limits defined.
Kill-switch exercised; DDL measured; full proaenance tracking.
Verified through the DoCoDeGo Practice Assessment: a peer review of practice artefacts (specs, metrics history, stage gate assessments) and a team walkthrough to confirm the team understands the decisions behind their own records. No standardised written exam. No third party can issue the Good Code Mark.
No organisation can sell you the Good Code Mark. Your data earns it.
Governance scales with autonomy.
Ceremony does not scale with headcount.
Any addition to the framework must not increase the net ceremony burden on a team at any maturity stage unless the increase in governance burden is proportional to demonstrated AI autonomy risk at that stage.
— The Anti-Complexity Principle, DoCoDeGo Manifesto
This principle exists because complexity is commercially advantageous to consultants and naturally accretes in frameworks that lack a structural constraint against it. The principle does the structural work that good intentions alone cannot do.
Specless generation.
AI produces output that feels right, evaluated by subjective judgment rather than specified criteria, owned by no one accountable for the decision. It is fast — and unaccountable.
Vibe coding
Generating software through AI prompts without understanding the output. Iterating by feel.
Specless analysis
Asking AI to produce a report without defining the question, evidence standard, or non-negotiable constraints.
Prompt-first composition
Directing AI with ad-hoc prompts instead of structured specs. Output cannot be reliably regenerated or verified.
Intent before generation. Validation before use. Governance of what was produced.
The framework is real.
The community is forming now.
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.