Open Lore Network
Gap Register
G-038Public

Roadmap surface design and credit calibration

Tier 2 — Structurally thin, not launch-blocking
Status
Open — read-only capture surface ships first; calibration and contribution gateway deferred
Owner
Creator + Brandon
Why now
Entry 016 commits to a public roadmap, viewer priority signal, an open-source contribution gateway, and founder time accruing credits at the same denomination. The shape of the roadmap surface, the credit-value methodology, and the claim/submission/acceptance flow are all open.
Depends on
Entry 016
Related
Entry 005, Entry 015, G-006, G-033, G-035, G-036, G-037

How the public roadmap is structured, how credit values are set per project, how outside contributors claim and submit work, and how founder time is logged against the same denomination as contributor work.

Why this matters

Entry 016 makes four commitments at once: a public roadmap, viewer priority signal, an open-source contribution gateway, and founder time credited at the same rate as contributor time. The principle is decided. The mechanics are not, and the mechanics are where this either holds together or quietly inverts into the default startup posture (founder equity opaque, contributor credits pegged to it after the fact).

Several of the sub-questions also cannot be answered independently of G-006 (platform economics), G-033 (Power dilution), and G-037 (pre-launch credit accrual rate). Locking them in here would force those decisions prematurely. So this entry captures the surface area the roadmap will ship into and the choices that remain open within it.

Sub-questions

Data model and surface

  • Project record shape. What does a P-NNN project carry? At minimum: ID, slug, title, status, summary, target milestone, credit value, related Journal/Register entries. What else — owner, dependencies on other projects, expected effort range, acceptance criteria, change log?
  • Status taxonomy. Proposed → Open → Claimed → In review → Accepted → Shipped → Rejected? A simpler set? How do statuses interact with credit accrual (only "accepted" credits, or partial credit at "in review"?).
  • Granularity. Is a P-NNN a single shippable change, a feature spanning multiple changes, or both at different scopes? If both, do child P-NNNs nest under parent P-NNNs?
  • Project corpus location. Files at src/content/roadmap/, parallel to journal/ and register/, with a loader and renderer that mirror the existing patterns. Confirmed in principle; the schema details are this entry's question.
  • Cross-reference token. P-NNN joins Entry NNN, B-NNN, and G-NNN in the cross-link primitive (remark-journal-refs).

Credit calibration

  • Unit and methodology. What is one credit? Is it tied to a target hourly equivalent, a t-shirt-size estimate, a market rate for the task type, or some hybrid? Whatever the methodology, it has to be legible enough that a contributor can predict the credit value before claiming.
  • Estimation process. Who proposes a credit value — the founder posting the project, a small panel, the contributor at claim time with founder approval? How are disputes handled?
  • Re-estimation rules. If a project turns out to be larger or smaller than estimated mid-flight, when (if ever) is the credit value revised, and who decides?
  • Founder time methodology. Founder time is logged against projects in the same units. Is the founder's logged time:
    • estimated up front and locked at the project's credit value (founder accepts the same risk a contributor would), or
    • actuals-based (founder logs hours and credits accrue accordingly, capped at the project's posted value)? The first preserves the same-denomination commitment most cleanly; the second is more accurate but reintroduces a founder-only escape hatch.
  • Calibration challenge mechanism. If a registered user thinks a posted credit value is wrong (too low, too high, or founder-favoring), what's the path to challenge it? Comments (G-035)? Reactions on the project itself? A separate dispute lane?

Contribution gateway

  • Claim semantics. First-come-first-served? Application-based? Time-boxed claims that expire if no progress? Multiple claimants on one project working in parallel?
  • Identity requirement. Is registration sufficient to claim, or does claiming require a stronger identity signal (e.g., a verified GitHub or domain-based email)?
  • Submission format. Pull request against the public repo? An uploaded artifact reviewed in-app? Linked external work?
  • Acceptance gates. Who reviews submissions? Founders only, during the founding phase? A rotating reviewer pool? Automated checks before human review?
  • Rejection and partial-credit handling. What happens when a submission is partially correct? Iterate until accepted? Award partial credit? Pass the project back to the queue?
  • Anti-gaming posture. What's the defense against trivial contributions designed to extract credits — automated PRs, low-value edits, ghost-contributors, sock-puppets? Acceptance review is the primary gate; the question is what supplementary signals (account age, prior contribution history, founder veto) layer on top.

Priority signal

  • Reuse of the reaction primitive. Reactions on projects share the Support / Concern shape (Entry 015 + G-036). The question is whether projects need additional primitives — e.g., a "claim" intent signal, or a third reaction kind specific to roadmap items.
  • Aggregation surfacing. Where and how are aggregate reactions displayed? On each project? On a roadmap landing index? Sorted by signal strength, recency, or status?
  • Weighting. G-036 leaves anonymous-vs-registered weighting open. The roadmap inherits whatever G-036 resolves; this entry just notes the dependency.

Sequencing

  • What ships in the read-only capture phase. This entry's first sub-decision: the surface ships as a read-only published roadmap with status, credit values, and reactions, but no claim / submission flow yet. That defers the contribution gateway questions while letting the priority signal start collecting.
  • What blocks the contribution gateway from shipping. Acceptance gates and identity requirements at minimum; ideally also a calibration-challenge path so contributors aren't claiming work whose value they can't dispute.

What we are deciding now (read-only phase)

Capturing here so the read-only ship is unambiguous:

  • Project corpus lives at src/content/roadmap/ as P-NNN markdown files with frontmatter mirroring the Journal / Register patterns.
  • Each project carries: id, slug, title, status, summary, target milestone, credit value, owner, related entries.
  • The roadmap is publicly visible at /roadmap (index) and /roadmap/[slug] (single project).
  • Reactions are mounted on each project page using the same primitive as Journal and Register entries (Entry 015 + G-036).
  • No claim, submission, or acceptance flow ships in this phase.
  • Founder time logging is captured as a structured field on the project (founder credits accrued so far) but the methodology choice above is not yet locked — the field is present so that whatever we decide, the surface is ready for it.

Everything else listed above remains open.

Related

  • Entry 005 — Contributor sovereignty (the frame: contributor work is real participation, not unpaid labor)
  • Entry 015 — Pre-launch engagement (the reaction primitive this reuses)
  • Entry 016 — The decision this entry depends on
  • G-006 — Platform economics (the broader Tier 2 question credit calibration folds into)
  • G-033 — Power dilution rates
  • G-035 — Comment / Q&A model (calibration challenges may live here)
  • G-036 — Reaction system parameters (priority signal inherits this)
  • G-037 — Pre-launch credit accrual (the parallel question for registration / engagement-based credits, distinct from project-based credits but feeding the same Power balance)

Your read on this

Anonymous reactions are accepted; signing in lets you change yours.