Product
Mimir. A knowledge base that actually gets used.
Mimir is a live knowledge-base PROCESS, not a hit counter: capture a known issue once, match every future occurrence against what is already known, and disseminate the real solution automatically - across every project that hits it, not just the one that found it first. Built to replace and augment per-project Markdown KNOWN_ISSUES.md files with one central, queryable service, the same process is available to license outside UV, on the terms that fit how you work.
The Problem
A known issue in one project stays unknown to the next.
A per-project KNOWN_ISSUES.md file records what one project has already learned - but it is siloed to that file. Two projects hitting the exact same problem independently have no way to find each other's entry, no hit count, and no record of who solved it or when.
Mimir centralises that record. Every hit is reported against a real, queryable service instead of a flat file, with a scope model that decides whether an issue stays siloed to its own project or collapses across every project that hits it.
How It Works
Three steps. Keyword scoring, not embeddings.
Exact match
A scope-aware signature hash (project, category, and title, normalised and lowercased) is checked first. A match increments the existing issue's hit count and returns its solution, if one exists.
Keyword scoring
Category, title, and symptoms are tokenised and scored against a candidate pool: +1 per keyword hit, +5 for an exact category match. The highest scorer above threshold wins - pure keyword scoring, no embeddings, no vector search.
Create if new
If neither step finds a match, a new OPEN issue is created with the hit's own scope and technology tag. Bulk imports can skip Step 2 explicitly, so a historical KNOWN_ISSUES.md migration does not risk false matches.
Scope Model
Project-siloed by default. Collapsible on purpose.
- Project the default - siloed to the project that reported it. Two projects hitting the same problem independently still create two separate issues.
- General not project-specific - the same issue reported from any project collapses into one row.
- Technology siloed to a free-text technology tag instead of a project, so every project hitting the same technology-tagged issue collapses into one row.
A separate, independent many-to-many technology-tags mechanism lets an issue keep its own project and scope while also being findable alongside every other issue sharing a tag - cross the project boundary for search without disturbing how the issue itself is stored or matched.
Reporting & API
Queryable, not just recorded.
Dedup review queue
An admin-triggered scan pairwise-scores open issues within a project, and optionally across every other project, surfacing likely duplicates for a human to review and merge - never automatic.
Reopen with audit trail
A wrongly-closed issue can be reopened without editing or deleting any prior hit or solution record - an append-only reopenings table keeps the full history, including who reopened it and why.
Reports
Hot issues by hit count, a leaderboard of top reporters and solvers, a summary of open and closed counts over a time window, and a by-technology breakdown of which cross-project problem has cost the most repeated time.
Scoped API keys
Every endpoint except health requires an API key with read, write, or admin scope. A missing or invalid key returns 401; a valid key with insufficient scope returns 403.
Technology Stack
Python, FastAPI, and a real file-backed SQLite database.
No mocked database layer in tests - every test runs against a real, fresh, file-backed SQLite database, matching this org's own testing discipline.
| Runtime | Python 3.11 |
| API framework | FastAPI + uvicorn |
| Database | SQLite (stdlib sqlite3) |
| Matching | Pure keyword scoring - no embeddings, no vector search |
| Deployment | systemd unit, hardened (NoNewPrivileges, ProtectSystem=strict) |
| TLS / reverse proxy | Caddy |
Licensing & Deployment
The same process, on the terms that fit you.
We run it for you
A dedicated, isolated tenancy spun up and hosted by UV - your own knowledge base, managed infrastructure, no self-hosting overhead on your side.
Run it on your own infrastructure
The same service licensed as a self-hosted, black-box Docker container - deploy it inside your own environment, under your own infrastructure and access controls.
Draw on a growing shared pool
Paid access to UV's own ever-growing cross-project knowledge base - find solutions other teams already discovered, and contribute your own hits back into the same shared pool.
Live UV Internal Infrastructure - and Available to License
Mimir runs in production today at rotc-kb.ou-uv.com, fronted by Caddy over TLS. It is the same service UV's own governed development sessions read known issues from and report new hits to, not a roadmap item - and the same process is available to any software development firm or team working with subject-matter LLMs, on whichever licensing model above fits.
Start a Conversation