# Living Source Update Protocol

**Protocol version:** `1.2.0`
**Applies to Living Source:** `YLS-2026.09.05.3`

## Purpose

A new wisdom must not become another disconnected paragraph. It must enter as a source-linked change whose consequences propagate through every affected claim, explanation, book, lesson, diagram, test, code requirement, application, and public page.

The update cycle is:

```text
new source or author correction
→ immutable capture
→ reconstruction
→ claim classification
→ relational reconciliation
→ unresolved-conflict classification
→ impact graph
→ full patch
→ challenge
→ validation
→ human approval
→ canonical merge
→ rebuild
→ release record
→ future-agent handoff
```

## Frozen corpus and append-only live intake

The release source corpus and the live author-intake ledger are deliberately separate populations.

- `atlas/SOURCE_INVENTORY.csv` and `atlas/SOURCE_INVENTORY.json` are frozen at **1,610 content-addressed records** for this release: 1,559 baseline repository records, 11 reconciled v9-only records, and 40 materialized session-source records.
- `intake/WISDOM_INBOX.jsonl` is the separately governed live-intake ledger. New direct author material is appended there with a unique capture ID, timestamp, type, portable raw-source address, affected surfaces, and proof boundary.
- Existing intake lines and raw captures are never rewritten, reordered, or deleted to express a correction. A later correction is a new record and must declare its lineage or supersession relation.
- A live intake is preserved and indexed immediately, but it is **not** silently inserted into the frozen 1,610-record inventory, substituted into historical audit denominators, or promoted into canonical wisdom.
- Changing the frozen corpus requires an explicit new inventory version, deterministic path/byte/SHA-256 reconciliation, population-delta report, human approval, rebuilt downstream artifacts, and a new release manifest.

This separation lets wisdom continue arriving without making a historical corpus count drift underneath an audit or release.

## Governed external reconciliation and proof-audit inputs

The five user-declared external roots are configured in `governance/EXTERNAL_SOURCE_ROOTS.json`. Their deterministic, read-only exact-byte inventory is validated against `schemas/Y_THEORY_EXTERNAL_SOURCE_RECONCILIATION.schema.json` and published as the JSON/Markdown `reports/source-reconciliation/EXTERNAL_SOURCE_RECONCILIATION` pair. This inventory records exact SHA-256 duplicates, source-family retrieval candidates, exclusions, and overlap with the frozen Living Source inventory. It does not ingest, rewrite, approve, canonize, or infer semantic equivalence.

For the Structure of Mind, use `reports/source-reconciliation/EXACT_SEVEN_ALL_SOURCE_AUDIT.md` and the schema-bound JSON/Markdown `STRUCTURE_OF_MIND_PROOF_MODE_AUDIT` pair. They preserve the premise-qualified internal derivation: equal-start adjacent inheritance supplies the one-third/two-thirds envelope and golden limit; the directed ten-part address scale places both expansion-facing quantities in `B7`; the explicit bridge `D := a(1/φ) = a(2/3)` gives seven; and recursive self-similarity carries `L7` into a changed `L1`. The exact `3 + 9 = 12` cell is available within each recursive depth, so twelve and seven type different structural axes rather than rival counts. External referents are evaluated proposition by proposition. Historical pre-repair snapshots under `reports/source-reconciliation/snapshots/` must remain immutable.

For toroidal visualization and dynamics, use the schema-bound `reports/source-reconciliation/TOROIDAL_MIND_SIMULATOR_AUDIT` pair before using the candidate application under `applications/candidate-toroidal-mind-simulator-v1/`. Keep four proof modes separate: a reversible coordinate theorem under declared premises, a selected dynamical model, implementation-conformance results, and unapproved Y-Theory method or ontology proposals. A two-phase `T²` address is not the complete delayed state; the seven-depth simulator setting consumes the current complete-Mind architecture rather than selecting or independently proving its depth, while other `N` settings are implementation diagnostics only; a calculated reference-frame projection is not observerhood. Simulator outputs may strengthen or falsify only the proposition and runtime contract actually tested.

## Stage 1 — Capture the source without rewriting it

