cc-inscription — Full Intelligence Synthesis

cc-inscription — Full Intelligence Synthesis

Gathered: 2026-05-11. Read-only research pass. Citations attached to every load-bearing claim.

---

1. One-paragraph plain-English summary

cc-inscription is a Rust crate at `[home]/Desktop/Comp-Core/core/semantic/cc-inscription/` that turns a stream of "embodied dynamics" (the `z`-trajectory of latent vectors coming out of the motion brain, called DELL) into discrete, typed, hash-witnessed statements written in N'Ko script. There are exactly ten claim types — Stabilize, Disperse, Transition, Return, Dwell, Oscillate, Recover, Novel, Place-Shift, Echo — each with a locked N'Ko sigil. A `ClaimDetector` watches the trajectory; when dynamics become constrained enough, it emits a typed Intermediate Representation (IR); a versioned `Lexicon` and `SurfaceRenderer` render that IR to a single canonical N'Ko line (`⟨sigil⟩ ⟨time⟩ : ⟨body⟩ ; ⟨slots⟩`); and a provenance layer (canonical CBOR + SHA-256 + `InscriptionId` + `ProvenanceWitness`) makes the whole thing replayable bit-for-bit. The public-facing site at `learnnko.com` calls the same 10 sigils "claims," documents the pipeline as `Motion Sensors → DELL → ClaimDetector → Claim IR → Lexicon → N'Ko Surface`, and frames the constitutional rules (replayability, determinism, non-retroactive lexicon) as a 10-document NIP series (N'Ko Improvement Proposals). The crate is fully built (10 claim types, lifecycle, lexicon, renderer, phrase mining, ontology, provenance, canonical serialization, PsiChain) but is wired into the live K11 LUMA pipeline only INDIRECTLY — `cc-brain` has its own self-contained 104D→10-claim detector (`claim_bridge.rs`) that mirrors the same sigil set, and `echelon-bar` (the K11 binary) does not link `cc-inscription` at all.

---

2. The 10 claim types (source-cited)

The locked sigil-to-claim assignment is the single most-replicated fact across all sources. Same table appears in:
- `README.md` lines 156–168 (`[home]/Desktop/Comp-Core/core/semantic/cc-inscription/README.md`)
- `src/lib.rs` lines 19–31 (top crate docstring)
- `docs/01-GLOSSARY.md` "The 10 Claim Types" table
- `docs/02-INVARIANTS_LEDGER.md` "INV-INS-001 Sigil Immutability"
- `docs/DESIGN.md` "The 10 Claim Types"
- `lexicons/v1.0.json` `operator_sigils` keys
- `learnnko.com/claims` (verified via WebFetch)
- `LearnNKo/web/src/lib/inscription/types.ts` `CLAIM_SIGILS`
- `cc-brain/src/san/claim_bridge.rs` lines 31–43 "Claim Sigil Map"

Source citation for the canonical lines: `README.md` lines 189–346; `lexicons/v1.0.json` `grammar_skeletons.*.canonical_form`; `docs/DESIGN.md` "Canonical N'Ko Line Forms".

Site-side gloss (from `LearnNKo/web/src/lib/inscription/types.ts` lines 28–48 + `learnnko.com/claims` page sections):

• Stabilize: "Embodied variance decreasing - settling into stability" (`types.ts:58`)
• Disperse: "Embodied variance increasing - expanding into exploration" (`types.ts:59`)
• Transition: "Transitioning between semantic places" (`types.ts:60`)
• Return: "Returning to a previously visited basin" (`types.ts:61`)
• Dwell: "Sustained period of low variance - dwelling in stability" (`types.ts:62`)
• Oscillate: "Periodic changes in variance - rhythmic pattern" (`types.ts:63`)
• Recover: "Variance reducing after a spike - recovering equilibrium" (`types.ts:64`)
• Novel: "First encounter with a new basin - discovery" (`types.ts:65`)
• Place-Shift: "First visit to a new place - spatial novelty" (`types.ts:66`)
• Echo: "Pattern similar to a recent claim - echo or repetition" (`types.ts:67`)

Site-side categories (`LearnNKo/web/src/app/claims/page.tsx` lines 295–319):
- Variance: stabilize, disperse, recover
- Spatial: transition, return, placeShift
- Temporal: dwell, oscillate
- Pattern: novel, echo

The technical-formula heuristics shown on the site (`page.tsx` lines 102, 122, 142, 162, 182, 202, 222, 242, 262, 282):

• stabilize: `σ(t) - σ(t-Δ) < -θ`
• disperse: `σ(t) - σ(t-Δ) > +θ`
• transition: `place(t) ≠ place(t-1)`
• return: `basin(t) ∈ BasinHistory`
• dwell: `σ < θ_low for t > t_min`
• oscillate: `autocorr(σ) shows periodic peak`
• recover: `σ↓ following recent σ spike`
• novel: `basin(t) ∉ BasinLexicon`
• placeShift: `place(t) ∉ PlaceHistory`
• echo: `sim(claim_t, claim_{t-k}) > θ`

---

3. What is DELL?

There are TWO documented expansions of the acronym in the codebase. Both are used. They describe the same artifact (the latent engine that produces `z(t)`) but differ on what the letters spell out:

1. "Distributed Embodied Latent Learner" — used in the cc-inscription README (`README.md:24`), in `learnnko.com/claims` page narrative, and in memory file `comp-core-layers.md`.
2. "Dual-Equilibrium Latent Learning" — used in `learnnko.com/technical`, in the Rust DELL crate (`core/audio-media/cc-echelon/crates/dell/src/lib.rs:1`), in the cc-brain DELL updater (`crates/cc-brain/src/latent/dell.rs:3`), in `core/runtime/cc-core/README.md:10` ("DELL: Dual-Equilibrium Latent Learning with fast (frame-rate) and slow (beat-rate) equilibria"), and on `learnnko.com/technical`.

The implementation matches the second expansion: it is a two-timescale equilibrium system. Concretely:

• Fast equilibrium: 60 Hz, frame-rate motion processing, captures micro-dynamics (`dell/src/lib.rs:9`, `cc-core/cc_core/equilibria/fast_solver.py`).
• Slow equilibrium: ~2.5 Hz, beat-rate musical/macro context (`dell/src/lib.rs:10`, `cc-core/cc_core/equilibria/slow_solver.py`).
• Coupler: bidirectional fast↔slow interaction (`dell/src/lib.rs:11`, `cc-core/cc_core/operators/coupler.py`).
• Coordinator: produces a `DELLState` snapshot per frame (`dell/src/lib.rs:60`, `cc-core/cc_core/equilibria/coordinator.py`).

Implementation locations:

• Python: `core/runtime/cc-core/cc_core/equilibria/{fast_solver.py, slow_solver.py, coordinator.py}`, `cc_core/training/dell_losses.py`, `cc_core/integrations/mocopi_dell.py`.
• Rust port (standalone crate): `core/audio-media/cc-echelon/crates/dell/src/lib.rs` exporting `DELLConfig`, `DELLCoordinator`, `DELLState`, `FastEquilibrium`, `SlowEquilibrium`, `Coupler`, `PoolType`.
• Rust integration (latent updater): `core/audio-media/cc-echelon/crates/cc-brain/src/latent/dell.rs` defining `DellLatentUpdater` + `DellLatentConfig`, alongside `SimpleLatentUpdater` and `LearnedLatentUpdater` (`crates/cc-brain/src/latent/mod.rs:17-19`).

Public technical-page statement (verbatim via WebFetch from `learnnko.com/technical`): "DELL (Dual-Equilibrium Latent Learning): Described as a 'neural architecture operating on two timescales,' processing motion sensor input at 60 Hz."

`AGENTS.md` acronym table in `docs/01-GLOSSARY.md` states: "DELL | Distributed Embodied Latent Learner | z-trajectory source."

Unresolved gap: README/site narrative use "Distributed Embodied Latent Learner"; canonical implementation comments use "Dual-Equilibrium Latent Learning." This is a doc-vs-implementation drift, not a bug.

---

4. How cc-inscription consumes DELL output (the integration API)

The integration is defined in `src/integration/dell.rs`:

• `DellFrame { timestamp: f64, z: Vec<f32>, place: Option<String>, session_id: Option<String> }` (`dell.rs:9–19`)
• `impl From<DellFrame> for ZSample` (`dell.rs:21–29`)
• `DellSubscription` ring buffer with `new`, `push`, `as_samples`, `window`, `clear`, `len`, `is_empty` (`dell.rs:31–82`)
• `DellClient { base_url }` with `subscribe(buffer_size) -> DellSubscription`, `get_history(start_t, end_t) -> Vec<DellFrame>`, `get_current_place() -> Option<PlaceClass>` (per README API ref lines 690–702; the in-source `dell.rs` shipped here is the stub with `pub fn new(base_url)` — `dell.rs:84–120`).

`ZSample` is the universal input to detectors:

pub struct ZSample {
    pub t: f64,
    pub z: Vec<f32>,
    pub place: Option<PlaceClass>,
}

(`src/detector/mod.rs:18–28`)

`ClaimDetector` API (`src/detector/mod.rs`):

• `ClaimDetector::new(DetectorConfig::default())`
• `detector.register_basin(basin_id, centroid)`
• `detector.detect(&samples) -> Vec<Claim>`

`DetectorConfig` knobs (`README.md:786–793`):
- `min_confidence: f32`
- `dispersion_window: f64`
- `curvature_threshold: f64`
- `min_dwell_time: f64`
- `oscillation_threshold: f64`
- `novelty_threshold: f64`

Live consumer pattern (from `Comp-Core/backend/cc-mcs/src-tauri/src/inscription_runner.rs:1–35`) — this is the ONE place in the codebase where `cc-inscription` is actually wired to a sensor pipeline:

FusedSkeleton → inscription_bridge → ZSample → ClaimDetector → Claim → NKoLine

Bridge details (`cc-mcs/src-tauri/src/inscription_bridge.rs:1–24`): "Extracts a 63D motion vector from skeleton (14 limbs × 4 quat + 3 pos = 98D, compressed to 63D)" → `LatentSample` → `ZSegmentDigest` → `Evidence::Sensor`. All continuous values are converted to `QuantizedFloat` for deterministic hashing.

---

5. Repository inventory

5.1 Crate root files

• `Cargo.toml` (731 B) — `cc-inscription` v0.1.0, edition 2021, MIT (`Cargo.toml:1–7`). Deps: serde, serde_json, thiserror, hex, sha2, uuid v4, tracing, bincode, unicode-normalization, ciborium. Dev: tokio.
• `Cargo.lock` (21 531 B)
• `README.md` (26 274 B)
• `src/` (17 entries)
• `docs/` (7 markdown files)
• `lexicons/` (`v1.0.json`)

5.2 `src/` module map

Counted via `find … -name '*.rs'` → 51 Rust files.

Modules declared in `lib.rs` (lines 35–45):
`types`, `claims`, `basin`, `lexicon`, `surface`, `phrase`, `detector`, `integration`, `canonical`, `provenance`, `ontology`.

Plus two NOT-YET-in-`lib.rs` modules sitting at `src/` root that are git-untracked (per `git status`):
- `src/bundle.rs` — "Bundle types for the symbolic handoff layer. `InscriptionBundle` is the canonical artifact connecting: embodied-state windows -> typed claims -> N'Ko surface -> lowered control." (`bundle.rs:1–4`)
- `src/lowering.rs` — "Adapter-neutral lowering from typed claims to symbolic music-control intent. … stable symbolic edit types that downstream adapters can convert into Strudel-IR, conductor edits…" (`lowering.rs:1–5`)
- `src/chain_link/` — PsiChain hash-chained inscription links (`chain_link/mod.rs:1–28`) with submodules `combining.rs` (combining-mark depth markers) and `steganography.rs` (zero-width Unicode metadata embedding).

These three are present on disk but are NOT mod-declared in `src/lib.rs` (verified by reading `lib.rs:35–45`). They are working code, not phantom files (e.g. `bundle.rs` imports from `lowering.rs` and `provenance` and is 17.5 KB; the `chain_link/` modules are referenced inside themselves but not re-exported).

Module-by-module description (one-sentence each, taken from top docstrings):

5.3 Public API surface (item counts per file)

From `grep -E "^\spub\s+(fn|struct|enum|trait|const|type)\s" src//.rs`:

Total public-item declarations: ~822 across the crate.

`src/lib.rs` re-exports (`lib.rs:48–91`) the main entry points: `WallTime`, `MonoTicks`, `Timestamp`, `DeterministicTimeWindow`, `ClockAnomaly`, `QuantizedFloat`, `quantized_math`, `QuantizedConfidence`, `QuantizedDistance`, `QuantizedDelta`; the entire `canonical` module surface; `ProvenanceWitness`, `ArchiveRef`, `PureVerificationContext`, `VerificationResult`; the entire `ontology` surface (`SliceDeclaration`, `AdmissibilityToken`, `OntologyOpType`, `PredictabilityAssessment`, `OntologyOperation`, `OntologyOperationBuilder`, `SplitPayload`, `MergePayload`, …); the 10 claim structs + `Claim` enum + `ClaimType`, `ClaimId`, `BasinId`, `ProtoBasinId`, `PlaceClass`, `TimeWindow`, `Confidence`, `DispersionMetric`, `EntropyMetric`, `CoupledClaimType`, `NodeId`, `Symbol`; `Basin`, `ProtoBasin`, `GraduationCriteria`, `RetirementType`; `Lexicon`, `LexiconVersion`, `BasinToken`, `PlaceToken`; `SurfaceRenderer`, `NKoLine`.

5.4 `docs/` directory

7 files:

5.5 `lexicons/` directory

Only one file: `v1.0.json` (5 313 B). Schema:

