Aerie Meets Sanity Context: A Ledger-Native Bridge Between an Offline Cognitive System and a Live Knowledge Base

Four ledger tiers, nine pipeline steps, one worked example — proving the round trip is auditable end-to-end, not just diagrammed.

What Aerie Is

Aerie (internal build name for the Library Ground Cognitive Engine) is an offline, ledger-native cognitive system. It runs terminal-native — PowerShell on Windows 10, with an inactive Rust reference workspace alongside it — not a browser GUI. Its reasoning rests on three codex layers plus one access layer:

• English Codex — nouns, verbs, tense (was/is/will be), queried by every organ
• MET Codex — formalized physics/math equations the system reasons against
• Codex Source — a grid/data-table ("boxes") access structure so anything can be reached uniformly
• Evidence grid — a line-column coordinate layer over the codexes, so every fact is traceable

The core rule: anything an organ builds from the codex must continuously re-ground against the codex, not check once and move on. New material goes to a separate Expansion Ledger — the core ledger stays untouched.

Four organs sit on top of this:

Organs coordinate over a separate machine-language protocol, kept apart from the human-facing linguistic layer, so internal coordination never throttles the user-facing system.

Organ Architecture

graph LR
    User((User)) <--> Herald

    subgraph Aerie["Aerie — offline core"]
        Herald
        Meridian
        Cairn
        Forge
        Herald <-->|machine protocol| Meridian
        Herald <-->|machine protocol| Cairn
        Herald <-->|machine protocol| Forge
        Meridian <-->|machine protocol| Cairn
        Meridian <-->|machine protocol| Forge
        Cairn <-->|machine protocol| Forge
    end

    Herald -.->|NEW: proposed| Gateway[/The Gateway/]
    Gateway -.->|NEW: proposed| Sanity[(Sanity Context MCP)]

    style Gateway stroke-dasharray: 5 5
    style Sanity stroke-dasharray: 5 5

Only Herald knows the Gateway exists — it stays consistent with Herald being the sole externally-facing organ.

The Gateway: What's New, What's Not

Not built: The Gateway. Everything above it — Herald, Meridian, Cairn, Forge, the codexes, the ledger discipline — is the real, already-built system.

Proposed: A bridge sitting between Herald and the outside network, giving Herald exactly one new fallback path, in two directions:

1. Export a bounded Codex slice up to a Sanity Knowledge Base.
2. Forward a structured query out, and a structured result back, when the local ledger alone falls short.

It changes nothing about how the four organs behave. It's an edge off Herald, not a new organ.

Pipeline Sequence — Nine Steps

sequenceDiagram
    participant U as User
    participant H as Herald
    participant M as Meridian
    participant G as Gateway
    participant S as Sanity Context MCP

    Note over H,S: Step 1 — Codex export (bounded slice, ≤150 docs, beta cap)
    H->>S: tagged JSON docs (organ-of-origin, subject, line/col)

    U->>H: Step 2 — asks a question
    H->>H: Step 3 — formalize via linguistic codex
    H->>M: Step 4 — check local ledger first
    M-->>H: local coverage: thin / contradictory

    H->>G: Step 5 — forward structured query
    G->>S: structured query over WiFi
    S-->>G: Step 6 — matched entries + source links + contradictions
    G-->>M: Step 7 — remote entries handed to Meridian
    M->>M: audit against local codex (existing re-grounding rule)

    M-->>H: audited answer
    H-->>U: Step 8 — relay answer, cite local + remote sources
    H->>M: Step 9 — write answer + provenance to ledger

Worked Example

Question: "What was Forge's last clarification request, and does the codex now define that term?"

Tier 1 — System Ledger (existing, offline, pre-network)

Meridian's normal dataset-pointer behavior, before any Gateway hop:

{
  "ledger_tier": "system",
  "organ": "Meridian",
  "query": "forge_last_clarification_term_status",
  "pointer": { "codex": "English Codex", "line": 412, "column": "definition" },
  "result": "no_entry",
  "confidence": "local_coverage_thin"
}

Tier 2 — Connected-System Ledger (Sanity's own provenance, in Aerie's vocabulary)

Sanity Context's "every entry stays linked to its source" behavior, framed as a ledger tier — structurally symmetrical to Aerie's own, not borrowed:

{
  "ledger_tier": "connected_system",
  "source_system": "Sanity Context MCP",
  "matched_entries": [
    { "id": "kb-0071", "term": "agent", "source_link": "<SANITY_DATASET_URL>#doc-0071", "defines_query_term": true },
    { "id": "kb-0088", "term": "agent (contradicting draft)", "source_link": "<SANITY_DATASET_URL>#doc-0088", "defines_query_term": true, "contradicts": "kb-0071" }
  ],
  "contradictions_surfaced": true
}

