DPCD & The Compounding Loop — Consolidated Reference v1

Human-gated — cannot close without your explicit confirmation AI self-loop — iterates unattended, escalates only when stuck Work phase

LAYER 01

The Compounding Loop

The philosophy. DPCD is one implementation of it, not the thing itself.

Guidance and compounding are co-equal requirements. A process that guides but does not accrete forgets everything between cycles; a process that accretes but does not guide produces a knowledge base nobody can act on.

The layering matters because it decides where a fix belongs. If a gap is in how the phases are enforced, it is a DPCD problem. If a gap is in what compounding means, it is a Compounding Loop problem and every implementation inherits it.

JetBrains' YouTrackDB workflow book is a sibling implementation of the same principle, not a rival philosophy — which is why its phase skeleton matches DPCD almost exactly (research → design+plan → implement → finalize) and every meaningful difference is about enforcement rather than shape.

Governing rules at this layer

One fact, one home. No truth is duplicated across documents. If it lives in the ADR, it does not also live in the operations doc.
Every phase exits with an artifact. State is session-scoped and dies with the session; the artifact is what survives, and therefore the only thing that can be asserted about later.
Compounding has a cost function. Every rule added to an always-loaded surface is rent charged to every future session. Named as a gap — see Layer 03, item 4.
Gates must be disjoint. Each gate has a forbidden question; two gates that both ask "is this right?" are one gate run twice. Named as a gap — see Layer 03, item 1.

Principle-layer finding

Compounding is not free

A compounding methodology that does not say what it costs will drown in its own knowledge base. This is the sharpest thing taken from the YouTrackDB comparison, and it is a hole in the philosophy — not merely in DPCD's implementation of it.

What DPCD has that the sibling implementation does not

Cross-change domain knowledge. YouTrackDB deletes its research log at the finalize phase; only the adversarial verdict folds into the ADR. It compounds the process, not the codebase understanding. DPCD compounds both.

LAYER 02

DPCD — settled spec (v4)

Discuss → Plan → Review 1 → Code → Review 2 → Document. Six phases; two of them are gates.

Each phase both deposits intent and gates the next one. The deposit is what compounds; the gate is what guides.

01 Discuss Human-gated

Deposit: Goals and constraints, stated by you, in your words.
Target: At least 50% interactive. Discuss is where the loop earns its keep; every phase after it is cheap by comparison.
Mechanisms: Question-first default — on a new problem statement the AI responds with questions only, no solutioning, unless explicitly released with "just plan it".

Question quota — Discuss cannot close until a minimum number of question/answer rounds have happened. Default 3, adjustable.

Understanding checkpoint — before Plan, the AI restates the problem and scope in its own words and waits for explicit confirmation ("yes, proceed" / a correction).
Exit condition: Quota met AND checkpoint confirmed. Not either/or.

02 Plan Most important artifact

Deposit: The approach, and — critically — what was not chosen.
Template: Intent — what this change is for, traceable to Discuss.

Approach — how it will be done.

Constraints carried forward — what must remain true afterwards.

Rejected alternatives — options considered and why they lost. This is the field that stops the next session re-litigating a settled decision.
Storage: Committed as a file (plan.md), not held in a thread. The repo is the artifact store.

03 Review 1 AI self-loop

Position: Post-Plan, pre-Code.
Catches: "Solving a symptom" and "incomplete coverage".
Checks: Root-cause check — the AI must state what the root cause is and how the plan addresses it, not merely assert that it does.

Requirements coverage — plan steps lined up against the Discuss requirements; any requirement with no corresponding step is flagged.

Assumption check — every assumption made during planning surfaced explicitly.
Autonomy: Finds a gap → fixes it → re-checks → loops until it passes. You are pulled in only if it gets stuck (unresolvable requirement conflict, root-cause question it cannot answer alone).

04 Code Autonomous

Deposit: Applies existing conventions; surfaces any new invariant the implementation introduces, so it can be captured rather than discovered later by breaking it.
Divergence: Permitted, but never silent. Divergence from the plan must be called out so Review 2 can judge it.

05 Review 2 AI self-loop

Position: Post-Code, pre-Document.
Catches: "Implemented the wrong thing" and "partial implementation".
Checks: Requirements-to-code trace — each requirement mapped to the specific change that satisfies it.