• `version`: `"1.0.0"`
• `created_at`: `"2026-01-03T00:00:00Z"`
• `parent_version`: `null` (this is genesis)
• `operator_sigils`: 10 entries `{sigil, unicode, name, description, locked: true}` for stabilize/disperse/transition/return/dwell/oscillate/recover/novel/place_shift/echo
• `coupled_claim_sigils`: `{transition: ߕ, disperse: ߜ, stabilize: ߛ}`
• `retirement_markers`: `{spurious: ⊘ₛ, real_gone: ⊘ᵣ, coordinate_shift: ⊘ᵥ}`
• `grammar_skeletons`: 10 entries with `sigil`, `time_format` (`window`/`instant`), `body_template`, `slots[]`, `canonical_form`
• `time_formats`: `{window: "⟦{t0}–{t1}⟧", instant: "⟦{t}⟧"}`
• `slot_formats`: 15 named formatters (confidence, place, sharpness, last_seen, distance, stability, frequency, amplitude, latency, ratio, distance_to_nearest, support, coupled_claim, similarity, ref_count)
• `basin_tokens`: `{}` (empty at v1)
• `place_tokens`: `{}` (empty at v1)
• `phrases`: `[]`
• `changelog`: `[]`

---

6. The typed-IR claim structs (one block, source: README.md:176–344)

pub struct StabilizeClaim   { id, window, dims, metric: DispersionMetric, delta, magnitude, confidence, place }
pub struct DisperseClaim    { id, window, metric: EntropyMetric, delta, magnitude, confidence, place }
pub struct TransitionClaim  { id, t_star, from_basin, to_basin, sharpness, confidence, place_from, place_to }
pub struct ReturnClaim      { id, t_star, basin, last_seen, distance, confidence }
pub struct DwellClaim       { id, window, basin, dwell_time, stability, confidence }
pub struct OscillateClaim   { id, window, basins, frequency, amplitude, confidence }
pub struct RecoverClaim     { id, event_t, target_basin, latency, baseline, ratio, confidence }
pub struct NovelClaim       { id, t_star, proto_id, distance_to_nearest, support_k, confidence }
pub struct PlaceShiftClaim  { id, t_star, from, to, coupled_claim: CoupledClaimType, confidence }
pub struct EchoClaim        { id, window, match_set, similarity, outcome_tag, confidence }

pub enum Claim { Stabilize(...), Disperse(...), Transition(...), Return(...), Dwell(...),
                 Oscillate(...), Recover(...), Novel(...), PlaceShift(...), Echo(...) }

impl Claim {
    pub fn sigil(&self) -> char;
    pub fn claim_type(&self) -> ClaimType;
    pub fn id(&self) -> ClaimId;
    pub fn confidence(&self) -> Confidence;
    pub fn time_range(&self) -> (f64, f64);
    pub fn time_window(&self) -> Option<TimeWindow>;
    pub fn instant(&self) -> Option<f64>;
    pub fn place(&self) -> Option<&PlaceClass>;
}

Supporting types (`README.md:352–410`):

• `BasinId(pub [u8; 16])` — UUID-shaped kernel-level primary key, with `mint()`, `to_hex()`, `short_hex()`
• `PlaceClass(pub String)` — coarse categorical location (NOT GPS); examples "home", "office", "gym", "transit"
• `TimeWindow { t0: f64, t1: f64 }` — seconds; `duration`, `midpoint`, `contains`
• `Confidence(pub f32)` — clamped [0,1]; `is_high() >= 0.7`, `is_low() < 0.3`

---

7. Basin lifecycle (source: README.md:444–512, DESIGN.md "Basin Lifecycle")

State machine:

ProtoBasin ── graduation ──► Basin ─┬─ split  ──► [Child₁, Child₂]
    │                               ├─ merge  ──► Parent
    │ expires                       └─ retire ──► Retired
    ▼
Retired(Spurious)                                    Retired(RealGone | CoordShift)

Graduation criteria — three independent persistence signals (`README.md:472–483`):

pub struct GraduationCriteria {
    pub min_return_sessions: usize,                 // 1. Re-entry across separate sessions (min 3)
    pub max_internal_dispersion_ratio: f64,         // 2. Low internal dispersion vs global (max 0.3)
    pub transition_consistency_threshold: f64,      // 3. Repeatable transition signature (min 0.7)
}

Retirement types (`README.md:498–510`):
- `Spurious { proto_id, reason }` — never real
- `RealButGone { basin_id, last_visit, total_dwells }` — attractor vanished
- `CoordinateShift { basin_id, old_version, new_version }` — coordinate system changed

Deprecation markers: `⊘ₛ` (spurious), `⊘ᵣ` (real-gone), `⊘ᵥ` (coordinate-shift) (`README.md:511`).

Split rule (`DESIGN.md` "Split Rules"): "The distribution is demonstrably multi-modal in a way that predicts different downstream dynamics. Two subclusters that look different but lead to the same transition behavior = ornamental complexity, refuse split."

Merge rule (`DESIGN.md` "Merge Rules"): "Two basin keys have become empirically indistinguishable within measurement resolution."

---

8. Lexicon versioning (source: README.md:514–558, lexicons/v1.0.json)

Core principle: "No retroactive rewriting. Old inscriptions remain untouched. Reinterpretation is an optional derived view."

Stability classes:

Change taxonomy (`README.md:548–557`):

pub enum LexiconChange {
    BasinAdded { id, token },
    BasinRenamed { id, old_token, new_token },
    BasinSplit { parent, children },
    BasinMerged { absorbed, into },
    BasinRetired { id, retirement },
    PlaceClassAdded { class, token },
    PhraseRegistered { phrase_id, pattern },
}

---

9. Surface rendering (source: README.md:562–608, surface/mod.rs:1–14)

Pipeline:

let lexicon = Arc::new(Lexicon::v1());
let renderer = SurfaceRenderer::new(lexicon);
let line: NKoLine = renderer.render(&Claim::Stabilize(claim));
// "ߛ ⟦100.0–200.0⟧ : z(σ) ↓ ; home ; c=0.85"

Two surface forms (`surface/mod.rs:8–14`):
1. `canonical_text` — for hashing and provenance, NFC-normalized, no BiDi isolates.
2. `display_text` — for terminal/UI rendering, with BiDi isolates.

`NKoLine { text, claim_id, lexicon_version }`.

---

10. Phrase emergence (source: README.md:612–648, phrase/mod.rs)

A phrase is a "compressible macro over a sequence of claims." Registered only when frequent AND compresses description AND improves prediction.

pub struct Phrase {
    pub id: PhraseId,
    pub pattern: Vec<ClaimPattern>,
    pub frequency: usize,
    pub compression_ratio: f64,
    pub predictive_gain: f64,
    pub nko_idiom: Option<String>,
}

Worked example "Arrival Turbulence" = PlaceShift → Disperse → Oscillate, collapses 3 lines into:

⟨arrival-turbulence⟩ ⟦t*–t2⟧ : home→office ; B1⇄B2

---

11. Provenance + canonical serialization (source: provenance/mod.rs, canonical/mod.rs)

Provenance Law (`provenance/mod.rs:1–18`): "For any InscriptionId `id`, given the archived evidence bundle, the lexicon at `lexicon_hash`, the basis at `basis_id`, the claim detection configuration, then: (1) the claim IR can be deterministically recomputed; (2) the N'Ko surface can be deterministically re-rendered; (3) the recomputed InscriptionId MUST equal `id`. If this property ever fails, the corpus is corrupted."