Tier 3 — Step Ledgers (nine entries, each referencing the prior step's output field)

{ "step": 1, "organ": "Herald", "action": "codex_export",
  "output": { "doc_count": 147, "cap": 150, "tag_fields": ["organ_of_origin","subject","line_col"] } }

{ "step": 2, "organ": "Herald", "action": "receive_question",
  "input_ref": "user_utterance_id:q-2291",
  "output": { "raw_query": "forge_last_clarification_term_status" } }

{ "step": 3, "organ": "Herald", "action": "formalize_via_linguistic_codex",
  "input_ref": "step2.output.raw_query",
  "output": { "structured_query": { "subject": "Forge", "attribute": "last_clarification_term", "check": "codex_definition_exists" } } }

{ "step": 4, "organ": "Meridian", "action": "check_local_ledger",
  "input_ref": "step3.output.structured_query",
  "output": { "pointer": { "codex": "English Codex", "line": 412, "column": "definition" }, "result": "no_entry", "coverage": "thin" } }

{ "step": 5, "organ": "Gateway", "action": "forward_structured_query",
  "input_ref": "step4.output",
  "output": { "forwarded_query": "step3.output.structured_query", "endpoint": "Sanity Context MCP" } }

{ "step": 6, "organ": "Sanity Context MCP", "action": "return_matches",
  "input_ref": "step5.output.forwarded_query",
  "output": { "matched_entries": ["kb-0071", "kb-0088"], "contradictions_surfaced": true } }

{ "step": 7, "organ": "Meridian", "action": "audit_remote_against_local_codex",
  "input_ref": "step6.output.matched_entries",
  "output": { "kb-0071": "consistent_with_local_codex", "kb-0088": "flagged_conflicting_draft", "audited": true } }

{ "step": 8, "organ": "Herald", "action": "relay_to_user",
  "input_ref": "step7.output",
  "output": { "answer": "Forge's last clarification named 'agent' as the unclear term; Sanity's kb-0071 now defines it, with kb-0088 flagged as a conflicting draft.", "cites": ["local:line412", "<SANITY_DATASET_URL>#doc-0071"] } }

{ "step": 9, "organ": "Meridian", "action": "write_back_to_local_ledger",
  "input_ref": "step8.output.answer",
  "output": { "written_to": "Expansion Ledger", "new_pointer": { "codex": "English Codex", "line": 413, "column": "definition" } } }

Ledger-Chain

graph TD
    T1[Tier 1: System Ledger] --> S4[Step 4: local check]
    S1[Step 1: codex export] --> T2[Tier 2: Connected-System Ledger]
    S2[Step 2: question] --> S3[Step 3: formalize]
    S3 --> S4
    S4 -->|thin coverage| S5[Step 5: forward]
    S5 --> S6[Step 6: Sanity returns matches]
    T2 --> S6
    S6 --> S7[Step 7: Meridian audits]
    S7 --> S8[Step 8: Herald relays]
    S8 --> S9[Step 9: write-back]
    S9 --> T4[Tier 4: Combined Ledger]
    T1 --> T4
    T2 --> T4

Combined Ledger

One artifact. Paste into a spreadsheet or diff tool and audit the whole round trip start to finish:

{
  "combined_ledger": {
    "tier_1_system": {
      "organ": "Meridian",
      "pointer": { "codex": "English Codex", "line": 412, "column": "definition" },
      "result": "no_entry"
    },
    "tier_2_connected_system": {
      "source_system": "Sanity Context MCP",
      "matched_entries": [
        { "id": "kb-0071", "source_link": "<SANITY_DATASET_URL>#doc-0071" },
        { "id": "kb-0088", "source_link": "<SANITY_DATASET_URL>#doc-0088", "contradicts": "kb-0071" }
      ]
    },
    "tier_3_steps": [
      { "step": 1, "organ": "Herald", "output": { "doc_count": 147 } },
      { "step": 2, "organ": "Herald", "output": { "raw_query": "forge_last_clarification_term_status" } },
      { "step": 3, "organ": "Herald", "output": { "structured_query": { "subject": "Forge", "check": "codex_definition_exists" } } },
      { "step": 4, "organ": "Meridian", "output": { "result": "no_entry", "coverage": "thin" } },
      { "step": 5, "organ": "Gateway", "output": { "endpoint": "Sanity Context MCP" } },
      { "step": 6, "organ": "Sanity Context MCP", "output": { "matched_entries": ["kb-0071", "kb-0088"] } },
      { "step": 7, "organ": "Meridian", "output": { "kb-0071": "consistent", "kb-0088": "flagged_conflicting_draft" } },
      { "step": 8, "organ": "Herald", "output": { "cites": ["local:line412", "<SANITY_DATASET_URL>#doc-0071"] } },
      { "step": 9, "organ": "Meridian", "output": { "written_to": "Expansion Ledger", "new_pointer": { "line": 413 } } }
    ],
    "tier_4_status": "round_trip_complete"
  }
}

Why This Only Works Because the Content Is Structured

A keyword search over the Codex could not produce Step 7 or Step 9. Auditing a remote answer against a local codex (Step 7) requires both sides to expose addressable, coordinate-referenced entries — not prose to be re-parsed. Writing a remote answer back as new local structured content (Step 9) requires a target schema to write into — a line/column slot, not a text blob. The diagrams and the ledger entries above are the proof; this section is just the pointer to them.

`