Capability Development Roadmap

This page is a compass and set of landmarks, not a railroad. Side paths may be discovered. Backtracking is allowed when evidence requires it. Surprise work is welcome. None of that redefines phase completion unless exit criteria are deliberately revised.

Sovereign-Games-OG-Image.jpg

Charter

Purpose: Track the emergence of operational capability within the discipline.

Phases represent new abilities the system can demonstrate, not the completion of documents. Exit criteria are based on observable capability, not page count or activity volume.

Compass and landmarks: The path orients work. It does not forbid discovery. New trails may open; wrong turns may require backtrack. Landmarks (exit criteria) still define whether a phase is complete.

Project rules:

Surprise discoveries remain allowed; they do not redefine phase completion.
Phase completion is demonstrated by operational capability, not by page count.
Instrument maturity (Experimental → Reference Standard Candidate) measures a page or tool. This roadmap measures project capability. Do not mix the scoreboards.

Infancy and development rules

Have you ever seen an apple seed?

A seed is not a failed orchard. It is not graded by fruit count, canopy size, or whether it already feeds a village. It is graded by whether it is alive, oriented, and planted in conditions where growth is possible.

This roadmap and the project it describes remain in infancy. Process is still messy. Conventions are still forming. That is expected under development rules and Permanent Beta.

Infancy rule	Meaning
Do not demand Operational behavior from Foundations work	Early phases produce language, scaffold, and citable architecture — not a full pilot factory
Mess is not the same as drift	Unfinished structure under active correction differs from silent contradiction left unlabeled
Labels stay honest	Experimental and Self-Assessed are strengths when true; inflating grade is a nonconformance
Development rules still bind	Pre-cal before content theater; log nonconformances before cosmetic fixes; standing remains tier-qualified
The seed is allowed to look like a seed	Outsiders and collaborators evaluate phase-appropriate capability, not a fantasy of finished NIST-for-abstract-systems

These rules do not lower the bar for later phases. They prevent category error: judging Phase 0–2 by Phase 7 criteria.

What success means (destination landmark)

Operational success for the calibration core means:

Calibration procedures in routine use
Calibration reports produced as normal work
Calibration recommendations in conditional form (If objective is X, evidence suggests Y)
Real-world (or clear outcome-contact) application cals feeding system improvement

That cluster is approximately Phase 5–7, not “Phase 2 looking busy.”

Path so far (landmarks already passed or in progress)

Work already done is mostly Foundations → Scaffold → Core Architecture Stable, with Procedure v0 beginning (structural pre-cal checklists in force).

Landmark	Status (Self-Assessed)
Shared discipline framing (MoA; See → Refuse → Build; Permanent Beta)	In place and in active use
Standing / confirmation / self-check distinctions	Formalized; still deepening under use
Domain-appropriate standards; abstract standards are real; system was missing	Formalized as principle pages / lexicon entries
Working terminology as discipline glossary	Seeded (Experimental)
Wiki scaffold (categories, GameModule, Admin Page Status conventions)	Largely in place; still messy at edges
Structural pre-cal checklist as procedure fragment	In use — early Phase 3 signal
Report / recommendation templates as default operations	Not yet Operational
Tier-A or clear outcome-contact pilots closing the loop	Not yet satisfied as phase exit

Excellent conceptual pages can accumulate in Phases 0–2 without moving project capability into Pilots or Operational. That fact is intentional honesty, not disparagement of the pages.

Phases