Canonical format (`canonical/mod.rs:1–28`): CBOR Canonical (RFC 8949 §4.2.1) with extra rules:
- Maps: keys sorted by canonical byte comparison (shortest first, then lexicographic)
- Sets: elements emitted in sorted order
- Strings: NFC-normalized UTF-8
- Floats: FORBIDDEN — use `QuantizedFloat` (i64 mantissa, scale 10⁶)
- Integers: shortest CBOR canonical encoding
- Arrays: order-preserving
- Multi-byte integers: big-endian (network byte order) for cross-platform hash stability

Public API: `canonical_serialize`, `canonical_deserialize`, `canonical_hash`, `sha256`, `Digest32`, `Digest16`, `ContentHash`, `NfcString`, `is_nfc`, `to_nfc`, `validate_nfc`, `canonical_bytes_cmp`, `canonical_sort`.

`ProvenanceWitness` type (`README.md:62–70` and `provenance/mod.rs` example) chains:

z-trajectory → ClaimDetector → Typed IR → Lexicon → N'Ko Surface → Proof Scaffold

---

12. Ontology governance (source: ontology/mod.rs, integration/graph_kernel.rs, integration/rag.rs, docs/PHASE2_IMPLEMENTATION.md)

Every lexicon-mutating operation must declare:
1. Which slice it consults (`SliceDeclaration` with `SliceFingerprint` + `AdmissibilityToken` from Graph Kernel) (`ontology/mod.rs:8–11`).
2. A predictability assessment (before/after delta measured by RAG++) (`integration/rag.rs:1–24`).

`OntologyOpType` (PHASE2_IMPLEMENTATION lines 137–143):

pub enum OntologyOperationType {
    ProposeSplit(BasinId),
    ProposeMerge(Vec<BasinId>),
    ProposeRetire(BasinId),
    GraduateProto(ProtoBasinId),
    RegisterPhrase(PhraseId),
}

Evidence sufficiency defaults (`integration/graph_kernel.rs` quoted in PHASE2 doc): `min_turns: 10`, `min_time_span: 86400.0` (1 day), `min_sessions: 3`.

RAG++'s explicit role boundary (`integration/rag.rs:7–17`):
- IS a bounded critic: retrieves comparable cases, measures prediction error before/after, emits quantitative verdicts (delta in bits of surprise).
- IS NOT allowed to: generate basin centroids, propose ontology changes, create new claim types.

---

13. PsiChain (source: chain_link/mod.rs, chain_link/combining.rs, chain_link/steganography.rs)

Chain formula (`chain_link/mod.rs:5–9`):

Ψ(t+1) = inscribe(z(t), Ψ(0..t), L(t), B(t))

Each inscription depends on every previous inscription through a SHA-256 link. Existing `ProvenanceWitness` has a content hash but no link to predecessor; PsiChain adds the chain link.

Two visual encodings:
1. Combining marks (`chain_link/combining.rs:1–28`): N'Ko combining marks U+07EB through U+07F3 inject AFTER the renderer but BEFORE the surface hash, so depth markers are part of the cryptographic commitment. Depth 0 has no mark; depths 1..8 use marks 230-class above the character; depth 9 uses U+07F3 (220-class, below).
2. Steganography (`chain_link/steganography.rs:1–35`): Zero-width characters U+200B (=0) / U+200C (=1) encode chain_height (8 B), epoch_number (8 B), device_hash (4 B), checksum (2 B), bracketed by sentinels U+200D and U+FEFF. Surviving copy/paste but lost on retype, in which case surface hash changes.

These three modules (`chain_link/mod.rs`, `combining.rs`, `steganography.rs`) are git-untracked and NOT mod-declared in `src/lib.rs:35–45`.

---

14. The public site at `learnnko.com`

14.1 Local source

Located at `[home]/projects/LearnNKo/` — monorepo.

Stack of the web target (`[home]/projects/LearnNKo/web/package.json`):
- Next.js 15.0.7, React 18.2.0, TypeScript 5
- Tailwind 3.4, Radix UI, framer-motion 12, lucide-react
- Prisma 5.21 + Supabase JS
- Anthropic SDK 0.39, Google Generative AI 0.21, OpenAI 4.86
- next-auth 4.24, next-themes
- React-Leaflet, Google Maps, d3, recharts

Monorepo layout (`[home]/projects/LearnNKo/CLAUDE.md`):
| Directory | Language | Purpose |
|-----------|----------|---------|
| `web/` | TS/Next.js | Learning web app (SRS, lessons, dictionary) |
| `pipeline/` | Python | Video extraction, 5 generative worlds, benchmarks |
| `ml/` | Python | NLLB fine-tuning, Bambara ASR, cloud training |
| `nko/` | Python | Core NLP package |
| `ios/` | Swift | iOS app + keyboard extension |
| `shared/` | Swift + Python | Shared libraries |

14.2 Page sources

The three pages live at:
- `[home]/projects/LearnNKo/web/src/app/claims/page.tsx` (1 224 lines)
- `[home]/projects/LearnNKo/web/src/app/technical/page.tsx` (3 958 lines)
- `[home]/projects/LearnNKo/web/src/app/nip/page.tsx` (1 517 lines)

Shared types:
- `[home]/projects/LearnNKo/web/src/lib/inscription/types.ts` (canonical TS mirror of the Rust IR: `ClaimType`, `CLAIM_SIGILS`, `CLAIM_DESCRIPTIONS`, `CLAIM_COLORS`, `TimeWindow`, `Inscription`, …)
- `[home]/projects/LearnNKo/web/src/lib/inscription/websocket.ts`

Live inscription UI components:
- `[home]/projects/LearnNKo/web/src/components/inscription/live/InscriptionCard.tsx`
- `[home]/projects/LearnNKo/web/src/components/inscription/live/InscriptionStream.tsx`
- `[home]/projects/LearnNKo/web/src/components/inscription/live/InscriptionTicker.tsx`
- `[home]/projects/LearnNKo/web/src/components/inscription/live/SessionReview.tsx`
- `[home]/projects/LearnNKo/web/src/components/inscription/live/ClaimLegend.tsx`

The `InscriptionStream` component opens a WebSocket to "the GCP VM fusion system (6Hz updates)" (`InscriptionStream.tsx:5–13`). The `types.ts:7-12` docstring states the architecture: "Backend: GCP VM fusion system ([ip]:8765) detects claims; Frontend: Receives inscriptions via WebSocket + Supabase; Detection: 6Hz (every 10 frames at 60fps)."

14.3 What `/claims` says (per WebFetch + local source)

Overall description (verbatim from `learnnko.com/claims`): "Claims are statements about your embodied state - descriptions of how your body is moving, settling, transitioning, or discovering new patterns."

Detection mechanism (verbatim): "Motion sensors capture your movement, fusion algorithms analyze the patterns, and claim detectors identify meaningful events in real-time."

