Lorepack

Lorepack

**Build, version, and deploy the context your AI depends on.**

Lorepack turns the files a team already trusts, such as runbooks, requirements, spreadsheets, architecture notes, specs and source-adjacent documents, into a versioned context package an AI client can read with citations.

The important part is not the search box. The important part is that context gets the same lifecycle discipline as code and infrastructure: plan it, build it, inspect it, activate it, diff it, deploy it and roll it back.

Lorepack compiles a directory of documents, spreadsheets and project artifacts into an **immutable, content-addressed build**. That build can be inspected, diffed, deployed, activated and rolled back, then read by chat models and coding agents over MCP, HTTP, or a bounded export.

Think *Git and Terraform for AI context*. It is not another local RAG server: retrieval is a runtime capability, the build lifecycle is the product.

source artifacts → plan → deterministic build → immutable version
                 → validate → activate atomically → diff / roll back


Why Lorepack exists

AI clients usually receive project context in one of three fragile ways:

1. a person pastes documents into a chat;
2. a tool searches a mutable folder or index at runtime;
3. a vector database stores chunks that are hard to inspect, diff or roll back.

Those can help a model find text, but they do not answer the release-engineering questions:

• Which exact documents did the AI see?
• Which files were excluded, and why?
• Did this spreadsheet remain a table, or was it flattened into prose?
• What changed between the context used yesterday and the context active today?
• Can a bad context update be rolled back without rebuilding?
• Can a remote runtime prove it is serving the same bu