N'Ko Inscription System — Design Document

N'Ko Inscription System — Design Document

Version: 1.0.0
Last Updated: 2026-01-03

---

Overview

The N'Ko Inscription System compiles embodied dynamics (z-trajectory from DELL) into justified N'Ko statements with cryptographic provenance. Every inscription is traceable to its source evidence through a typed IR pipeline.

Design Principle: The N'Ko surface is a controlled technical register using sigils (single N'Ko characters) as operator markers. This keeps the system deterministic and learnable. Natural-language N'Ko phrasing can be layered on later once the lexicon is settled by usage.

Line Skeleton: `⟨operator-sigil⟩ ⟨time-marker⟩ : ⟨claim-body⟩ ; ⟨slots⟩`

---

Architecture

┌─────────────────────────────────────────────────────────────────────┐
│                     INSCRIPTION PIPELINE                             │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  z_{t-k:t}  ──┬──►  ClaimDetector  ──►  Typed IR  ──►  N'Ko Line    │
│              │           │                  │              │         │
│  place ──────┤     ┌─────▼─────┐      ┌────▼────┐    ┌────▼────┐    │
│              │     │ 10 Claim  │      │ Lexicon │    │ Surface │    │
│  slice_id ───┘     │ Detectors │      │ (vN)    │    │ Render  │    │
│                    └─────┬─────┘      └────┬────┘    └────┬────┘    │
│                          │                 │              │         │
│                    ┌─────▼─────────────────▼──────────────▼────┐    │
│                    │           PROVENANCE CHAIN                │    │
│                    │  Evidence → IR → Surface → Proof Scaffold │    │
│                    └───────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────────────────┘

---

The 10 Claim Types

Each claim has: a typed IR structure, a canonical N'Ko line form, and a specific sigil.

---

Canonical N'Ko Line Forms

Claim 1: Stabilization (ߛ)

ߛ ⟦t0–t1⟧ : z(σ) ↓ ; ⟦place⟧ ; c=⟦conf⟧

"Within this window, dispersion decreased measurably"

Claim 2: Dispersion (ߜ)

ߜ ⟦t0–t1⟧ : z(σ) ↑ ; ⟦place⟧ ; c=⟦conf⟧

"Spread increased"

Claim 3: Transition (ߕ)

ߕ ⟦t*⟧ : ⟦B_from⟧ → ⟦B_to⟧ ; κ=⟦sharp⟧ ; c=⟦conf⟧

"Curvature spike + state delta at timestamp t*"

Claim 4: Return (ߙ)

ߙ ⟦t*⟧ : ↺ ⟦B⟧ ; last=⟦Δt⟧ ; d=⟦dist⟧

"You re-entered basin B"

Claim 5: Dwell (ߡ)

ߡ ⟦t0–t1⟧ : stay(⟦B⟧)=⟦τ⟧ ; ϕ=⟦stab⟧

"You stayed in basin B long enough to matter"

Claim 6: Oscillation (ߚ)

ߚ ⟦t0–t1⟧ : ⟦B1⟧ ⇄ ⟦B2⟧ ; f=⟦freq⟧ ; a=⟦amp⟧

"Ping-pong between basins"

Claim 7: Recovery (ߞ)

ߞ ⟦t*⟧ : rec→⟦B⟧ ; τ=⟦lat⟧ (×⟦ratio⟧)

"Control theory: how long to recover"

Claim 8: Novelty (ߣ)

ߣ ⟦t*⟧ : new⟦P⟧ ; d*=⟦dist⟧ ; k=⟦support⟧

"We need a new word" - region not covered by existing tokens

Claim 9: Place-Shift (ߠ)

ߠ ⟦t*⟧ : ⟦P_from⟧ → ⟦P_to⟧ ; ↪ ⟦claim_sigil⟧ ; c=⟦conf⟧

"This place shift drove/paired with another claim"

Claim 10: Echo (ߥ)

ߥ ⟦t0–t1⟧ : ≈ ⟦E#⟧ ; sim=⟦s⟧ ; refs=⟦n⟧

