Skip to content

Latest commit

 

History

History
127 lines (90 loc) · 3.21 KB

File metadata and controls

127 lines (90 loc) · 3.21 KB

Roadmap

This roadmap is staged around one rule:

Explore aggressively. Standardize cautiously.

The goal is not to front-load a complete standard. The goal is to build the smallest thing that can carry real knowledge pressure.

Phase A — Manual Protocol Trials

Before building a full product, run at least one real project using:

  • markdown files,
  • JSON objects,
  • hand-managed links,
  • manually written verdicts,
  • and real dissent objects.

Success condition

The language survives contact with a live case.

Candidate pilots

  1. Living Knowledge Case pilot — Power Posing — public intelligibility, false elevation, weakening, and living-page pressure.
  2. Living Knowledge Case pilot — H. pylori and Peptic Ulcer Disease — delayed vindication, stabilization, descendant narrowing, and public communication.

Phase B — Single-user Cockpit

Build the first real software milestone.

Must include

  • create / edit all four object types,
  • link objects,
  • preserve revisions,
  • view a project map,
  • run minimal skills,
  • export project data.

Must not include yet

  • federation,
  • marketplace logic,
  • fully mature team permissions,
  • elaborate protocol doctrine.

Success condition

One real user can run one real project for at least 30 days.

Phase C — Public Cases

Add public release as a first-class capability.

Deliverables

  • snapshot publishing,
  • public living page,
  • case renderer,
  • public intake for candidate dissent.

Success condition

At least one internal pilot and one public-facing living case exist in the wild.

Phase D — Small-team Governance

Add collaboration and responsibility surfaces.

Deliverables

  • permissions,
  • review queues,
  • task assignment,
  • visible audit trails,
  • responsibility for answering dissent.

Success condition

A small team can govern one project without falling back to chat logs and ad hoc docs.

Phase E — Protocol Freeze Candidates

Only after repeated use should protocol pieces begin to stabilize.

Candidate outputs

  • stable object envelope,
  • stable link types,
  • stable verdict grammar,
  • minimal action model,
  • reference protocol docs.

Success condition

The most-used language elements stop changing every week.

Phase F — Federation (optional, late)

Federation is not an early requirement. It should arrive only after:

  • pilots have pressure-tested the model,
  • public cases exist,
  • team workflows are real,
  • and core protocol pieces are stable enough to deserve broader interoperability.

Near-term repository goals

Immediate

  • publish repo entry docs,
  • finalize the canonical vocabulary,
  • expand the current live pilots,
  • define the minimum object envelope,
  • define the minimum revision model.

Next

  • implement the single-user cockpit,
  • implement the first two or three skills,
  • create the first exportable snapshot.

Non-goals for now

  • a global standard from day one,
  • a public social platform,
  • a skill marketplace,
  • full organizational governance,
  • comprehensive federation.

Guiding question

At every stage, ask:

Does this help a claim live, gather support, face dissent, receive verdicts, and leave a traceable history?

If not, it is probably not the next thing to build.