loxora

Loxora gives AI agents a local-first project memory that knows what is current, what changed or was rolled back, which projects are affected, and delivers evidence-backed context through MCP.

Comment

Loxora — Projects Should Never Lose Their Memory

Inspiration

Modern AI coding tools are powerful, but their understanding of a project is often temporary.

I work as a Product Owner but in my spare time I do some coding projects. Often smaller tools or games. I realized some issues by using different AI tools.

Important decisions become scattered across chats, Markdown files, repositories, issue trackers, and different AI tools. When a conversation ends, a model changes, or development moves to another IDE, much of the project context has to be reconstructed. As Product Owner we have even bigger issues because we have no IDE with version control and rely on the documentation, notes, boards that we write down. Knowledge is more scattered between different tools and different AI agents. But as some bigger projects have a lot of Iterations AI doesn't know all context and gets confused and I wish I had a second bigger brain sometimes. I am a writer as well and I always wanted a tool that supports my story creation and acts as a second brain that can give me hints if I made a mistake in story development but therefore it would have to remember all what was written so far and maybe across different books.

Even when information is retrieved successfully, an AI agent may not know whether it is:

  • still current,
  • already superseded,
  • rolled back,
  • only historical,
  • or merely planned for the future.

I built Loxora around a simple idea:

Projects should never lose their memory.

Instead of attaching memory to a single model, chat, IDE, or developer, Loxora treats knowledge as something owned by the project itself. Different AI agents can then reuse the same evidence-backed understanding through MCP.

What Loxora Does

Loxora is a local-first, model-independent project knowledge and context layer.

It does more than store documents or retrieve similar text. Loxora distinguishes between three temporal views:

  • Current knowledge — what should be trusted and used now
  • Historical knowledge — what was previously accepted but later superseded or reverted
  • Planned knowledge — what is intended, but not yet implemented

Every accepted change creates a new immutable revision. Previous revisions remain available together with their evidence, review decision, rationale, and lineage.

The demo follows a real project lifecycle:

  1. V1 is reviewed, accepted, and becomes Current.
  2. V2 supersedes V1.
  3. V2 creates a compatibility problem in another project.
  4. A rollback is explicitly recorded.
  5. V3 is accepted as a new restoration revision.

V1 and V2 are never deleted. V1 is not silently reactivated after the rollback. V3 becomes Current while the complete sequence remains inspectable as:

V1 → V2 → V3

This allows an AI agent to understand not only what the project currently believes, but also how and why that understanding changed.

Cross-Project Impact

Loxora also connects knowledge across projects.

In the demo, the customer-portal project consumes an authentication contract owned by the identity-contract project.

The reviewed relationship is:

customer-portal / Token Parser → DependsOn → identity-contract / Token Format

The first version of the contract requires the claim customer_id, and the consumer expects that claim.

The provider then introduces V2, replacing:

customer_id → subject_id

Loxora preserves the accepted dependency, detects that its original revision binding is now stale, and creates a revision-specific impact assessment.

The result is a High compatibility impact because the consumer still requires customer_id.

The assessment includes:

  • the exact provider revision,
  • the exact consumer revision,
  • the reviewed dependency,
  • supporting evidence,
  • confidence,
  • structured impact facts,
  • severity,
  • and freshness.

The relationship and the impact assessment remain separate. The dependency may continue to exist while an older assessment becomes stale after either project changes.

Context Packages

Loxora builds deterministic, task-specific Context Packages for AI agents.

A Context Package can contain:

  • the Current revision of a focus node,
  • related project knowledge,
  • accepted dependency paths,
  • exact applicable impact assessments,
  • evidence and source references,
  • lifecycle classifications,
  • inclusion reasons,
  • omission reasons,
  • warnings,
  • and a deterministic token-budget estimate.

Historical knowledge is excluded from Current instructions unless it is explicitly requested.

This prevents an AI agent from accidentally treating superseded or rolled-back knowledge as active truth.

The same Context Package operation is exposed through one read-only MCP tool:

loxora_get_context

This means that the local UI and an external MCP-compatible AI agent can receive the same normalized project understanding.

The demo verifies that both outputs contain the same:

  • revisions,
  • evidence,
  • dependency paths,
  • impact assessments,
  • ordering,
  • warnings,
  • and budget result.

How I Built It

Loxora is implemented as a TypeScript workspace with strict boundaries between domain logic, persistence, MCP integration, and the local demo application.

The main packages are:

  • @loxora/core — lifecycle rules, navigation, relationships, impact assessments, Planned Knowledge, and Context Package generation
  • @loxora/sqlite — local persistence, migrations, transactions, integrity constraints, and immutable records
  • @loxora/mcp — the read-only loxora_get_context stdio tool
  • @loxora/demo — deterministic fixtures, local Node server, React/Vite interface, guided demo, and MCP parity proof