"I've seen this movie" - controlled recall within slice

---

Basin Lifecycle

Basins are hypotheses the machine bets its consistency on. Each basin has an origin, stability phase, possible refinement, and eventual persistence or retirement.

Basin States

┌──────────────┐     graduation      ┌──────────────┐
│  ProtoBasin  │ ─────────────────►  │    Basin     │
│  (scratch)   │     criteria met    │  (identity)  │
└──────────────┘                     └──────┬───────┘
       │                                    │
       │ expires                            ├─── split ──► [Child₁, Child₂]
       ▼                                    │
┌──────────────┐                            ├─── merge ──► Parent
│   Retired    │ ◄──────────────────────────┤
│  (spurious)  │      retirement            │
└──────────────┘                            │
                                            ▼
                                    ┌──────────────┐
                                    │   Retired    │
                                    │ (real-gone / │
                                    │  coord-shift)│
                                    └──────────────┘

Graduation Criteria

A proto-basin becomes a basin when it earns three independent persistence signals:

1. Re-entry: Return visits across separate sessions/day partitions (min 3)
2. Low Dispersion: Internal dispersion vs global ratio ≤ 0.3
3. Transition Consistency: Entry/exit pattern consistency ≥ 0.7

Split Rules

A split is NOT "I realized there are two kinds." It's:
> "The distribution is demonstrably multi-modal in a way that predicts different downstream dynamics."

Two subclusters that look different but lead to same transition behavior = ornamental complexity, refuse split.

Merge Rules

A merge is NOT "these names feel redundant." It's:
> "Two basin keys have become empirically indistinguishable within measurement resolution."

Reasons: Sensor coverage changed, contexts abandoned, behavior converged.

Retirement Types

---

Lexicon Versioning

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

What Evolves vs What's Stable

Lexicon Change Types

pub enum LexiconChange {
    BasinAdded { id: BasinId, [sensitive field redacted],
    BasinRenamed { id: BasinId, old_token: String, new_token: String },
    BasinSplit { parent: BasinId, children: [BasinId; 2] },
    BasinMerged { absorbed: Vec<BasinId>, into: BasinId },
    BasinRetired { id: BasinId, retirement: RetirementType },
    PlaceClassAdded { class: PlaceClass, [sensitive field redacted],
    PhraseRegistered { phrase: Phrase },
}

---

Phrase Emergence

A phrase is a compressible macro over claim sequences. Earned only when it improves description length without loss of predictive structure.

Example: Arrival Turbulence

Old (3 lines):

ߠ ⟦t*⟧ : home → office ; ↪ ߕ ; c=0.8
ߜ ⟦t0–t1⟧ : z(σ) ↑ ; office ; c=0.7
ߚ ⟦t1–t2⟧ : B₁ ⇄ B₂ ; f=3.2 ; a=0.4

New (1 line with phrase):

⟨arrival-turbulence⟩ ⟦t*–t2⟧ : home→office ; B₁⇄B₂

The day becomes a "score" - structured, replayable, compressive.

---

Integration Points

### Graph Kernel
- Input: Slice fingerprint for Echo claim evidence
- Output: Admissibility token for provenance
- Governance: Ontology operations declare consulting slice

### RAG++
- Input: Query for pattern matching
- Output: Similar episodes within admissible slice
- Role: Supply nearest-neighbor episodes for ontology evaluation

### DELL
- Input: Subscribe to z-trajectory stream
- Output: z(t) embeddings at consistent intervals
- Role: Source of all claim detection

---

Security Model

### Provenance Chain
Every inscription includes:
- `claim_id`: Unique claim identifier
- `evidence_ref`: Source z-window or slice_id
- `lexicon_version`: Which vocabulary was used
- `graph_snapshot_hash`: Immutability proof
- `admissibility_token`: Graph Kernel authorization (for Echo claims)

### Trust Boundaries
- DELL is trusted for z-trajectory
- Graph Kernel is trusted for admissibility
- Inscription system is trusted for detection and rendering
- N'Ko surface is a derived view, not authoritative