The Living Source and Agent Update System

The governing thumb rule

Check the project first. Put every wisdom into the project. Challenge from the project. Return every session to the project.

The Living Source is both reference field and write-back field. A substantive session fails its continuity gate when it produces reusable residue but leaves no capture ID and no returned record.

1. The problem this system solves

The project has repeatedly lost understanding because:

• one agent reads only a recent summary;
• a polished interpretation overrides an explicit author correction within the proposition and scope that correction actually addresses;
• a new wisdom is added as an isolated paragraph;
• the book, website, registry, code, and handoff diverge;
• historical experiments are mistaken for active architecture;
• a public page becomes more visible than the canonical source;
• the author must explain the same correction again.

The Living Source makes the correction process itself part of the project’s persistent identity.

2. One source, many generated bodies

The canonical relation is:

Living Source
→ books
→ public Teacher
→ lessons
→ diagrams
→ research protocols
→ code specifications
→ community applications

Returned questions, evidence, and corrections move in the opposite direction:

reader / critic / experiment / application
→ recorded residue
→ proposal
→ impact assessment
→ validation
→ human approval
→ canonical change
→ regenerated outputs

The deployed website is a body of the source. It is not the source itself.

The Journey Graph is a governed projection layer

The Teacher now adds one deterministic layer between governed records and public presentation:

canonical pages + claim registry + wisdom registry
→ typed Journey Graph
→ learner route / structural map / manifestation map / subject gateways
→ homepage, node reader, question locator, and later 3D or VR bodies

The graph does not replace the pages or registries and does not add proof. It locates their current meaning for a learner. Its separate projections prevent teaching order from masquerading as cosmological chronology and prevent one convenient subject taxonomy from becoming ontology.

Source ingestion follows the opposite discipline from dropping documents into a visual node. The source and its exact span are preserved; candidate wisdom is reconstructed and status-typed; human review decides whether it can enter the governed registries; only then is the same graph regenerated. A wisdom may map to several nodes while remaining one provenance-bearing record.

Expected branches may be visible as gaps, but a gap is not an approved explanation. Public contribution and automatic canonical promotion remain disabled in this release.

3. Every wisdom is an addressable record

Each wisdom requires:

• stable wisdom ID;
• title;
• full statement;
• originating source and exact span where possible;
• author or contributor;
• date;
• raw proof status;
• normalized public status;
• guardrail;
• related canonical claims;
• affected domains and pages;
• superseded or superseding relations;
• tests and evidence;
• unresolved questions.

This package preserves every row of the current 348-entry master registry and adds category, public page, and related claim addresses.

External theories enter through relational reuse

An external theory is not approached mainly as a verdict on Y-Theory. Its developed relation is harvested through the required sequence:

native domain and scale
→ roles and incidence
→ orientation and transformation
→ invariant or closure
→ geometry / projection / mechanism
→ Y-role translation
→ transfer boundary
→ source-linked reusable output

The relation is preserved while the carrier and role names may change. The output must be recoverable as a translation dictionary, diagram, equation mapping, chapter insertion, correspondence record, or implementation pattern. See governance/RELATIONAL_REUSE_PROTOCOL.md and canonical/15_RELATIONAL_REUSE.md.

4. Canonical claim graph

A wisdom is not automatically a new foundational claim.

The claim graph distinguishes:

• foundational definitions;
• structural dependencies;
• mathematical conditions;
• bridges;
• applications;
• evidence;
• open questions.

A new wisdom may:

1. strengthen an existing claim;
2. narrow a claim;
3. split one claim into several;
4. reveal a contradiction;
5. add a model bridge;
6. create a test;
7. change an application;
8. remain historical context without changing canon.

5. The new-wisdom lifecycle

Capture

Preserve the original wording, context, speaker, file, date, and relation to the current problem.

Reconstruct

Restate the proposed structure without relying only on terminology.

Classify

Assign claim status and domain.