Create a proposal from `NEW_WISDOM_PROPOSAL_TEMPLATE.yaml`.

Required fields:

- proposal ID;
- date;
- contributor;
- source file or conversation reference;
- exact original wording or faithful source span;
- context and triggering question;
- proposed statement;
- why it matters;
- current status;
- requested status;
- assumptions;
- strongest guardrail.

Never discard the raw wording merely because the polished statement is clearer.

## Stage 2 — Reconstruct the structure

The proposing agent must state:

- scale and point of reference;
- inside;
- outside;
- relation;
- boundary;
- direction;
- delay/residue;
- return;
- what would count as failure.

This reconstruction is separate from agreeing with the claim.

## Stage 3 — Type the claim

Choose one:

- definition;
- canonical structural law;
- structural derivation;
- conditional mathematical derivation;
- Y-Theory postulate;
- model bridge;
- empirical claim;
- prototype observation;
- theological/interpretive lens;
- application architecture;
- rejected/superseded;
- open question.

A claim may have a primary status and secondary tags, but one statement should not hide several incompatible proof levels.

The exact count of seven is typed as a premise-qualified internal derivation of the complete-Mind recursive depth. It must not be converted into a simulator choice among rival values of `N`. The derivation requires the whole declared chain—address orientation, equal-start adjacent inheritance, recoverable consequential relation, `D := a(1/φ) = a(2/3) = 7`, and recursive self-similarity—not an isolated recurring numeral or visual resemblance. The exact `3 + 9 = 12` structure is the recursive cell available within each depth, not an alternative depth count. Claims that instantiate the architecture in a physical, biological, cognitive, theological, or computational referent retain their own evidence and falsification obligations.

## Stage 4 — Reconcile, then find conflicts and lineage

Search:

- `atlas/CANONICAL_CLAIM_REGISTRY.json`;
- `atlas/WISDOM_REGISTRY_ENRICHED.csv`;
- `atlas/SOURCE_INVENTORY.csv`;
- all relevant canonical pages;
- conflict and correction records;
- implementation and experiment results;
- `corrections/AUTHOR_CORRECTION_2026-09-01_RELATIONAL_COHERENCE_AUTHORITY.md`;
- `reports/source-reconciliation/EXTERNAL_SOURCE_RECONCILIATION.json`;
- `reports/source-reconciliation/EXACT_SEVEN_ALL_SOURCE_AUDIT.md`;
- `reports/source-reconciliation/STRUCTURE_OF_MIND_PROOF_MODE_AUDIT.json`;
- `reports/source-reconciliation/TOROIDAL_MIND_SIMULATOR_AUDIT.json`;
- external primary sources when the claim is domain factual.

Before recording a contradiction, normalize both propositions to the same identity or referent and compare their scale, dimension, reference frame, clock, boundary conditions, domain, proof mode, and claimed consequence. Test whether the difference is wording, agent interpretation, refinement, scope, cross-scale translation, or a narrower lawful reading. File date and duplicate copies are neither truth authority nor independent support.

An explicit author correction is high-authority source evidence only for the proposition, referent, and scope it actually addresses. It supersedes a prior formulation when that relation is explicit or the two remain incompatible after reconciliation; it is not a global newest-file override for coherent wisdom outside its declared scope. Capture date, filename, and words such as *latest*, *current*, *final*, *canonical*, *repaired*, *proof*, or *validated* are metadata or claims to review, not authority by themselves.

After exact aliases and source-dependent restatements are identified, nonduplicate coherent relations strengthen structural persistence while retaining their dependency direction and proof mode. Exact copies and paraphrastic duplicates may improve recoverability, but they do not count as independent support and must not inflate confidence.

Record:

- supports;
- contradicts;
- narrows;
- supersedes;
- is superseded by;
- depends on;
- creates a new branch;
- remains unresolved.

Use `contradicts` only when two propositions remain mutually incompatible about the same normalized subject under the same declared conditions and proof mode. Otherwise use the more precise relation. Do not use file date or rhetorical polish as authority.