Plan-fidelity check — did the code diverge? If yes, was the divergence justified and declared, not silent?

Side-effect scan — anything touched that was not in the plan.
Autonomy: Same as Review 1: self-contained loop, escalates only when stuck.

06 Document Closes loop

Deposit: Confirms the outcome matches the original intent from Discuss — not the intent as it drifted. This is what makes the loop a loop rather than a line.

The single fallback rule

Any review failure that cannot self-resolve, or that touches a requirement, falls all the way back to Discuss

Never to an intermediate phase. Plan and Code can be short on re-entry precisely because Discuss resolved the gap upstream — re-entering at Plan would carry the same broken premise forward, which is the failure the rule exists to prevent.

Session model

DPCD state is always session-based and every session always leaves with an artifact. That splits the state cleanly:

Ephemeral layer — current phase, question-quota status, review verdicts. Lives in the session, loses nothing when it dies.
Durable layer — the artifact. The only assertion that outlives the session is "artifact exists, artifact is reviewed."

The consequence is enforcement-shaped: CI cannot gate on phases, because phases are not durable. It can only check that the artifact landed. The gate is a human decision inside the session; the mechanical check is downstream of it.

Repository estate

Three tiers, distinguished by how often they are written — which is also how you decide where a new fact goes.

compounding-loop-starter/ ├── README.md entry point ├── AGENTS.md loop memory — read/written every cycle ├── plans/ loop memory — plan.md per change ├── docs/ │ ├── adr/ living reference — updated on decision │ ├── operations/ living reference — updated on change │ ├── diagrams/ living reference — updated on change │ └── artifacts/ produced — generated on demand, never maintained └── tests/ living reference Tier 1 loop memory read and written every cycle Tier 2 living references updated when the thing they describe changes Tier 3 produced artifacts generated on demand, never maintained

Skill folders exist for the discuss, plan and document stages, plus a loop agent file. The structure is deliberately tool-agnostic: it maps onto both Claude Code and GitHub Copilot via their respective native file conventions, so the methodology is not hostage to one vendor's harness.

LAYER 03

Proposed amendments (v5)

Ranked by value-to-DPCD ÷ cost-to-adopt. Grafted from the YouTrackDB structural diff.

Not adopted Nothing in this section is part of the spec. v4 stands unmodified. Items 1 and 4 are principle-layer gaps — they belong to the Compounding Loop and every implementation inherits them. The rest are DPCD implementation detail.

#	Mechanism	Verdict	Cost & rationale
01	Single-challenge rule + comprehension-only second gate Principle layer	ADOPT	Cost: prose. Both current gates drift toward "is this right?". Split them by forbidden question: Gate 1 attacks decisions; Gate 2 is forbidden from re-litigating them and only asks whether a cold reader can build a working model from the document alone, plus the absorption check — every decision in the Discuss log appears in the Plan, and the Plan invented none the log never made. Highest value per word changed in the list.
02	Mechanical trigger for fallback-to-Discuss	ADOPT	Cost: one sentence. Current rule is a judgment call. Mechanical version: a new load-bearing decision surfaced during Plan → append it to the Discuss log, re-challenge it there, and Gate 2 may not run until it clears. Converts a vibe into a named trigger.
03	Tier gate — ceremony scaled to change size	ADOPT	Cost: one section. Two routing questions, three tiers, an artifact set per tier. Fixes DPCD's actual failure mode: it gets skipped on small changes because it is all-or-nothing. Categories must be your own — data correctness, erasure/GDPR semantics, IAM/policy surface, table-format or schema migration, cost hot path, public interface, methodology machinery. The category must be what the change is about, not something it brushes.
04	Priced improvement gate Principle layer	ADOPT	Cost: a formula plus the discipline to run it. `load_cost` = paragraphs added × placement multiplier (always-loaded file ≈ 15–20× an on-demand one), weighed against `self_fix_cost` = turns per recovery × sessions that hit the trigger. File only at ≥5×; cap one per session; zero is the expected outcome. Fixes a real defect, not polish. Without it the loop compounds into a context tax paid every session.
05	Handoff file with verbatim re-present text	ADOPT	Cost: low. When a session runs out of room mid-phase, write a file whose key field is the exact prompt the next session must show you — not a paraphrase of the decision you were half-way through making. On resume it outranks every other marker and must be resolved before any routing. You hit this constantly on long artifact sessions.
06	Risk tag per step, sharing the tier gate's categories	ADAPT	Cost: low. One source of truth read at two granularities — change-level (which tier?) and step-level (does this step get its own review?). Only worth it once step-level review exists at all.
07	Session-per-phase + phase ledger	ADAPT	The mechanism is sound and it is the one most missing: the session that argued the design biases the plan derived from it; the session that wrote the code biases its review. But the reference implementation assumes a filesystem and an auto-resuming skill. In a chat client you would hand-carry a ledger artifact between chats — friction you will abandon by week two. In Claude Code / Copilot it is natural. Adopt the boundary (new session per phase, state written down before you clear); skip the append-only last-value-wins machinery until an agent can read the file itself.
08	Dimensional review fan-out	ADAPT	Take the shape, not the roster: triage the diff → select lenses by characteristic → normalize severities → location-collapse synthesis → on iteration 2+ run a gate check rather than a re-review, each reviewer verdicting only its own findings under a tight output budget, capped at 3 then escalate. Three or four lenses, not sixteen. Keep the upgrade-only severity backstop even with three lenses.
09	Mutation discipline on the design document	DEFER	Worth it only for a long-lived, multiply-edited design artifact. Data Matrix qualifies. TerraLab does not.
10	Workflow-SHA stamps + drift migration	SKIP / PART	Skip the machinery, keep the stamp: mark each artifact with the spec version it was written against. The new-filename-per-version convention is already half of this. The migration-replay engine solves a problem you do not have — you are the sole author of your own spec, so you feel the drift directly.