The site lists all 10 claim names + sigils (matches the Rust crate). Definitions on the public page narrative are friendlier than the Rust docstrings (e.g., "Movement settling into consistency" vs `README.md`'s "Dispersion decreased measurably"). The local source `page.tsx:92-293` has `CLAIM_DETAILS` with `bodyMetaphor`, `technicalFormula`, `examples`, `colorClass` for each of the 10.

14.4 What `/technical` says (per WebFetch + local source)

Public quotes (verbatim):
- DELL (Dual-Equilibrium Latent Learning): "neural architecture operating on two timescales, processing motion sensor input at 60 Hz."
- Pipeline Flow: `Motion Sensors (60 Hz) → DELL (z-trajectory embeddings) → ClaimDetector (10 typed detectors) → Claim IR (typed representation) → Lexicon → Surface N'Ko render`
- Graph Kernel: "Deterministic context slicing engine for bounded, reproducible slices"
- Claim IR: "Strongly-typed intermediate representation for each claim type"
- Basin Lifecycle: Proto-basin → Basin → Split/Merge/Retire transitions
- Provenance Chain: `z-trajectory → ClaimDetector → Typed IR → Lexicon → N'Ko Surface → Proof Scaffold`
- Detector categories: Variance, Spatial, Temporal, Pattern, Transition.

Design principles surfaced:
- Anticipation Over Prediction: "Detects when dynamics become constrained enough that a claim is warranted"
- Non-Retroactive Corpus: "Original inscriptions remain untouched when lexicon evolves"
- Determinism First: "Same inputs must produce byte-identical outputs across runs"

Line structure (verbatim): `⟨operator-sigil⟩ ⟨time-marker⟩ : ⟨claim-body⟩ ; ⟨slots⟩`

14.5 What `/nip` says (per WebFetch + local source)

NIP stands for "N'Ko Improvement Proposals" (confirmed by `LearnNKo/web/src/app/nip/page.tsx:2`). They are the constitutional framework for the N'Ko Inscription System. Ten NIPs are embedded in `page.tsx:28-1295` as full markdown content:

Verbatim from NIP-0001 (per `page.tsx:29-205` and WebFetch): "The system exists to produce replayable, justified, bounded inscriptions from embodied dynamics, rendered in a controlled N'Ko technical register, with cryptographic provenance and audit-grade determinism." Primitive objects defined: Claim, Evidence (`Graph | Sensor | Hybrid`), Surface, Inscription, InscriptionId, Slice, Ontology, Derived view.

NIP-0001 §3 Replayability Law: "Inputs required for replay MUST be sufficient to re-run evidence acquisition, claim detection, canonical surface rendering, and `InscriptionId` recomputation. The recomputed identifier MUST equal the original identifier `id`. Any mismatch MUST be treated as corpus corruption or implementation non-compliance."

NIP-0001 §4 Determinism Charter:
- §4.1 Time determinism: "monotonic time MUST be used for intra-session ordering, and wall time MUST be used only for anchoring and external correlation."
- §4.2 Numeric determinism: "Any continuous value that contributes to hashes MUST be quantized into a fixed-point representation. Raw floats MUST NOT enter canonical serialization."
- §4.3 Text determinism: "Canonical surface text MUST be Unicode-normalized (NFC or stricter), and hashing MUST use that canonical form."

---

15. Alignment check: site vs Rust crate

No semantic drift on the 10-claim contract. The only meaningful divergence is the DELL acronym text and live-rate numbers.

---

16. Dependents and integration footprint (full Cargo grep)

`grep -rln "cc-inscription" --include="Cargo.toml"` returns exactly two manifests:
- `[home]/Desktop/Comp-Core/core/semantic/cc-inscription/Cargo.toml` (the crate itself)
- `[home]/Desktop/Comp-Core/backend/cc-mcs/src-tauri/Cargo.toml` (line 33: `cc-inscription = { path = "../../../core/semantic/cc-inscription" }`)

`grep -rln "cc_inscription"` finds Rust callers in only one package: `cc-mcs` (3 files: `inscription_bridge.rs`, `inscription_runner.rs`, `main_headless.rs`). Self-references inside cc-inscription itself live in `src/surface/normalize.rs` and `src/types/quantized.rs` docstrings.

The K11/echelon chain crates (`cc-brain`, `echelon-bar`, `femto-bridge`, `motion-bridge`) — verified by reading their `Cargo.toml` files — do NOT declare `cc-inscription` as a dependency. `echelon-bar/Cargo.toml` lists only: `anyhow`, `cc-brain`, `clap`, `femto-bridge`, `serde`, `serde_json`, `tokio`, `tracing`, `tracing-subscriber`. `cc-brain/Cargo.toml` declares only `femto-bridge` from the workspace plus optional `cc-anticipation`, `cc-gesture`, `cc-collection`.

The on-device claim detector path uses an independent implementation:

• `[home]/Desktop/Comp-Core/core/audio-media/cc-echelon/crates/cc-brain/src/san/claim_bridge.rs` (sigil-map at lines 31–43): a self-contained 104D-latent → 10-claim detector with Welford-online statistics over a 30-frame (~1 s @ 30 Hz) window. Its file-level docstring (`claim_bridge.rs:1-5`): "Claim Bridge: 104D Echelon latent state → 10 N'Ko inscription claim signals. Maps the flattened 104D latent vector from the SAN pipeline onto the 10 claim types defined in `cc-inscription`. This is a lightweight, self-contained detector that runs at 30Hz with no external dependencies." Line 234 confirms: "Claim index (0-9), matching `ClaimType::to_index()` in cc-inscription."
• C-ABI exposed at `cc-brain/src/ffi.rs:957–1090`: `claim_bridge_create`, `claim_bridge_destroy`, `claim_bridge_detect`, `claim_bridge_reset`, `claim_bridge_basin_count`, `claim_bridge_frame_count`. Returns `ClaimDetectionFFI { sigil_bytes[4], sigil_len, index, confidence, behavior[5] }`.
• Swift consumer: `[home]/Desktop/MotionMixApp/MotionMixApp/Services/ClaimBridgeService.swift` (40+ lines visible) — `@MainActor final class ClaimBridgeService`, calls FFI, posts to `http://[ip]:3211/inscription/motion` (a Convex endpoint on a Tailscale IP), debounce 2 s per claim type, `minPostConfidence = 0.6`.

So there are TWO live claim pipelines on Mohamed's mesh:
1. iOS / MotionMix path (the one running today): `MotionMix.app → EchelonCore (cc-brain) → SAN pipeline → 104D latent → claim_bridge.rs → ClaimBridgeService.swift → POST /inscription/motion → Convex → learnnko.com WebSocket → InscriptionStream`. Bypasses cc-inscription entirely; only the sigil/index contract is shared.
2. Desktop / cc-mcs path (Tauri app, less recently active): `cc-collection FusedSkeleton → inscription_bridge.rs → ZSample → cc-inscription::ClaimDetector → Claim → NKoLine` (via `inscription_runner.rs::InscriptionRunner` instantiated in `main_headless.rs:205` with `Lexicon::v1()`).

---

17. K11 live LUMA pipeline status

K11 / LUME bar pipeline today (per `echelon-bar/src/main.rs:1-40` and memory file `lume-femto-only-step1-step2pt1-2026-05-09.md`):

Femto Mega RGB → mediapipe_pose_verify.py (MediaPipe BlazePose 3D) → JSONL skeleton stream
   → echelon-bar (Rust binary)
   → femto-bridge::Encoder (skeleton → 128D)
   → cc-brain::EchelonCore.update_femto_skeleton + dynamics_128()
   → LUMA UDP datagram on :9703
   → Sky Garden Unity visuals

`cc-inscription` is NOT in this pipeline. `echelon-bar/Cargo.toml` doesn't link it. The 128D vector that `dynamics_128()` returns (`memory: lume-femto-only-step1-step2pt1-2026-05-09.md`) is published over UDP for Sky Garden; it is NOT shoveled into a `ClaimDetector` or `ZSample` anywhere on the live bar path.

Where wiring would land if it were ever connected (NOT a proposal, just observation): `echelon-bar/src/main.rs` already has every input that `cc-inscription` needs — timestamped 128D vectors, a place class (the bar), a session. A `cc-inscription` integration would mirror what `cc-mcs` already does in `inscription_runner.rs`, just with `FemtoSkeleton`/`LatentState` instead of `FusedSkeleton`.

The integration that DOES exist in cc-echelon today (`cc-brain/src/san/claim_bridge.rs`) emits claims with the same sigil contract but emits them locally, posts them direct to Convex from MotionMix iOS, and is not invoked at all from `echelon-bar` (no Swift on the bar; no claim_bridge wiring in `main.rs`).

Memory file `lume-nko-convergence-2026-05-02.md` lays out the intended convergence: bar display N'Ko inscription on 1920×440 strip, `LumeNkoInscriber.cs` Unity component, `LUMN` codepoint wire-format parallel to LUMA/LUMD/LUMF/LUMM. None of these have shipped onto the K11 bar path yet — they live as content-strategy / Wave 9+ candidates.

---

18. Memory files mentioning inscription / sigil / DELL

Located in `[home]/.claude/projects/-Users-mohameddiomande/memory/`. Relevant files and one-line notes:

• `inscription-architecture-decision.md` (2026-04-05): Claude+Codex adversarial review concluded that Unicode codepoints do NOT encode opacity; opacity must live in a separate `inscriptionUnits` Convex table. Settled the schema split `memoryUnits` (semantic content) vs `inscriptionUnits` (dynamical shape).
• `plan-nko-convergence-april2026.md` (2026-04-14): Master convergence plan tying ASR, paper updates, inscription integration, learnnko.com migration, vocabulary expansion. Notes `inscriptionUnits` extended for motion/speech/conversation sources; `inscriptions.ts` mutations (`inscribeMotion`, `inscribeSpeech`, `inscribeConversation`); HTTP routes (`POST /inscription/motion`, `/speech`).
• `lume-nko-convergence-2026-05-02.md`: LUME × N'Ko convergence — bar wordmark deboss → N'Ko, 1920×440 inscription strip, sigil-composer × LumeMocopiReceiver, new `LUMN` wire format. Wave 9+ candidate `LumeNkoInscriber.cs`.
• `nko-cognitive-representation.md`: Vision for a secondary NKo model that converts cognitive-twin output to N'Ko, learning new vocab from Mohamed's patterns. Connects to cc-inscription for blockchain encoding.
• `epoch-appchain.md` (2026-03-20): EPOCH appchain plan to embed GK, RAG++, cc-inscription, cc-semantic as native Stacks fork modules. "96 682 lines of production Rust across 6 crates ready for embedding. 5 native Clarity functions: graph-query, verify-admissibility, rag-search, render-inscription, analyze-semantic-state."
• `comp-core-layers.md`: Confirms `cc-inscription` lives in `core/semantic/` semantic layer alongside `cc-graph-kernel` (port 8001) and `cc-cognitivetwin-bridge`.
• `lse-engram-architecture-insights.md`, `nko-paper4-reproduction-launcher.md`, `numu-fare.md`: side mentions of sigils/inscription in unrelated contexts.

Cross-cutting fact from memory: the live inscription path Mohamed's UI sees on `learnnko.com` is fed by Convex via the `iOS → ClaimBridgeService → POST /inscription/motion → Convex → WebSocket` route, NOT by the Rust `cc-inscription` crate. The Rust crate is the authoritative semantic spec; the production live feed is a parallel implementation that honors the same sigil contract.

---

19. Git state of cc-inscription

• Repo containing the crate: `[home]/Desktop/Comp-Core` (Comp-Core monorepo)
• Current branch: `feat/femto-only-bar`
• Last commit touching the crate (scoped to `core/semantic/cc-inscription/`): `4bcca8d5 2026-01-12 refactor(core): Reorganize 35 projects into 8 domain folders`
• Previous semantically-meaningful commits (full repo grep on path "inscription"):
• `b5bb2855` fix(cc-inscription): Recalibrate thresholds for 63D z-vector scale
• `4277de9f` feat(cc-inscription): Improve claim detection thresholds and add basin auto-registration
• `0a00c07a` feat(inscription): Add sensor-based inscription processing
• `b04b748d` feat(inscription): Add database persistence and enhanced logging for N'Ko inscriptions
• `fbfaf4eb` fix(docker): Add missing cc-gesture, cc-inscription, and dell crates to Dockerfile
• Uncommitted state inside the crate (`git status -s core/semantic/cc-inscription/`):
• `?? core/semantic/cc-inscription/src/bundle.rs`
• `?? core/semantic/cc-inscription/src/chain_link/` (mod.rs, combining.rs, steganography.rs)
• `?? core/semantic/cc-inscription/src/lowering.rs`

Modified files in the working tree but not staged: none specific to cc-inscription beyond the three untracked additions above. (`lib.rs` shows `mtime` May 10 17:31 but no `M` flag in `git status` for it, so it has been touched but content matches HEAD.)

---

20. Answering the framing questions

What does cc-inscription do?
It compiles `z`-trajectory (from DELL) plus place + slice context into typed Rust claims of 10 fixed types, each represented internally as an IR struct and externally as a one-line N'Ko sentence; it locks every output to a content hash and a `ProvenanceWitness` so the whole inscription is replayable bit-for-bit from archived inputs. (Sources: `src/lib.rs:1-32`, `README.md:1-91`, `docs/00-PROJECT_CHARTER.md`.)

The exact 10 claim types with definitions + sigils.
Listed in §2 above.

What is DELL (z-trajectory generator)?
Two-timescale equilibrium engine. Acronym used inconsistently across sources: cc-inscription README says "Distributed Embodied Latent Learner"; cc-core, cc-echelon, and `learnnko.com/technical` say "Dual-Equilibrium Latent Learning." Same artifact: fast equilibrium at 60 Hz + slow equilibrium at ~2.5 Hz coupled bidirectionally; outputs `z(t)` per frame plus a `DELLState` snapshot. Code in `core/runtime/cc-core/cc_core/equilibria/` (Python) and `core/audio-media/cc-echelon/crates/dell/` (Rust port) and `crates/cc-brain/src/latent/dell.rs` (cc-brain latent updater).

How does cc-inscription consume DELL output?
Through the `integration::dell` module: `DellFrame { timestamp, z, place, session_id }` → `From<DellFrame> for ZSample`. `DellSubscription` buffers frames; `DellClient.subscribe / get_history / get_current_place` is the documented API. `ZSample` then flows into `ClaimDetector::detect()`. In production, the bridge is implemented in `cc-mcs` (Tauri app) as `FusedSkeleton → inscription_bridge::extract_z_vector (63D) → LatentSample → ClaimDetector`. (Sources: `src/integration/dell.rs`, `src/detector/mod.rs`, `cc-mcs/src-tauri/src/inscription_bridge.rs`, `cc-mcs/src-tauri/src/inscription_runner.rs`.)

Where in the K11 live pipeline does cc-inscription fit?
It currently DOES NOT fit. `echelon-bar/Cargo.toml` doesn't link `cc-inscription`. The K11 bar binary publishes the 128D vector over LUMA UDP to Sky Garden; no claim detection runs on bar today. The parallel iOS path (MotionMix) uses `cc-brain::san::claim_bridge`, an independent self-contained detector with the same sigil contract, posting via Convex to `learnnko.com`. (Sources: `echelon-bar/src/main.rs:1-40`, `cc-brain/src/san/claim_bridge.rs:1-50`, `MotionMixApp/Services/ClaimBridgeService.swift:1-30`, memory file `lume-femto-only-step1-step2pt1-2026-05-09.md`.)

What does the public surface say IS, vs what the Rust crate does?
Aligned on contract (10 sigils, IR types, pipeline shape, replayability, determinism, basin lifecycle). Diverges on DELL acronym text and on live-rate numbers (site says 60 Hz → 6 Hz detection; cc-brain runs at 30 Hz). The public site claims a "GCP VM fusion system [ip]:8765" feeds it via WebSocket (`types.ts:8-12`), but Mohamed's local memory + code show the production feed runs through MotionMix iOS → Convex, not through `cc-inscription`'s `DellClient`.

What is "nip"?
N'Ko Improvement Proposals — the constitutional document set for the inscription system. 10 NIPs (NIP-0001 Core Charter through NIP-0010 Inter-Subject Comparison Ethics), embedded as markdown in `LearnNKo/web/src/app/nip/page.tsx`. NIP-0001 establishes the Replayability Law and the Determinism Charter that the Rust crate enforces in code.

Is the local learnnko site source available, and where?
Yes. Located at `[home]/projects/LearnNKo/web/`. Stack: Next.js 15 / React 18 / TypeScript 5 / Tailwind 3 / Prisma + Supabase / Anthropic + Gemini + OpenAI SDKs / next-auth. The three target pages render from:
- `[home]/projects/LearnNKo/web/src/app/claims/page.tsx`
- `[home]/projects/LearnNKo/web/src/app/technical/page.tsx`
- `[home]/projects/LearnNKo/web/src/app/nip/page.tsx`

Shared types and live components under `[home]/projects/LearnNKo/web/src/lib/inscription/` and `[home]/projects/LearnNKo/web/src/components/inscription/live/`.

What's the gap between "what's built" and "what's running on K11 right now"?
What's built in `cc-inscription`:
- All 10 typed claim IR structs + canonical N'Ko rendering + `Lexicon::v1()`.
- Full basin lifecycle (proto → graduate → split/merge/retire), with three retirement markers.
- Phrase emergence (sequence mining + compression + predictive-gain gating).
- Ontology operations with slice declarations + RAG++ predictability assessment.
- Provenance Law machinery: canonical CBOR + NFC + quantized floats + `InscriptionId` + `ProvenanceWitness`.
- PsiChain hash-chained inscriptions with combining-mark depth + zero-width steganography (untracked).
- `bundle.rs` and `lowering.rs` symbolic-handoff layer + adapter-neutral lowering to Strudel/conductor edits (untracked).
- Wired end-to-end inside the desktop `cc-mcs` Tauri app via `inscription_bridge.rs` + `inscription_runner.rs` (online + offline modes).

What's running on K11 today:
- `echelon-bar` reading MediaPipe skeleton JSONL, running `femto-bridge::Encoder` to 128D, publishing LUMA UDP to Sky Garden. No claim detection. No N'Ko surface output. No `cc-inscription` link.

Gap, concretely:
- K11 pipeline emits a 128D state vector but never feeds it to `ClaimDetector`.
- The 10-claim contract on `learnnko.com` is fed in production by the iOS `claim_bridge` path, not by anything on K11.
- `cc-inscription`'s `DellClient` is a stub — there is no real subscribe-to-DELL wire on disk.
- `cc-mcs` (Tauri) is the only place the full `cc-inscription` pipeline runs against fused skeleton input.
- The three untracked modules (`bundle.rs`, `lowering.rs`, `chain_link/`) are not declared in `lib.rs`; they will not be compiled by external callers until added to `lib.rs::mod` declarations.

---

21. Source citation index

This synthesis references the following files (absolute paths) and URLs:

Rust crate:
- `[home]/Desktop/Comp-Core/core/semantic/cc-inscription/Cargo.toml`
- `[home]/Desktop/Comp-Core/core/semantic/cc-inscription/README.md`
- `[home]/Desktop/Comp-Core/core/semantic/cc-inscription/lexicons/v1.0.json`
- `[home]/Desktop/Comp-Core/core/semantic/cc-inscription/src/lib.rs`
- `[home]/Desktop/Comp-Core/core/semantic/cc-inscription/src/bundle.rs`
- `[home]/Desktop/Comp-Core/core/semantic/cc-inscription/src/lowering.rs`
- `[home]/Desktop/Comp-Core/core/semantic/cc-inscription/src/types/{mod,time,quantized,basis,evidence,session}.rs`
- `[home]/Desktop/Comp-Core/core/semantic/cc-inscription/src/claims/{mod,stabilize,disperse,transition,return_,dwell,oscillate,recover,novel,place_shift,echo}.rs`
- `[home]/Desktop/Comp-Core/core/semantic/cc-inscription/src/basin/{mod,proto,graduation,lifecycle,constitution}.rs`
- `[home]/Desktop/Comp-Core/core/semantic/cc-inscription/src/lexicon/{mod,version,tokens,changelog,reinterpret,epoch}.rs`
- `[home]/Desktop/Comp-Core/core/semantic/cc-inscription/src/surface/{mod,renderer,grammar,slots,normalize}.rs`
- `[home]/Desktop/Comp-Core/core/semantic/cc-inscription/src/phrase/{mod,detection,compression,registration}.rs`
- `[home]/Desktop/Comp-Core/core/semantic/cc-inscription/src/detector/{mod,dynamics}.rs`
- `[home]/Desktop/Comp-Core/core/semantic/cc-inscription/src/integration/{mod,dell,sensor,graph_kernel,rag}.rs`
- `[home]/Desktop/Comp-Core/core/semantic/cc-inscription/src/canonical/mod.rs`
- `[home]/Desktop/Comp-Core/core/semantic/cc-inscription/src/provenance/mod.rs`
- `[home]/Desktop/Comp-Core/core/semantic/cc-inscription/src/ontology/mod.rs`
- `[home]/Desktop/Comp-Core/core/semantic/cc-inscription/src/chain_link/{mod,combining,steganography}.rs`
- `[home]/Desktop/Comp-Core/core/semantic/cc-inscription/docs/00-PROJECT_CHARTER.md`
- `[home]/Desktop/Comp-Core/core/semantic/cc-inscription/docs/01-GLOSSARY.md`
- `[home]/Desktop/Comp-Core/core/semantic/cc-inscription/docs/02-INVARIANTS_LEDGER.md`
- `[home]/Desktop/Comp-Core/core/semantic/cc-inscription/docs/03-IMPLEMENTATION_GUIDE.md`
- `[home]/Desktop/Comp-Core/core/semantic/cc-inscription/docs/DESIGN.md`
- `[home]/Desktop/Comp-Core/core/semantic/cc-inscription/docs/IMPLEMENTATION_SUMMARY.md`
- `[home]/Desktop/Comp-Core/core/semantic/cc-inscription/docs/PHASE2_IMPLEMENTATION.md`

Dependent Rust crates:
- `[home]/Desktop/Comp-Core/backend/cc-mcs/src-tauri/Cargo.toml`
- `[home]/Desktop/Comp-Core/backend/cc-mcs/src-tauri/src/inscription_bridge.rs`
- `[home]/Desktop/Comp-Core/backend/cc-mcs/src-tauri/src/inscription_runner.rs`
- `[home]/Desktop/Comp-Core/backend/cc-mcs/src-tauri/src/main_headless.rs`
- `[home]/Desktop/Comp-Core/backend/cc-mcs/src-tauri/src/visualization.rs`

DELL implementations:
- `[home]/Desktop/Comp-Core/core/audio-media/cc-echelon/crates/dell/src/lib.rs`
- `[home]/Desktop/Comp-Core/core/audio-media/cc-echelon/crates/cc-brain/src/latent/dell.rs`
- `[home]/Desktop/Comp-Core/core/audio-media/cc-echelon/crates/cc-brain/src/latent/mod.rs`
- `[home]/Desktop/Comp-Core/core/runtime/cc-core/README.md`
- `[home]/Desktop/Comp-Core/core/runtime/cc-core/cc_core/equilibria/coordinator.py`
- `[home]/Desktop/Comp-Core/core/runtime/cc-core/cc_core/equilibria/fast_solver.py`
- `[home]/Desktop/Comp-Core/core/runtime/cc-core/cc_core/equilibria/slow_solver.py`
- `[home]/Desktop/Comp-Core/core/runtime/cc-core/cc_core/training/dell_losses.py`
- `[home]/Desktop/Comp-Core/core/runtime/cc-core/cc_core/integrations/mocopi_dell.py`

K11 / live pipeline:
- `[home]/Desktop/Comp-Core/core/audio-media/cc-echelon/crates/echelon-bar/src/main.rs`
- `[home]/Desktop/Comp-Core/core/audio-media/cc-echelon/crates/echelon-bar/Cargo.toml`
- `[home]/Desktop/Comp-Core/core/audio-media/cc-echelon/crates/cc-brain/Cargo.toml`
- `[home]/Desktop/Comp-Core/core/audio-media/cc-echelon/crates/cc-brain/src/san/claim_bridge.rs`
- `[home]/Desktop/Comp-Core/core/audio-media/cc-echelon/crates/cc-brain/src/ffi.rs`
- `[home]/Desktop/Comp-Core/core/audio-media/cc-echelon/crates/femto-bridge/Cargo.toml`
- `[home]/Desktop/Comp-Core/core/audio-media/cc-echelon/crates/motion-bridge/Cargo.toml`
- `[home]/Desktop/MotionMixApp/MotionMixApp/Services/ClaimBridgeService.swift`
- `[home]/Desktop/MotionMixApp/MotionMixApp/Services/EchelonBridge.swift`

Public site (local source):
- `[home]/projects/LearnNKo/CLAUDE.md`
- `[home]/projects/LearnNKo/web/package.json`
- `[home]/projects/LearnNKo/web/src/app/claims/page.tsx`
- `[home]/projects/LearnNKo/web/src/app/technical/page.tsx`
- `[home]/projects/LearnNKo/web/src/app/nip/page.tsx`
- `[home]/projects/LearnNKo/web/src/lib/inscription/types.ts`
- `[home]/projects/LearnNKo/web/src/lib/inscription/websocket.ts`
- `[home]/projects/LearnNKo/web/src/components/inscription/live/InscriptionCard.tsx`
- `[home]/projects/LearnNKo/web/src/components/inscription/live/InscriptionStream.tsx`

Memory files:
- `[home]/.claude/projects/-Users-mohameddiomande/memory/inscription-architecture-decision.md`
- `[home]/.claude/projects/-Users-mohameddiomande/memory/plan-nko-convergence-april2026.md`
- `[home]/.claude/projects/-Users-mohameddiomande/memory/lume-nko-convergence-2026-05-02.md`
- `[home]/.claude/projects/-Users-mohameddiomande/memory/nko-cognitive-representation.md`
- `[home]/.claude/projects/-Users-mohameddiomande/memory/epoch-appchain.md`
- `[home]/.claude/projects/-Users-mohameddiomande/memory/comp-core-layers.md`
- `[home]/.claude/projects/-Users-mohameddiomande/memory/lume-femto-only-step1-step2pt1-2026-05-09.md`
- `[home]/.claude/projects/-Users-mohameddiomande/memory/lume-chain-1-phase-2-shipped-2026-05-09.md`

Public web URLs (fetched read-only):
- https://www.learnnko.com/claims
- https://www.learnnko.com/technical
- https://www.learnnko.com/nip

Comp-Core repo metadata:
- `[home]/Desktop/Comp-Core/.git` (git log, git status)

---

22. Items marked "unknown"

These were targeted but not resolvable from on-disk evidence:

• Exact run-time test count from `cargo test --no-run`. (Not executed per instructions. Static `#[test]` count = 377 markers across 46 of 51 source files. README+IMPLEMENTATION_SUMMARY cite 52 (Phase 1) and PHASE2_IMPLEMENTATION cites 268. The current 377-test figure post-dates both reports.)
• Whether the `bundle.rs` / `lowering.rs` / `chain_link/` modules will be mod-declared into `lib.rs` next session, or stay scratch. They compile in isolation but nothing public can reach them.
• Whether `learnnko.com` live WebSocket endpoint `[ip]:8765` is currently up. (Cited in `types.ts:8-12`; not contacted in this pass.)
• Site narrative says detection runs at 6 Hz; `cc-brain::claim_bridge` says 30 Hz; cc-mcs targets ~100 ms. Three rates cited, no single authoritative source on which one is "live" right now.
• The exact mapping from the 128D `dynamics_128()` slots to the `cc-brain::claim_bridge` 104D layout is documented (`claim_bridge.rs:7-22`) but how the new femto 128D vector (76..128 freed for Femto features per memory `lume-femto-only-step1-step2pt1-2026-05-09.md`) maps into either detector is not yet wired.