Report proof on five separate axes: internal Y-Theory derivation, nonduplicate cross-source reinforcement, structural correspondence or model bridge, external empirical support, and named-runtime predictive result. Give each axis its own state, exact evidence, assumptions, and unpaid obligation. A missing, untested, or negative state on one axis must not silently erase an earned result on another, and an earned result on one axis must not be promoted into another.

## Stage 5 — Generate an impact report

Run:

```bash
python tools/impact_report.py proposals/<proposal>.yaml
```

The report proposes affected claims and pages by explicit links and lexical overlap. It is an aid, not final semantic judgment.

The agent must then inspect every proposed impact and add missing descendants.

Minimum impact surfaces:

- canonical claim registry;
- full narrative chapter;
- glossary;
- wisdom registry;
- source inventory;
- book chapters;
- Teacher lesson and question flow;
- diagrams;
- research tests;
- runtime or application specification;
- open questions;
- changelog and release manifest.

## Stage 6 — Draft a complete patch

Create a change workspace:

```text
changes/<proposal-id>/
  proposal.yaml
  impact_report.md
  source_capture/
  patches/
  tests/
  approval.yaml
  session_return.md
```

A core correction should update existing prose where the old formulation occurs. Do not merely append “new wisdom” to the end of a document while leaving contradictory explanations unchanged.

Preserve old wording through version control and explicit supersession records.

## Stage 7 — Challenge the proposed change

The patch must include:

- strongest rival interpretation;
- counterexample;
- proof obligation;
- what observation would refute or narrow it;
- whether it changes only Y-Theory canon or also asserts an external fact;
- whether the change introduces a theological, moral, privacy, safety, or authority risk.

A beautiful or spiritually resonant explanation still requires this step.

## Stage 8 — Validate

Run:

```bash
python tools/validate_living_source.py
python tools/build_site.py
```

Validation checks:

- unique wisdom and claim IDs;
- required fields;
- valid claim dependencies;
- every wisdom mapped to a page and claims;
- every declared page exists;
- every claim names status, sources, guardrail, and affected pages;
- no canonical claim points to a missing dependency;
- site pages, data files, and links exist;
- release records and changelog are present.

The validator cannot decide philosophical truth. It verifies continuity and structural completeness.

## Stage 9 — Human approval

Use `CANONICAL_APPROVAL_TEMPLATE.yaml`.

Canonical approval must identify:

- proposal ID;
- approver;
- decision;
- approved wording;
- approved status;
- affected claims and pages;
- unresolved residue;
- effective version.

It must also bind the exact semantic-review registry hash, resolution-registry hash, affected source hash, and explicit decision or obligation IDs. Exact historical registry bytes are retained in `atlas/SOURCE_SEMANTIC_APPROVAL_SNAPSHOT_REGISTRY.json`, allowing old append-only events to remain verifiable after the current registries change. Partial approval applies only to the listed IDs. Objective task audits and research routing cannot be approved as theory-status upgrades. Approval events are append-only and hash chained in `atlas/SOURCE_SEMANTIC_APPROVAL_LEDGER.jsonl`.

An agent may prepare the approval file but cannot set the human's signature confirmation. That confirmation is an explicit repository-governance assertion; it does not by itself provide cryptographic signing, key verification, or authenticated-account proof.

## Stage 10 — Merge and regenerate

After approval:

1. apply the accepted statement to the wisdom and claim registries;
2. update every affected canonical chapter;
3. update glossary and open questions;
4. update book-specific source files;
5. update tests and application requirements;
6. rebuild the static site;
7. run validation;
8. update `CHANGELOG.md`;
9. create a new `RELEASE_MANIFEST.json`;
10. preserve a rollback tag or archive;
11. write the session return.

## Stage 11 — Public correction

The public Teacher should display:

- current Living Source version;
- claim status;
- source lineage;
- date of last correction;
- what changed;
- previous wording where material;
- route for challenge.

A public explanation may be simplified, but it must not strengthen the source claim.

## Automatic update versus automatic authority

The desired system is automatic in **propagation**, not automatic in **authority**.

After an approved wisdom is merged, the source graph and build system should automatically regenerate all declared dependent outputs.

Before approval, agents automatically produce impact analysis, drafts, validation, and previews—but not canonical truth.

This preserves both continuity and correction.