Decision
Backfill the roadmap with the platform-infrastructure work that
shipped before the roadmap surface existed. Each backfilled project
gets a captured_retroactively: true flag visible on its page, plus
an explicit disclaimer in the body, so a reader can always tell
which projects are first-class records and which are honest
post-hoc reconstructions.
Why
Entry 016 commits founder time to credits at the same denomination contributors will earn. The roadmap surface (P-001) and the reactions thin slice (P-002) shipped with the roadmap and got clean records. Everything before that — the Phase 1 network shell, the Founder's Journal corpus and routes, the Gap Register, the admin dashboard, the Decision Journal Claude skill — is real work that, if it goes uncaptured, makes the founder credit total artificially low and inverts the principle. The same denomination is worthless if half the founder work isn't on the ledger.
The alternative — declaring "credits start the day P-001 ships" — would be cleaner administratively but dishonest about the actual work done. It would also create the wrong incentive for future contributors: a contributor reading the roadmap should see what the platform took to build, not just what's been built since the ledger started.
What this entry commits to
- An expanded retroactive project set: P-006 through P-013 cover the Phase 1–5 integration work plus the pre-roadmap engagement capture session, and P-014 through P-023 cover the multi-year conceptual and architectural work that produced everything the platform expresses (OLN / LoreDoor split, stewardship governance, brand architecture, trust & safety, economic primitives, the Commons / Home / LoreLines surface architecture, sovereignty design, the years of synthesis sessions with Brandon, the founding charter draft, and the bootstrap of the project itself).
- Each retroactive entry carries
captured_retroactively: true, surfaced as a chip in the project header. - Each retroactive entry's body includes a disclaimer block at the top stating values are post-hoc estimates and may be revised when G-038's calibration methodology lands.
- Credit values for platform-infrastructure projects use the conservative band: 4–8 for small subsystems and decision-capture sessions, 8–12 for mid-size feature ships, 14–22 for cross-cutting subsystems, 24+ for foundational shell-and-auth work.
- Credit values for conceptual / multi-year projects use a separate band that reflects elapsed wall-clock time and load-bearing dependency depth: 12 for discrete conceptual blocks, 20–30 for large architectural decisions that the entire platform depends on, 30+ for the years-long synthesis work that produced the corpus of decisions.
- All retroactive values are subject to revision (or rejection) once G-038 lands the calibration mechanism. They do not lock in a methodology — they're a placeholder ledger so the principle is at least directionally honored from day one of the surface existing.
Brandon escrow
A second piece of this commit: contributor credit allocation for
co-founder Brandon. Brandon's contributions across the multi-year
work are real and substantial, but Brandon hasn't yet logged into
the platform — meaning there's no user_id to attach his credits
to. The naive options are bad:
- Skip his credits until login. Erases his work from the ledger on a technicality. Same failure mode the whole roadmap-capture exercise is correcting.
- Attach them to the founder account. Inverts the contributor sovereignty principle (Entry 005) by aggregating Brandon's work under someone else's identity.
The path taken: a structured contributor_credits field per
project that names the contributor and their amount with a
status: "pending_login" flag. Aggregate "pending contributor
credits" surface on the index. When Brandon logs in for the first
time, an admin (or an automated reconciliation step) attaches the
escrow records to his user_id. Until then, the ledger publicly
says "Brandon, pending login, X credits" and the work is visible.
This pattern generalizes — it's the right shape for any future contributor work that's been done off-platform and needs to be attributed when they arrive.
What this entry does not do
- It does not retroactively credit governance-content writing (writing journal entries, register entries, etc.) as separate projects. Decision capture is captured in P-013 only as the one discrete pre-roadmap engagement-capture session that explicitly shipped four governance entries. Whether ongoing governance authoring earns credits at all is a G-038 question.
- It does not fold P-001 or P-002 into the retroactive set. Those shipped with the roadmap surface and were captured cleanly.
What we're asking for
Forgiveness for the imprecision. The values are best-effort
post-hoc estimates, not measured time-logs. If the calibration
mechanism G-038 produces says the values are wrong, they get
revised in the open with the prior values preserved in the change
log. The visible captured_retroactively flag is the contract: no
retroactive credit can quietly disappear into the methodology.