Lantern Keeper

Inspiration

Lantern Keeper started from a very practical problem: when work moves between ChatGPT, Codex, editors, local tools, and future assistants, the human often becomes the memory bus. I repeatedly found myself explaining the same project decisions, copying context between tools, and trying to reconstruct where an old idea or decision originally came from.

The goal is not to make an AI remember everything forever. The goal is to build a reliable local map back to the source material that matters.

What it does

Lantern Keeper is a local-first shared memory system for AI-assisted software work. Its first service, Lighting, stores source material, marks meaningful episodes inside that source, connects those episodes to projects and markers, and can retrieve the original source range when a remembered phrase is searched later.

The first proof is deliberately narrow:

• register a Markdown source
• create an exact byte-range episode inside it
• create a project and marker
• associate the episode with the project and marker
• retrieve the matching episode from a vague remembered phrase
• return the exact source reference and excerpt so the assistant can reread the real context

This is aimed at reducing the repeated copy-and-paste loop between ChatGPT, Codex, and local development work.

How we built it

Lantern Keeper is built as a Rust workspace with a clean inward dependency structure:

• lighting-core defines the domain types and repository traits
• lighting-store-surreal implements durable SurrealDB storage
• lighting-service exposes a localhost-only HTTP API using Axum
• lighting provides the runnable binary
• PowerShell scripts start/check SurrealDB and run the first-proof demo

SurrealDB is used as the durable local store because the long-term shape of the project is naturally graph-like: sources, episodes, projects, markers, relationships, and eventually richer retrieval paths.

Codex was used throughout the build to turn the project plan into a working Rust service skeleton, implement repository and route layers, add integration tests, check API behaviour, and keep the scope honest when the idea wanted to expand too quickly.

GPT-5.6/Codex usage is part of the project story: the build process itself is a test case for the problem Lantern Keeper is trying to solve, because the project exists to preserve and transfer useful working context between AI-assisted sessions.

Current build status

The repository currently includes:

• Rust Cargo workspace
• localhost-only Lighting service
• health and version endpoints
• Source API for storing and fetching Markdown/text sources
• Project API
• Marker API with normalized lookup
• Episode API using exact byte ranges
• episode-to-project and episode-to-marker associations
• marker-based retrieval endpoint
• SurrealDB schema and repository tests
• service integration tests
• a first-proof demonstration script using a small Markdown fixture

The submission is still being finalized. The remaining deadline work is to make the demo path easy for judges to run, record the video, polish the README, and verify the exact /feedback session ID for the main Codex build thread.

Challenges

The main design challenge was restraint. A shared memory layer could easily become a giant archive, a chat sync tool, or an over-complicated AI database. I kept returning to one question: what is the smallest useful proof that shows the system can find the right original context later?

The technical challenges were also practical ones:

• preserving exact source ranges instead of relying on vague summaries
• keeping the domain layer independent of SurrealDB and HTTP
• making local-only defaults explicit
• using durable storage without making tests fragile
• deciding what not to build yet

Accomplishments that we're proud of

The project now has a real backend shape rather than only a concept. It can store source material, create durable records, associate memory markers with episodes, and return source-backed context from a retrieval-style query.

I am especially happy that the implementation is test-led and local-first. The service does not require a cloud account, does not bind to public interfaces, and treats the original source as the authority rather than pretending a summary is enough.

What we learned

The strongest version of this idea is not a system that remembers more. It is a system that helps an assistant reread the right thing at the right time.

I also learned that the project needs hard boundaries early: no automatic ingestion, no embeddings, no GUI, no connectors, no permanent-memory magic until the central retrieval loop works and is boringly testable.

What's next

Before the final submission deadline:

• verify the end-to-end first-proof demo on a clean run
• update the README with judge-friendly setup steps
• record a short demo video showing the source-to-episode-to-marker retrieval loop
• add the Codex /feedback session ID
• confirm the repository visibility/access requirements

After Build Week, the next steps are richer retrieval, context packages tailored differently for ChatGPT and Codex, and eventually integrations that let AI tools ask Lantern Keeper for relevant local project context directly.

Built With

• axum
• clap
• codex
• gpt-5.6
• powershell
• rust
• surrealdb
• tokio