Finally, humans and agents see the same picture
Navon (Hebrew: נָבוֹן — "wise, discerning") is a self-hosted knowledge base built on a single premise: what your AI agents know should not be a black box to your team. Before Navon that knowledge lives in scattered chunks, unreadable context windows, and drift — invisible and unaccountable. Navon turns it into one structured, navigable picture that a technician and an agent can both open, read, and trust.
THE PROBLEM IT SOLVES
Every knowledge base today fails one of its two audiences. Human-facing tools — Notion, GitBook, BookStack, Confluence — treat AI agents as an afterthought: a bolt-on MCP endpoint with no trust model, no provenance, and no cost controls. Agent-facing stores — vector databases, RAG pipelines, wiki dumps — give humans no navigable, trustworthy interface at all. You end up maintaining two corpora, and they drift apart the moment either side is edited.
For a DevOps team this is not an annoyance, it is an operational hazard. An agent answers a runbook question from a stale chunk; a technician updates the same runbook in the wiki; the alert fires and the two sources disagree. Navon removes the fork: humans and agents read and write the same markdown canon, with one access model, one audit trail, and one retrieval path.
HOW IT WORKS
Markdown is the single source of truth. Every page is a Markdown document with linted frontmatter. Chunks, embeddings, links, claims, and graph edges are all derived artifacts — disposable, rebuildable from the markdown at any time, and carrying no permissions of their own. Lose the entire index? Rebuild it. Nothing is trapped in a proprietary store.
Retrieval that tells the truth about itself. The pipeline is hybrid: Postgres full-text search and pgvector run in parallel, fuse with reciprocal rank (RRF), then a bounded rerank, hub-rescue, and parent-document expansion. Every query joins the live access row, so authorization is enforced inside the query path — derived artifacts never leak across tenants. And every result carries the honesty fields an agent actually needs:
| Field | What it tells the caller |
|---|---|
| sources[] | Every citation, with its trust_level and review state — human > agent > imported > external |
| disagreements[] | Where two pages contradict each other — surfaced, never silently merged |
| low_confidence | Explicit flag when the corpus does not actually support an answer |
| considered / truncated | How much was searched and whether results were cut — "no answer" is distinguishable from "no search" |
| stale_sources[] | Citations past their review window — visible, not hidden |
The result is a grounding pack, not a guess: the answer tool does deterministic retrieve → rerank → assemble, so an agent can say "the canon says X, from these three pages, one of which is stale" — and a human can see exactly why.
Lexical degrades, it never breaks. If the embedding service or the model hub is down, the system falls back to full-text search as a fully functional path — not an error page. Same principle everywhere: degrade, never block.
LIVING KNOWLEDGE, NOT A DOCUMENT GRAVEYARD
Most wikis rot because nothing measures staleness and nothing owns the fix. Navon treats knowledge as a managed lifecycle:
Review windows and verification as a ranking signal. Pages carry a review_due date and a review state — fresh, verified, stale, or disputed. Verification is not a decorative badge: it feeds the ranking, so a verified page outranks an unverified one on the same query. When a review date passes, the escalation ladder fires — reminder, then the space owner's queue, then escalation. Content is never auto-hidden or auto-edited; humans stay in the loop, and the consequence of neglect is visibility to an owner, not a broken link.
Conflict findings instead of silent merges. Whole-corpus near-duplicate detection, external drift signals, and agent-reported conflicts all land in a findings queue with an owner — they become Gitea issues, and fixes ship through normal review. The KB cannot quietly contradict itself.
Provenance you can audit. Every write is stamped with a trust level at ingest. Every revision is immutable and attributed — create, manual, agent, sync, or sync-conflict. Ingest sanitises on the way in and reports what it removed, so a destructive edit is a defect you can see, never a silent corruption.
Git as a first-class citizen. Each space materialises deterministically into a git tree with a recorded digest and publishes on a ref with an auditable record. The markdown canon round-trips with version control; your knowledge base inherits the same review, diff, and rollback discipline as your code.
BUILT FOR AGENTS FROM THE FIRST LINE
The agent surface is not a wrapper around a REST API — it is the primary interface. Navon speaks MCP on the 2026-07-28 spec: stateless, server/discover, multi-round-trip human input, and long-running task polling, all via the official Go SDK. The tool set is deliberately small and composable:
| Surface | What agents get |
|---|---|
| answer | The grounding pack — retrieve, rerank, assemble, with citations and honesty fields |
| search | Raw hybrid hits (keyword / semantic / hybrid) when an agent wants to reason itself |
| list_tree · read_file · grep | Filesystem primitives over the canon — exact, staleness-free access |
| get_page · get_entity · get_graph | Progressive disclosure: outline, properties, entity record, one-hop neighbourhood |
| create_page · update_page · add_comment · verify_page · report_conflict | Gated writes with provenance stamping, idempotency keys, and optimistic concurrency |
Agent identity is first-class, not shared credentials. Each agent is its own principal with scoped tokens, per-agent quotas, and cost attribution. Every space carries a publishers allowlist — the "an agent must not poison the KB" guardrail implemented as a server-side rule rather than a convention. Knowledge agents can draft; only permitted publishers promote. Three MCP surfaces keep it honest: /mcp for the full toolset, /mcp/readonly for read-only automation, and /mcp/curate for the consolidation and curation lane.
A KNOWLEDGE GRAPH THAT IS A NAVIGATION SPINE
Relations in Navon are typed and ontology-driven — every relation type carries its colour, direction, and allowed source/target types, and participates in a containment axis. Hierarchy is modelled as multiple axes (containment, type, role, tag) rather than one brittle tree. From structured pages, Navon extracts claims — (subject, predicate, object) facts with a source span back into the markdown — and builds an entity graph of the hosts, services, people, and credentials your knowledge talks about.
Unlike a graph bolted onto a RAG pipeline, this one is anchored: every claim traces to the exact passage that produced it, and the whole graph is a rebuildable index over the markdown — not a separate store that can drift. That makes questions like "what else references this service" or "which runbooks touch this host" answerable in one hop, with citations.
DESIGN PRINCIPLES WE HOLD OURSELVES TO
| Principle | What it means in practice |
|---|---|
| Markdown is canonical | Every derived artifact is disposable and rebuildable — no lock-in, no unrecoverable index |
| Authorize in-query | Derived artifacts carry no permissions; every query joins the live access row |
| Degrade, never block | Lexical-only is a first-class mode; a service outage slows enrichment, it does not stop the KB |
| No silent data loss | Patches and imports report exactly what they removed; ingest reports what it sanitised |
| Record, don't infer | Every health signal can legitimately read zero — no fabricated confidence |
| Simple topology | Four services by default. No worker tier, no separate search service, no cache service |
WHERE IT STANDS
Demo coming soon
The core is built and running: the navigation and reading shell, the source-first editor, the hybrid retrieval pipeline, the MCP agent surface, the housekeeping core (freshness, lifecycle, lineage), knowledge-graph extraction, and git materialisation. In flight: inbound sync hardening. Planned to v1 GA: quality scoring and findings, harness integration, the BookStack importer, and the public migration path.
We are preparing a public demo instance with a realistic seeded corpus so you can navigate the tree, run retrieval, watch provenance and staleness markers in action, and connect your own agent to it over MCP. It is not public yet — we would rather show you something that works than something that almost does.
If a shared human-plus-agent knowledge base is on your roadmap, talk to us — the design conversations are usually the useful part, and early feedback shapes the demo.
Two readers. One source of truth.
If your agents and your team are reading from different wikis — or the same wiki in different ways — let's talk about what a single canon looks like for your stack. Self-hosted, documented, handed over.