Phase	Name	Capability Gained	Exit Criteria
0	Foundations	Shared language, scope, and boundaries	Working Terminology available; physical–abstract boundary and Abstract Standards Are Real; the System Was Missing citable; Discipline vs. Application explicitly defined.
1	Scaffold	Navigable, metadata-bearing corpus	Core pages carry agreed metadata patterns; static dates, categories, and page conventions reusable without reinventing each page.
2	Core Architecture Stable	Citable core without weekly rewrites	Metrology of the Abstract hub, Standing rules, and Domain-Appropriate Standards boundary stable enough that procedures can reference them.
3	Procedure v0	Same structural steps every time	Pre-Calibration Checklist in use; Content Calibration procedure written; nonconformances logged before correction as the normal operating rule.
4	Report v0	Outputs behave as instruments	Calibration Report and Calibration Note templates exist; standing is recorded on the report; at least three sample reports, including at least one evaluating a claim outside pure framework self-description.
5	Recommendation v0	Conditional guidance	Reports include the "If the objective is X, the evidence suggests Y" format; unbound prescriptions are not the default.
6	Pilot Loop	System improves through external contact	At least three logged calibrations that produce documented changes to a procedure, glossary, or standard through correction memory; at least one Tier A or other clear outcome-contact pilot, not only framework-on-framework evaluations.
7	Operational	Procedure → Report → Recommendation becomes normal work	The calibration workflow is the default operating path rather than a special event.
8	Continuous Improvement	Permanent Beta becomes normal operations	Version updates, new applications, calibration pilots, and correction cycles are routine; the discipline has no terminal "finished" state.

Spiral, not only ladder

The discipline may operate at Operational or Continuous Improvement while a new application begins again at Foundations and progresses through the Pilot Loop.

This is a normal engineering pattern: mature method, immature deployment.

How to use this compass

Declare one active phase.
Keep that phase’s exit criteria short enough to argue about.
Map new work to: advances a criterion · Future Layer · Development Breadcrumb · backtrack note.
Close a phase only when exit criteria pass — then move the pointer.
Revise landmarks deliberately when evidence requires; do not let excitement silently rewrite completion.

Boundary condition — roadmap gaming

This project and its collaborators are strong at Foundations and Scaffold artifacts. A failure mode is indefinite production of excellent Phase 0–2 pages while Pilot Loop and outcome contact never start.

If Phase 6 is “completed” only by more framework-on-framework calibration theater, record a Readiness Gap: documentation excellence is not operational capability.

Current pointer (Self-Assessed)

Active region: Phase 0–2 heavy; Phase 3 starting.

Next landmark emphasis: harden Procedure v0, then Report v0 with at least one outward-facing sample — without demanding orchard-scale fruit from an apple seed.

Status

Field	Value
Version	0.1
Maturity	Experimental
Calibration review	Self-Assessment
Validation	Low — architectural freeze of the path; not field-proven as a management instrument
Role	Compass and landmarks for capability development
Freeze note	v0.1 locks the phase shape and rules for citation; still Permanent Beta and infancy-bound

This page is in Permanent Beta. The freeze is a landmark freeze (stable enough to steer by), not a claim that the project has left infancy.

See the Game. Refuse the Game. Build Better.

Open Calibration Items

Confirm on-wiki links to Working Terminology and Abstract Standards principle pages when titles stabilize.
Define numeric N and ownership for Phase 6 logging in a short Pilot Log convention.
Revisit active-phase pointer after first three outward sample reports exist.

Structural Connections

Page Transparency & Calibration

Calibration Log & Decision Records (via Talk Page) — This page uses Talk-only calibration tracking. Full history of reviews, version changes, calibration decisions, and any governance reasoning behind structural decisions all live on the same Talk page, per Calibration Log: When to Create One and Decision Records: Governance Memory. Not every Calibration Log entry is a Decision Record — scan the Talk page's headings for entries specifically marked as decisions; the link itself being active only confirms this page has calibration history, not that a formal decision was ever recorded.
View Current Page History — Complete edit history.

This page is under continuous calibration in line with the Permanent Beta principle.

Public Discussion Welcome

Questions, suggestions, feedback, disagreement, and proposed improvements are welcome on the Talk page.

Light rules:

Prefer evidence and concrete examples over slogans.
Apply Diagnostic Inversion Test when criticizing — the same standard to this page that you would apply elsewhere.
Distinguish observation from conclusion.
Calibration entries and Decision Records are maintenance records; public discussion belongs in ordinary Talk threads.
This framework remains in Permanent Beta. Better calibration is always in scope.

Calibration Dependent

Pages that list this page as a load-bearing dependency:

Page	Priority	Instrument Grade	Last Updated	Cycle Status	Drift Status
Category:Exploration	Supporting	Experimental	2026-07-23	Current	Breadcrumb-Open
Research Hypothesis: Traceability Chains for AI Claim Calibration	Supporting	Experimental	2026-07-23	Current	Breadcrumb-Open
Research Hypothesis: Civilizational Effective Intelligence and Calibration Infrastructure	Supporting	Experimental	2026-07-23	Current	Breadcrumb-Open

If this page is edited substantively, review the list above per the Ripple Review rule — see Calibration Dependencies: Standards and Process#Rule: Core-Priority Changes Trigger Mandatory Ripple Review.

Calibration Dependencies

Pages this page relies on as load-bearing dependencies: Metrology of the Abstract • Permanent Beta • Metrology of the Abstract — Working Terminology • Abstract Standards Are Real • The System Was Missing If incorrect, edit the `depends_on` field in Admin Page Status — do not edit this section directly, it is auto-generated.

Calibration References

This page is calibrated against the following core standards and reference materials:

The Sovereign Games Framework — Overall framework philosophy and operating principles
Permanent Beta — Core maintenance and continuous improvement standard
Reference Standards — Principles for traceable, confirmed standards
Calibrating Conceptual Instruments — Methodology for evaluating and refining pages
Civilizational Traceability Hierarchy — How standards should connect to reality across levels
Diagnostic Inversion Test — Mandatory self-application standard
Reality Game — Foundational reality-alignment tool
Reality Override Game — Standing discipline against protecting an existing model rather than updating it
Observable Behavior Rule — Standing principle that diagnostics evaluate observable actions, mechanisms, and consequences, not internal motive, belief, or intent
One-Way Nature of the Sovereign Games — Anti-capture design principles
The Royal Cubit Civilization (Strategy) — Long-term civilizational vision and metrology metaphor
Conceptual Instruments — Overall direction and metrology metaphor
Breadcrumb Philosophy — Standing discipline for making unresolved questions and provisional decisions explicit
Calibration Dependencies: Standards and Process — Rule that visible and hidden dependency lists must match, and that dependencies describe genuine reliance

Page Construction & Maintenance References

How we construct, maintain, and utilize each page as a self-admin control panel.

Distributed Instrumentation — the architectural principle behind why this page (and every page) carries its own live instrumentation, rather than relying on a separate central dashboard.
Page Structure Calibration Checklist — the Step 0 structural pass every page should pass before content calibration begins; this page's own structure should be checkable against it.
Template:New Page Seed — the seed template this page's basic structure was built from.
Calibration Log: When to Create One — the decision procedure this page's own Talk-only vs. dedicated-log status was decided against.
Framework Features Reference — maintains consistency and traceability across the framework's structural features while avoiding unnecessary maintenance overhead; consult before introducing a new structural pattern this page might otherwise duplicate.

Calibration Procedure

In development. See Calibration Procedure for current status. No formal step-by-step procedure exists yet beyond the practices demonstrated across individual pages developed during the initial creation of this project.

Tracking & Log Pages

Admin:Maintenance Dashboard - This dashboard shows pages that require calibration or review.
Nonconformance Reporting Procedure — What counts as a nonconformance and where it routes.
Known Site Issues & Fixes — Technical/mechanism bugs.
Calibration Failure Log — Calibration-design failures.
Breadcrumb Tracking — Live index of open Development Breadcrumbs.
Decision Records: Governance Memory — Why governance/structural decisions exist, plus its Index.
Insights and Future Layers — Unexpected benefits and project-wide future ideas.
Feature Request Log — Genuinely desired features that were attempted and confirmed not currently possible with available tools. Index-only; full write-ups and discussion live on Talk.
Calibration Report Standard Format - Standardrized reporting formatting.

Page Reference

Title	Capability Development Roadmap
URL	https://www.thesovereigngames.com/wiki/Capability_Development_Roadmap
Description	Compass-and-landmarks path for operational capability in Metrology of the Abstract. Phases with exit criteria; infancy rules; surprise discoveries allowed without redefining phase completion.
Category	Meta & Framework