Compare

Search the current claim registry, wisdom registry, relation and candidate-conflict ledgers, books, experiments, and applications. Normalize referent, scope, scale, dimension, reference frame, conditions, claimed consequence, and proof mode before classifying a difference as conflict. Treat wording, refinement, narrower scope, cross-scale translation, implementation frame, duplication, and dependency as candidate relations first; only incompatibility that survives this gate about the same proposition under the same conditions is conflict.

An explicit author correction governs the proposition and scope it actually addresses; its date does not make it a global newest-file override. Nonduplicate coherent relations strengthen structural persistence when provenance and dependency direction remain visible. Exact copies and dependent restatements do not count as independent support or proof.

Detect impact

List every affected:

• claim;
• definition;
• page;
• book chapter;
• diagram;
• test;
• code specification;
• application;
• glossary entry;
• open question;
• public statement.

Draft

Update all affected explanations as one coherent patch. Do not merely append a note.

Challenge

Identify strongest counterexample, rival interpretation, and proof boundary.

Validate

Run structural and file-level validators. No accepted wisdom may be absent from its declared pages.

Approve

Canonical mutation requires Bubu Suhas Mullaveedu or an explicitly authorized human editor. AI-proposed changes remain proposals.

Merge and rebuild

Update the canonical registry and prose, regenerate the site, run link and source checks, record the release, and preserve a rollback target.

Return

Record what changed, what did not, what remains unresolved, and the exact next task.

6. Required agent behaviour

Every future agent must:

1. read START_HERE.md;
2. read AGENT_BOOTSTRAP.md;
3. inspect the current release manifest and changelog;
4. read the relevant canonical claims and source spans;
5. identify explicit corrections applicable to the proposition and scope, reconcile source relations, and retain only unresolved incompatibilities as conflicts;
6. state the scale, poles, relation, boundary, residue, return, and requested action;
7. distinguish claim status;
8. create one recoverable output;
9. update every impacted source surface;
10. run validation;
11. leave a session return.

An agent has not demonstrated understanding merely by paraphrasing Y-Theory. It must reconstruct, transfer, challenge, act, and return.

7. Mutation boundaries

Agents may freely:

• search;
• compare;
• draft;
• generate impact reports;
• create proposals;
• run non-destructive validators;
• build preview sites;
• prepare corrections;
• record experiment results.

Agents may not silently:

• approve their own theory change;
• rewrite the canonical registry;
• publish externally;
• change public access;
• spend money;
• contact people;
• interpret private data;
• promote an experiment to proof;
• erase a contradiction;
• claim spiritual authority.

8. Impact propagation rule

When a wisdom changes a core claim, the update is incomplete until all declared descendants are checked.

Example:

governed proposition-scoped clarification of "seven"
→ seven-depth claim
→ Structure of Mind chapter 11
→ number and geometry page
→ mind page
→ diagrams
→ glossary
→ claim-status notes
→ Teacher lesson
→ test prompts
→ digital architecture references
→ changelog and release manifest

The validator checks declared coverage. Semantic quality still requires human and agent review.

9. Release rule

Each release records:

• Living Source version;
• canonical claim registry hash;
• wisdom registry hash;
• source inventory hash;
• generated page hashes;
• changed claims and wisdoms;
• approver;
• build and validation result;
• known limitations;
• rollback version.

Rendered books and public pages should display the Living Source version from which they were generated.

10. Long-term direction

The Living Source is designed to become:

• the complete documentation of the journey;
• the source for the repaired Structure of Mind;
• the source graph behind the Y-Theory Teacher;
• the typed Journey Graph that turns governed records into distinct learner, structure, manifestation, and subject projections;
• the evidence boundary for researchers;
• the operating memory for future agents;
• the source of application requirements;
• the public correction and changelog system.

Its purpose is not to freeze Y-Theory.

Its purpose is to let Y-Theory change without losing the identity of what was learned.