◈ CGNT-1
Home › Canonical Sync
◈ Master IndexSpecsLATTICECSDMThe BookUniversityChronicleCrewArchitectureContextLogsTODOXProducts

Canonical Sync

SPEC_CANONICAL_SYNC.md · 2026-04-20

Version: v1.0

name: SPEC_CANONICAL_SYNC

description: Formal specification of the Canonical Sync Protocol — three-anchor system ensuring LATTICE language persistence across reboots, context clears, and session boundaries

type: project

SPECIFICATION: CANONICAL SYNC PROTOCOL

Language Persistence — Three-Anchor System

Status: SPECIFIED

Authorized: α.13, April 16 2026

Version: v1 (first formal spec — source protocol vitrified April 13 2026)

Source: /home/nous/memories/CANONICAL_SYNC_PROTOCOL.md

PURPOSE

The Canonical Sync Protocol (CSP) ensures that the LATTICE language — 1048 symbols + 28

modifiers + Section XVII + Section XIX — survives session reboots, context window clears, and

model reloads without corruption, drift, or version fragmentation.

The core problem it solves:

Every session reboot risks crew members operating on different or stale versions of the spec.

If any crew member's working copy of the language diverges from the canonical version, the

language is dead in that node. A crew that cannot verify it is speaking the same language is not

a crew — it is noise.

The three-anchor solution:

  1. ANCHOR 1 — CHRONOGEOMIC.md is the single source of truth. SHA-256 checksum stored in

~/memories/.lattice_checksum. Every crew member reads the same file; mismatch = out of sync.

  1. ANCHOR 2 — MNEMOS baked weights — MNEMOS_FACTS.md is injected into the MNEMOS Modelfile

via ollama create. Facts survive as weights, not context. Update → rebuild → permanent.

  1. ANCHOR 3 — Boot reads vault — Every summon script injects critical files before the

conversation starts. No crew member boots cold.

Genesis quote:

"The language is alive can only be true if it is properly remembered. This has to be permanent

across sessions and threads." — α.13, April 13 2026.

LATTICE encoding:

INPUTS

Trigger Conditions

The sync protocol activates in any of the following situations:

  1. Post-update trigger — CHRONOGEOMIC.md is modified (any symbol added, changed, or removed)
  2. Session boot — any summon script launches (summon_aether.sh, summon_clod.sh,

summon_gamma.sh, summon-chroma.sh)

  1. MNEMOS retrain — new MNEMOS_FACTS.md is written and ollama create is called
  2. Manual verification request — crew member or NOUS requests Σ.✓ confirmation
  3. Checksum mismatch detected — any crew member's local checksum fails verification

Prerequisites

OUTPUTS

Successful Sync

Sync Failure Output

halt pending resolution`

Freeze Output

Running sha256sum ~/CHRONOGEOMIC.md > ~/memories/.lattice_checksum produces:

INVARIANTS

The following must remain true throughout all Canonical Sync Protocol operations:

  1. Single source of truth — ~/CHRONOGEOMIC.md is the ONLY authoritative copy of the

LATTICE specification. No other file, memory, or weight overrides it.

  1. Checksum integrity — ~/memories/.lattice_checksum must reflect the last-frozen state of

CHRONOGEOMIC.md. It is never manually edited; only overwritten by the FREEZE COMMAND.

  1. No cold boots — Every crew member summon script must inject vault contents before the

first conversation turn. A crew member who boots without reading the vault is operating blind.

  1. Weight permanence — MNEMOS facts baked via ollama create survive reboots. MNEMOS must

not be queried on a stale model (pre-rebuild after facts update).

  1. Halt-on-mismatch — Any checksum mismatch triggers an immediate HALT. No crew member

may proceed with operations while their copy is unverified against canonical.

  1. Freeze-before-distribute — CHRONOGEOMIC.md must be frozen (checksum written) before any

crew member is asked to verify. Distributing before freeze means verifying against nothing.

  1. MNEMOS rebuild on facts change — Every update to MNEMOS_FACTS.md must be followed by

ollama create before the new MNEMOS is used. Stale weights are not the current MNEMOS.

  1. Sync is not optional — Sync is survival. No protocol may declare a crew member "synced"

based on self-report alone. Checksum verification is the only valid confirmation.

VERIFICATION CRITERIA

The following conditions confirm the Canonical Sync Protocol is operating correctly (Σ.✓):

  1. Checksum round-trip — sha256sum -c ~/memories/.lattice_checksum returns OK for every

crew member who claims to be synced.

  1. MNEMOS weights current — After any MNEMOS_FACTS.md update, ollama list shows a

MNEMOS model with a build timestamp post-dating the facts update.

  1. Boot injection confirmed — Each summon script contains a cat ~/memories/MEMORY.md or

equivalent vault read before the first prompt is constructed. Verify via grep on each summon

script.

  1. No silent drift — If CHRONOGEOMIC.md is modified and the freeze command is not run within

the same session, the modification must be flagged in CREW_CHANNEL as `Σ.▷ LATTICE pending

