Session Export - ChatGPT Doctrine Design

assetactive

Session Export — ChatGPT Doctrine Design

Source file: Morphism/ChatGPT-Branch · Morphism Doctrine Design.md (~109KB, ~4,700 lines) Session date: 2026-03-25 Platform: ChatGPT export Link: chatgpt.com/c/69c4c525-f72c-83e8-8b53-6b0e39d01ecb

Session Overview

This session designs the Morphism Doctrine from scratch — the single canonical operating document that governs writing style, repository layout, commit grammar, enforcement workflows, and agent behavior. It begins with a prompt refinement exercise and produces the full Doctrine specification including style system, documentation topology, authority model, enforcement architecture, and a multi-file synthesis resolving competing documentation approaches.

Key Topics

1. Documentation Style System (A–E)

Five documentation styles are defined and then reduced to a practical set:

| Style | Name | Use For | Feel | |-------|------|---------|------| | A | Ops Manual | Runbooks, reference | Terse, command-driven, table-oriented | | B | Engineering Notebook | Onboarding, architecture rationale | Explain reasoning once, then practical | | C | Codex | Internal governance, kernel, invariants | ASCII, formal notation, compressed | | D | Control Plane | Default — most docs | Direct, visual, grounded; every claim backed by artifact | | E | Narrative Doctrine | README, pitch, public docs | Story + data → concrete demo |

Decision: Style D is the default house style. Style E for outward-facing. Style C restricted to internal governance. Style B allowed locally but not as a top-level doctrine style. Style A absorbed into D.

2. Morphism Doctrine v0.1 (Full Draft)

The session produces a complete Doctrine specification with eight core principles:

| ID | Principle | Core Claim | |----|-----------|------------| | D1 | One canonical operating document | docs/DOCTRINE.md is authoritative | | D2 | One truth per domain | No domain may have two competing main files | | D3 | Docs must point to artifacts | Claims backed by file paths, commands, schemas, tests | | D4 | Default to directness | Prose only for rationale/tradeoffs; tables for everything else | | D5 | Generated where possible | Manual for meaning/policy; generated for inventories/references | | D6 | Depth is a liability | Max 3–4 directory levels | | D7 | Governance is continuous | Enforcement in authoring, commits, PRs, deploys, agent behavior | | D8 | Style is a control surface | Style controls clarity, proof burden, and reliability |

3. Documentation Topology (Five-Lane Model)

All documentation collapses into exactly five lanes:

| Lane | Governs | |------|---------| | docs/about/ | What Morphism is — positioning, narrative, pitch | | docs/architecture/ | How Morphism works — system design, data flow, research | | docs/governance/ | What constrains Morphism — invariants, policies, ADRs | | docs/operations/ | How Morphism runs — runbooks, CI/CD, deployment | | docs/reference/ | Lookup material — commands, schemas, glossary |

Includes a migration mapping from the existing ~12 folder structure into the five-lane target.

4. Authority Model

Exactly four files hold first-class authority:

| File | Responsibility | |------|---------------| | README.md | Public entrypoint | | AGENTS.md | Contributor and agent behavior | | SSOT.md | Domain ownership and source-of-truth mapping | | docs/DOCTRINE.md | Documentation, structure, and enforcement |

All other files (GUIDELINES.md, CLAUDE.md, style guides) are explicitly demoted to reference, adapter, or deprecated status.

5. Multi-File Synthesis

The session analyzes and reconciles three competing documentation approaches:

  • File 0: A Docusaurus/Diataxis-oriented site architecture with heavy tooling (Vale, mkdocstrings, TypeDoc, preview deploys, freshness crons)
  • File 1: The repo audit and consolidation approach with five-lane collapse and authority reduction
  • File 2: The style vocabulary and Doctrine identity from the current session

Resolution: Use File 1 as the governing baseline, File 2's style system as the identity layer, and selectively adopt File 0's frontmatter, generated-vs-manual policy, and ADR filename discipline — but reject its docs/doctrine/ lane, seven-category structure, and immediate heavy platform rollout.

6. Enforcement Architecture

The session specifies enforcement ordering:

  1. Enforce canonical lanes (no new top-level lanes without Doctrine update)
  2. Enforce authority uniqueness (no domain with two canonical documents)
  3. Enforce frontmatter (style, status, authority metadata)
  4. Enforce generated markers (distinguish manual from generated content)
  5. Then add site tooling (Vale, Docusaurus, etc.)

Key rule: docs/governance/ = human-readable governance docs, while governance/ or scripts/ = machine-executable governance code.

Key Decisions Made

  1. Morphism Doctrine is the single canonical operating document — not a themed content area
  2. Style D (Control Plane) is the default; Style E for public-facing; Styles B and C restricted
  3. Five-lane documentation topology replaces the existing ~12 folder structure
  4. Four authority files only — all others demoted
  5. Enforcement before tooling: stabilize canonical structure before adding docs infrastructure
  6. Diataxis is useful for site IA but does not replace the doctrine model for governance

Outputs Produced

  • Morphism Doctrine v0.1 (complete specification)
  • Style system with four tiers (D default, E public, C restricted, B local)
  • Five-lane documentation topology with migration mapping
  • Authority model with explicit demotions
  • Multi-file synthesis resolving three competing approaches
  • Enforcement priority ordering