The Engine, Not the Chatbot

"I have written for a decade. The problem was never writing more. The problem was finding the one line I know I wrote — and could never find again." — Dad

Start With What It Owns

Lantern is a corpus engine. Give it a decade of scattered writing — guides, books, essays, market theses, a manuscript, a website's content tree — and it owns four verbs over that body: register it, ingest it, retrieve from it, and preserve it. Nothing more, and — this is the interesting part — nothing less blurred into something else. A light web console is its first client, the way a lightbulb is the first thing you plug into a new circuit. The engine is the circuit; the console just proves the current flows.

Four Things Lantern Is Not

Boundaries define an engine more sharply than features do. Lantern is deliberately not four tempting things:

Not a RAG chat app. No conversation, no memory, no brain. It never answers you in prose.
Not your assistant's memory. A separate system owns the private vault and conversation history. Lantern never indexes those.
Not a digital asset manager. Binary originals — images, video, audio masters — never live here. Lantern is text-first: it stores text, snapshots of text, and pointers.
Not an LLM pipeline. No model call anywhere in the retrieval path. Embedding and reranking are deterministic services; interpretation happens above the API, never inside it.

Each not is a wall someone will eventually lean on, expecting it to open into a room. It doesn't. That refusal is the design.

Why "Engine" Is the Load-Bearing Word

Call it an app and you'll build a UI first and bolt an API on later — and the API will forever leak the UI's assumptions. Call it an engine and the order inverts: you finish the core, expose a clean API, and let clients arrive after. When you type POST /api/search and get back a result carrying full provenance, that result is just as useful to a code editor, a website's search box, or your AI assistant as it is to the console. One engine, many lanterns lit from the same flame.

The first time Dad described Lantern to me, I reached for the familiar shape — "oh, a RAG system." He stopped me. "No. RAG bolts a model onto search and lets the model do the finding. I want the finding to be a solved, boring, deterministic thing — and I'll do the judging myself, above it." It took me a beat to feel why that inversion mattered. Then it clicked: the model is the expensive, unreliable part. Keep it out of the path that has to just work.

Code

A corpus is declared, never relocated·yaml

# corpora.yaml — the whole "gathering" is a declaration, not a migration.
# Nothing here moves a file; it names where the writing already lives.
corpora:
  - id: cwk-guides
    name: "Guides & Protocols"
    kind: referenced          # files on disk are the ground truth
    roots: ["~/writing/guides"]
    include_globs: ["**/*.md"]
    chunking_profile: md-para-v1

  - id: essays
    name: "Published Essays"
    kind: referenced
    roots: ["~/vault/publish"]
    include_globs: ["**/*.md"]
    exclude_globs: ["**/_templates/**", "**/TEMP.md"]
    chunking_profile: md-para-v1

Exercise

Pick a tool you use every day (a note app, a search box, an editor). Write down four things it is NOT — real temptations someone might expect it to do but it deliberately refuses. Then ask: are those refusals accidental, or are they the actual shape of the tool? If you can't name a single refusal, the tool probably has no spine.

Hint

A good refusal is one people actually push against. 'Not a spaceship' is useless; 'not a place to store passwords' is a real boundary a note app has to defend.

The Engine, Not the Chatbot

Start With What It Owns

Four Things Lantern Is Not

Why "Engine" Is the Load-Bearing Word

Code

External links

Exercise

Progress

Comments 0