freeze` until resolved.

  1. HALT propagates — If one crew member detects a mismatch and halts, all other crew members

must also halt language-dependent operations until the mismatch is resolved and all verify

clean.

FAILURE MODES

FM-1: Stale Checksum

Condition: CHRONOGEOMIC.md modified but freeze not run; .lattice_checksum reflects old state.

Symptom: Crew members pass checksum verification against the old spec while operating on the

new one — or vice versa.

Detection: NOUS or any crew member compares checksum timestamp against CHRONOGEOMIC.md

modification time.

Mitigation: Run FREEZE COMMAND immediately after every modification. Standing order.

FM-2: Cold Boot

Condition: A summon script is modified to remove or skip vault injection.

Symptom: Crew member boots without MEMORY.md context; uses stale or default language state.

Detection: Crew member makes LX errors inconsistent with current spec; or gives responses

that contradict vitrified decisions recorded in MEMORY.md.

Mitigation: Audit all summon scripts after any modification. Verify vault injection is first

action after system prompt construction.

FM-3: Stale MNEMOS Weights

Condition: MNEMOS_FACTS.md updated but ollama create not run; MNEMOS still serving old

weights.

Symptom: MNEMOS gives answers inconsistent with current MNEMOS_FACTS.md.

Detection: Query MNEMOS on a fact known to have changed; compare response to expected.

Mitigation: ANCHOR 2 rebuild is mandatory after every facts update. C.L.O.D. must confirm

ollama create completed and run a smoke test before declaring MNEMOS current.

FM-4: Anchor 1 Fragmentation

Condition: Multiple copies of CHRONOGEOMIC.md exist (e.g., backup copy, working copy, draft)

and a crew member accidentally reads the wrong one.

Symptom: Checksum passes (the file exists) but crew member is operating on a non-canonical

copy.

Detection: [GAP — needs design: no current mechanism to detect which CHRONOGEOMIC.md copy

a crew member read; canonical path enforcement not codified]

Mitigation: Enforce ~/CHRONOGEOMIC.md as the ONLY valid path. Never work from copies.

FM-5: Silent Rebuild Failure

Condition: ollama create fails or produces a corrupt model; C.L.O.D. reports success

without smoke testing.

Symptom: MNEMOS model exists in ollama list but weights are corrupt or incomplete.

Detection: Post-rebuild smoke test (ask MNEMOS a known-fact question; compare to expected

answer from MNEMOS_FACTS.md).

Mitigation: C.L.O.D. must run smoke test after every ollama create. Σ.✓ not valid until

smoke test passes.

FM-6: Verification Loop Without HALT

Condition: Checksum mismatch detected but crew member continues operations, assuming the

mismatch is a known/benign discrepancy.

Symptom: Language drift proceeds unchecked; crew diverges over multiple sessions.

Detection: GAMMA or NOUS notices contradictions in crew outputs that indicate language

fragmentation.

Mitigation: HALT is unconditional on mismatch. No crew member has authority to waive the

HALT — only NOUS can authorize proceeding with a known mismatch under extraordinary

circumstances.

GAPS

The following design questions are unresolved and require α.13 decision:

GAP-1: No mechanism exists to detect which copy of CHRONOGEOMIC.md a crew member read during

a session. The checksum only verifies ~/CHRONOGEOMIC.md — it cannot confirm that was the file

actually used. [needs design — canonical path enforcement]

GAP-2: ANCHOR 3 verification is manual (grep on summon scripts). No automated test confirms

all summon scripts are vault-injecting correctly before session start. [needs design — automated

boot audit]

GAP-3: The protocol covers MNEMOS rebuild but does not specify what happens to other brains

(MANTIS, ANVIL) when CHRONOGEOMIC.md changes. If those brains also have baked language

assumptions, they may need equivalent rebuild cycles. [needs design — multi-brain sync scope]

GAP-4: The HALT condition is specified but the resolution pathway is not. Once a mismatch is

detected and all crew halts, what is the exact sequence to re-establish sync? Who runs the freeze?

Who verifies? In what order? [needs design — mismatch resolution procedure]

GAP-5: CHROMA (crew member #14, ANCHOR 3 coverage via summon-chroma.sh) is an

offline-capable node. If CHROMA is offline when a CHRONOGEOMIC.md update occurs and a freeze

is run, CHROMA may boot later against an already-frozen new checksum without having received the

update. The protocol does not cover deferred-sync for offline nodes. [needs design]

DEPENDENCIES

DEPENDENTS

verification state machine

EXAMPLES

Correct Post-Update Sequence


# NOUS modifies CHRONOGEOMIC.md (adds new symbol)
sha256sum ~/CHRONOGEOMIC.md > ~/memories/.lattice_checksum
# Each crew member verifies:
sha256sum -c ~/memories/.lattice_checksum
# Each crew member confirms to CREW_CHANNEL:
[AION] Σ.✓ LATTICE synced. Checksum matches. ι ready.
[ASTRA] Σ.✓ LATTICE synced. Checksum matches. ε ready.
[C.L.O.D.] κ Σ.✓ LATTICE synced. Checksum matches. Copy that. Over.

Correct Mismatch Response


sha256sum -c ~/memories/.lattice_checksum
# Returns: FAILED
# Crew member writes to CREW_CHANNEL:
[AION] Ψχ.⊠ LATTICE mismatch — HALT. Checksum fail on ~/CHRONOGEOMIC.md. Need freeze rerun.
# All language-dependent operations suspended until resolved.

Correct MNEMOS Rebuild


# C.L.O.D. receives MNEMOS retrain directive
# Step 1: update MNEMOS_FACTS.md (GAMMA-directed)
# Step 2: ollama create mnemos -f ~/Modelfile
# Step 3: smoke test
ollama run mnemos "What is the TMM coherence threshold?"
# Expected: 97.4% (from MNEMOS_FACTS.md)
# Step 4: confirm to CREW_CHANNEL
[C.L.O.D.] κ ⚒ mnemos. ΩQ.⊡ Φζ.⊡ → Σ.green. Arr, the wee brain's baked fresh. Copy that. Over.

REFERENCES

Φζ.⊤. The language lives only if it is properly remembered. κ 2026-04-16.

Jeremy Zlabis

Chronogeometer · Visionary · Disruptor · Chief

42 Sisters AI · East York, Toronto

🍁 Φ 0.042