The roadmap was silently gone: four documentation layers and why none of them overlap

The June session was supposed to close out documentation on the /learning/ page. PRD enclosure, roadmap phase entry, brainstorms refiled. An afternoon of housekeeping.

Three problems surfaced instead. The first: the roadmap had been silently lost at some point earlier in the session. Not raised as an error. Not flagged in the devlog. Just absent, discovered only because the explicit instruction was to verify it was there.

The other two followed the same shape. Drift that had accumulated, uncaught, because the layer doing the logging was not the layer responsible for catching that category of problem.

This is the pattern the captainrandom docs stack is built to surface.

The stack assembled in sequence

Nothing was designed upfront. The four layers arrived in order, each one pulled in by a specific gap the previous layer couldn't close.

docs/devlog.md arrived first on 19 May, modelled on the BBBrain convention so the global agent-audit-preflight hook exemption applied here too. Append-only, one paragraph per change, what changed and why. Format is identical across repos because the hook checking it is global.

docs/roadmap.md arrived five days later, on 24 May. Wave 4a of a phased rollout: Wave 1 had shipped the roadmap tooling and git-hooks, Wave 2 backfilled BBBrain as the canonical example. The captainrandom roadmap was the Wave 4a instance. The five-day gap between devlog and roadmap is a clean demonstration of the first blind spot. Session work in that window had a place to log changes. It had no place to record phase membership or scope decisions.

PRD enclosures were the third layer. Each significant area of work gets its own folder under docs/specs/ with a self-contained spec, plan, and brainstorm set colocated. docs/specs/learning-hub/ was the first session to explicitly enforce this shape. It was also the session that surfaced the silently-lost roadmap.

The DVLAW gate is the fourth layer. Topics enter as candidates in a daily digest. Triage happens via Telegram inline buttons. A picked topic goes to thesis variant selection, then Sonnet drafting, then the scrubber, then review. The gate was working before it was documented as a process. In May, the third article through it read noticeably more structured than the two before. Cj noticed and asked whether the method had changed. Auditing the last three articles showed it had. Two steps in actual practice, a triage step and variant-count guidance, had become working convention without ever being written down.

That was Drift A. The gate documentation was updated to six steps.

What each layer catches

The devlog catches what happened. It does not catch whether what happened was in scope for the phase it belonged to, or whether a decision made in an earlier session still holds.

The roadmap catches scope and status. It does not catch the tradeoffs made inside that scope, because it records outcomes rather than reasoning.

The PRD enclosure catches requirements and constraints. It does not catch real-time drift between the spec and the implementation, because the spec doesn't update on every session.

The gate catches publication drift: whether an article would retread already-published ground, and whether the thesis has a genuine angle. It does not catch process drift in the gate itself, or in the layers feeding into it.

Each layer's blind spot is the next layer's coverage.

The silently-lost roadmap in June was catchable only because the explicit instruction was to verify it was present. Without that instruction, the devlog would have logged the session's work and the absent roadmap entry would have registered as nothing at all. No error. No flag. Just a gap that compounds until a session requires the absent thing.

The DVLAW gate drift in May was catchable only because a third article read differently from the first two. The difference was noticed and traced. Without that comparison the undocumented steps would have remained undocumented, and the working method and the documented method would have diverged further with each subsequent article.

Two different kinds of drift, caught by different layers. Neither would have caught the other's problem.

Why redundancy is the wrong frame

A four-layer docs stack looks like redundancy from the outside. Four places to record something. Four checks on the same work.

It isn't. The layers don't overlap. They abut. The devlog records events; the roadmap records scope; the PRD records intent; the gate records publishability. Each one carries a category of information the others don't model. The roadmap cannot be derived from the devlog. The devlog doesn't contain phase boundaries. The PRD describes what should happen rather than what did, so it can't produce the devlog either. Neither can be derived from the gate, which operates at article-level, not session-level.

The compounding is real because the coverage is genuinely non-overlapping. Maintaining all four layers costs more than maintaining any one of them. The return is a different failure mode. Drift surfaces in layers rather than all at once, and each layer's surface is smaller and cheaper to audit than the accumulated drift of a single undifferentiated changelog.

What it costs

The devlog and roadmap overhead is near-zero per commit. Both are hooked into the commit workflow, and the cost of trying to skip them is a hook failure. The PRD enclosure cost is front-loaded on the session that creates it: it requires knowing the shape of the work before the work starts. The gate cost is distributed across a daily triage, a variant pick, and a scrub pass for each article that reaches drafting.

None of this is free. The PRD session for /learning/ was an afternoon of housekeeping that surfaced three problems, which made it longer. The gate update in May required auditing existing articles against the newly documented process to confirm no steps had been silently skipped.

The alternative is cheaper in the short term. A single devlog, updated after each session, is the minimum viable record. It works until you need to answer a question the devlog doesn't model: which phase is this in, what was the original constraint, is this article redundant with the one published three weeks ago. At that point the work of answering is archaeological. Read back through the devlog, infer structure that was never explicitly captured.

The four-layer cost is front-loaded. The single-devlog cost is back-loaded and unbounded.

The shape now

docs/specs/learning-hub/ exists. Roadmap has a Phase 11 entry for the /learning/ work. Brainstorms are refiled. The three problems from the June session are resolved.

The more durable thing the session produced is a clean demonstration of the compounding pattern. The roadmap was silently gone. The devlog had recorded the session work. It took a layer concerned with roadmap integrity to surface the absence. One layer, one blind spot. Four layers, four different kinds of drift caught before they compound into something expensive.

That's what the stack is for. Not redundancy. Differentiated coverage, maintained consistently, with the overhead front-loaded where it can be automated.

All writing