SQLite stores project-owned knowledge locally.

The Core package remains independent of SQLite and exposes asynchronous ports. This keeps the system model-independent and allows the persistence implementation to be replaced later.

The browser never accesses SQLite directly. It communicates with a small local application server that delegates all important operations to the existing Core services.

The UI offers two modes:

Guided Demo

A nine-step presentation flow:

  1. Establish project knowledge
  2. Connect the projects
  3. Introduce a breaking change
  4. Assess cross-project impact
  5. Record the rollback
  6. Restore compatible knowledge
  7. Compare Current, History, and Planned
  8. Build a task-specific Context Package
  9. Verify MCP parity

The server determines which actions are currently valid. The browser cannot authorize reviews, rollbacks, restorations, impact assessments, Context Packages, or MCP behavior on its own.

Explore Mode

Users can freely inspect:

  • Projects
  • Spaces
  • Collections
  • Knowledge Nodes
  • Evidence
  • Sources
  • Current revisions
  • Historical lineage
  • Planned Knowledge
  • Dependencies
  • Impact assessments
  • Context Packages

The complete demo can be reset to a deterministic starting state, making the scenario reproducible for development, testing, judging, and presentation.

Challenges

Modeling Change Without Rewriting History

The first major challenge was ensuring that accepted knowledge could never be edited in place.

Supersession, rollback, and restoration had to remain separate concepts.

A rollback could not simply move Current back to V1 because that would hide the fact that V2 existed and was later rejected as the desired direction.

The solution was to use immutable revisions together with explicit predecessor, supersession, rollback, restoration, and restored-from relationships.

Separating Relationships From Impact

A dependency and an impact assessment are not the same thing.

The relationship records that one project depends on another. An impact assessment describes the consequences of one exact provider and consumer revision pair.

This distinction allows a relationship to remain accepted while an older impact assessment becomes stale.

Preventing Stale Context

A memory system becomes dangerous when historical information is presented as current truth.

Loxora derives Current exclusively from explicit Current pointers. Historical revisions are returned only through History queries or explicit historical Context Package requests.

Impact assessments are selected only when their provider and consumer revisions match the revisions selected for the current task.

Preserving Evidence and Ownership Across Projects

Cross-project records require more than two node identifiers.

Loxora validates the owning project, node, scope, revision, evidence, visibility, and relationship direction. A relationship may describe two projects, but it never silently changes the canonical knowledge of either project.

Deterministic Context Generation

Context selection had to be repeatable and explainable.

Loxora uses:

  • explicit selection priorities,
  • bounded one-hop dependency traversal,
  • stable ordering,
  • deterministic deduplication,
  • inclusion and omission reasons,
  • and a provider-independent budget estimator.

Identical project state and structured input produce the same normalized Context Package fingerprint.

Explaining a Complex Lifecycle in a Short Demo

The underlying lifecycle is more complex than a typical memory demo.

The final UI therefore shows one server-authorized next action at a time. After each real transition, it explains:

  • what became Current,
  • what remained Historical,
  • which other project was affected,
  • which evidence supports the result,
  • and what the next step proves.

What I Learned

The most important lesson was that project memory is not primarily a retrieval problem.

Useful project memory also requires:

  • lifecycle semantics,
  • provenance,
  • evidence,
  • review,
  • temporal separation,
  • cross-project relationships,
  • impact awareness,
  • and deterministic context assembly.

Retrieving a document is not enough if an AI agent cannot tell whether that document is current, superseded, restored, rejected, historical, or planned.

I also learned that MCP becomes more valuable when it exposes a shared, project-owned context operation instead of another model-specific chat integration.

The Loxora UI and MCP tool both use the same Context Package service, allowing different AI agents and interfaces to receive the same evidence-backed understanding.

Current Scope and Future Work

The Hackathon version is intentionally local and bounded.

It demonstrates:

  • reviewed and immutable project knowledge,
  • Current, Historical, and Planned separation,
  • supersession,
  • rollback and restoration,
  • cross-project dependencies,
  • revision-specific impact assessments,
  • progressive project navigation,
  • deterministic Context Packages,
  • a read-only MCP tool,
  • and a reproducible guided demo.

Future work includes:

  • deterministic full-project export and reconstruction,
  • generalized repository import,
  • authentication and team permissions,
  • synchronization,
  • broader search,
  • additional relationship types,
  • and production deployment.

The current version proves the foundation:

AI agents should not just remember project information. They should understand what is true now, what changed, why it changed, and what else is affected.

Built With

Share this project:

Updates