LAYER 04

Open threads

Decisions raised and left unresolved. Listed so they stop re-surfacing as if new.

UNWRITTEN

Compounding Loop amendment

Items 1 and 4 above are principle-layer gaps. The proposal was to write them as an amendment to the Compounding Loop document — the cost function plus the gate-disjointness rule — leaving DPCD v4 untouched. Never drafted.

DESIGN SETTLED
BUILD PENDING

Card-driven DPCD UI tool

One hard constraint decided: the UI is a projection of repo state, never the source of truth. Phase, gate approvals, quota status and review verdicts land in the repo (plan.md frontmatter or .dpcd/state.json on the branch); the UI only renders them. If state lived in a fork's local store the fork becomes load-bearing and upstream churn costs you the methodology, not just a UI. Open: fork T3 Code vs. standalone prototype — with the prior step being to check whether T3 Code's custom-actions surface can carry it without a fork at all. Flagged as a good candidate to move into Cowork (multi-file, iterative build/test/commit).

IN FLIGHT

DPCD phases as the cost-attribution unit

AI credit cost per PR, split by DPCD phase. The phase boundaries are what make the spend interpretable — the measurement itself is commoditising fast, but "does front-loading Discuss compress downstream rework?" is a claim about how to work, and it is only askable because session boundaries map onto phases.

OBSERVED

Internalization gap

The workshop series surfaced it: people can follow DPCD as steps without internalizing why the gates exist. Named independently by a peer at another institution the same week, which suggests it is structural to the methodology class rather than a local rollout problem.

APPENDIX

Provenance

Where each part came from, so you can go back to the argument rather than just the conclusion.

Compounding Loop framing, four-stage deposits/gates, repo estate, "one fact, one home" — starter-skeleton rebuild session, 07 Jul 2026.
Discuss mechanisms, both review gates, the single fallback rule, the v4 spec document — workflow-issues session, 09 Jul 2026. Produced compounding-loop-full-spec-v4.md.
Philosophy/implementation split, the ten ranked mechanisms, the priced-gate finding — YouTrackDB structural diff session, 14 Jul 2026.
Session-scoped state, artifact-only durability, UI-as-projection constraint — T3 Code fork session, 13 Jul 2026.
Cost-attribution framing — AI credit tracking session, 18 Jul 2026.

Status of this document: Layers 01–02 are settled and reflect v4. Layer 03 is a proposal set with no adoption decision taken. Layer 04 items are open by definition. Nothing here supersedes compounding-loop-full-spec-v4.md; this is a consolidation, not a new version of the spec.