---
id: PX-RESEARCH-103C1075
type: research
title: System Governance Evolution
---

## Scope

This records governance decisions that evolved from historical Super and early The System material into verified current behavior.
Historical claims describe design or shipped-era intent only.
Verified current claims derive from `extensions/the-system/README.md`, `system-prompts.ts`, `documents.ts`, `system-config.ts`, and `CHANGELOG.md`.

## Historical evolution

The System began as an intentional hard replacement of Super, rejecting aliases and duplicate public surfaces so live ownership stayed singular.
Early governance separated human project law from agent-authored working memory and treated invalid document state as a diagnostic or blocked mutation rather than silent repair.
The initial document model used flat, validated HTML files with a shared project stylesheet.
The rich-Markdown amendment replaced that model with typed `<ID>-<slug>/index.md` bundles, making assets move with their owning document while preserving browser-oriented presentation through an extension-owned renderer.
That amendment also replaced spec-decomposition roadmaps with project-wide phases, separating operating posture from delivery work.
The initial plan and phase status model later narrowed so current phases carry identity and a footer label while operational completion state belongs outside canonical bundle prose.
The recurring architecture was a pure document and graph kernel beneath thin runtime, doctor, initialization, rendering, and command boundaries.

## Verified current behavior

The current extension exposes one `/system` command with explicit lifecycle and read-only viewing surfaces.
Canonical bundles are typed directories with YAML-frontmatter `index.md` documents and random eight-character ID tokens.
Research has only `id`, `type`, and `title` as required frontmatter, and it links to no lifecycle stage.
Configuration schema version is `0`.
Project operational state is stored separately in `.system/board.json`, so bundle text does not claim implementation progress.
Current phases are project-wide operating epochs selected through config rather than spec work breakdowns.
Single-document and full-book views render ephemeral output rather than generated project state.
Existing core documents plus existing phase and spec-bundle files receive one-shot human approval before mutation.
The bundle-allocation tool reserves an ID and semantic path during a lifecycle authoring run, avoiding count-based ID allocation races.

## Lasting lessons

One owner per fact prevents circular authority between goals, constraints, approved behavior, implementation intent, and operational status.
Canonical source should remain human-editable while rich presentation stays derived and disposable.
Typed bundle boundaries make document-owned assets explicit and keep source moves or deletions atomic.
Strict machine-written identity and reference fields coexist with flexible human-authored Markdown bodies.
Read-only diagnosis and candidate validation should share models with mutation gates, otherwise their findings drift.
Governance hooks are advisory safeguards around trusted repository content, not a sandbox or substitute for explicit human decisions.
A hard rename is safer than compatibility shims when aliases would preserve conflicting live authority.

## Historical sources

Original bytes remain recoverable from Git commit `88660125c313dd5eff4f8c4dee431caa8e0ddd22`.

- `docs/super/specs/2026-07-11-the-system-design.html`
- `docs/super/roadmaps/2026-07-11-the-system-roadmap.html`
- `docs/super/plans/2026-07-11-the-system-phase-1-hard-rename.html`
- `docs/super/plans/2026-07-11-the-system-phase-2-document-kernel.html`
- `docs/super/plans/2026-07-11-the-system-phase-3-doctor.html`
- `docs/super/plans/2026-07-13-the-system-phase-4-guided-init.html`
- `docs/super/plans/2026-07-13-the-system-phase-5-runtime-governance.html`
- `docs/super/specs/2026-07-15-the-system-rich-markdown-design.md`
- `docs/super/plans/2026-07-15-the-system-phase-6-rich-markdown-bundle-kernel.md`