Ontology Atlas

Understand your system as AI agents change its code.

_{Give agents task context. Inspect the meaning, evidence, and unknowns yourself.}

Download for macOS · Windows x64 beta _unsigned · Live demo · Guide · Status

Ontology Atlas MCP server on Glama

_{The installed macOS app reading samples/storefront — an online store described by Markdown files in a folder. Meaning changes remain visible in files and Git diffs for a person to inspect, correct, reject, or keep; the feature inventory is the current behavior contract.}

In 30 seconds

When an agent finishes a change, you still need to judge what it understood, which rules matter, and what needs your attention. File lists and the producing agent's summary are starting points; they do not by themselves establish that the system's meaning or boundaries were preserved.

Atlas keeps those answers in an atlas/ folder of Markdown inside the repository, so meaning is cloned, branched, and reviewed with the code. Each file's frontmatter declares what it is — project, domain, capability, element, or a linked document — and what it points at. That folder is the whole database.

Atlas compiles that folder into a typed graph. Your coding agent can request context for a task: recorded capabilities, implementation anchors, declared dependencies, evidence, and unknowns. You can inspect those same records and relations in the workbench, open their evidence, and decide which proposed meaning changes to keep. The files remain available to the next person or agent, alongside the code in Git.

The goal is understanding and actionable control, with confidence proportionate to the evidence. A graph path is a declared relationship, not proof of a complete runtime blast radius. A current source path does not prove its recorded meaning is correct. Atlas keeps those distinctions visible so missing evidence can lead to further inspection rather than automatic reassurance. Its five-kind discriminator and standards boundary live in the vault specification.

Use it in the next task

With a populated vault and an MCP connection, ask your agent for the context of the change you want to make. The current task-aware entry is query_ontology with operation: "agent_brief", detail: "compact", a selected project, and your task. It supplies bounded context and follow-up reads; the coding agent still inspects source and verifies its work.

When meaning changes, review the exact proposal and its evidence, then keep the accepted Markdown change with the code's Git history. You need not open Atlas for every task; its map, documents, and change review are there when you need to understand or correct the recorded meaning. Meaning acceptance, code review, merge, and deployment are separate decisions. Host support and configured permissions determine how agent writes reach review; an MCP connection alone does not enforce every agent's behavior.

What still needs proof: reliable meaning reconstruction from unfamiliar legacy code, a complete task-bound Meaning Diff, and improved outcomes across successive real tasks remain development and validation work. Current graph, write-review, and task-context features do not guarantee that an agent's code change is safe. See the quality authority map and development priorities.

Status — read this before installing

The download page is the release authority: a generated record of the published tag, real asset sizes, checksums, platforms, and signing state. This README pins no tag, so it cannot contradict the files you are about to install. GitHub Releases is the second direct source.

• The unsigned Windows beta is a real risk, not a formality. SmartScreen may warn about an unknown publisher, and a managed work PC may refuse the installer outright. Security states what is and is not promised.
• Installing the desktop app installs the agent surface. Both bundles carry the compiled MCP server. There is no npm package; every other platform runs the browser app, the CLI and MCP server from a source checkout, or the MCP server as an .mcpb bundle or a container image (channels).
• A -rc.N build walks the same signing, notarization, installer, and updater checks as a final one — what it lacks is a wide run behind it. The in-app updater reads a fixed Pages manifest staged from the newest non-draft release, release candidates included, and every archive must pass the bundled signature check before installation.
• Screenshots demonstrate the product journey, not release availability.

Where it stands

Not a roadmap. This summarizes behavior documented in the feature inventory, the specification, and the decision history and independent record workflow.

Each worktree adds its own decision/change/pilot fragments with pnpm record:new and pnpm po:record. pnpm test:records checks composition and writer contracts. Docs Vault JSON and public copies are ignored build products, materialized by installation and checkout/merge hooks; use pnpm docs-vault:build after an installation with scripts disabled.

Working today

• A Markdown folder is the whole database — read and written in place, with no import step, no index to build, and no account.
• The macOS app, Developer ID signed and notarized, with the compiled MCP server inside its bundle, and the hosted web app as a no-install gateway.
• MCP over stdio for Claude Code, Cursor, VS Code, Codex, and any other client, typed and advertised through tools/list. Agent guide.
• One-button agent setup that ends in a real proof — paths shown before writing, then an agent restart and mcp-verify. File presence is never presented as a live connection.
• A CLI with the same authority as the agent — scaffold, validate, dry-run writes, traversal, blast radius, commit preflight, agent handoff. CLI reference.
• Every surface reads that one folder — Map, Architecture, Library, Insights, Projects, Agents, MCP, and Git History.
• Saved constellations keep a task's concept set together — name a set in Galaxy, record its purpose, reopen the whole set on the map, inspect its real members in Library, or recover the same read-only context through MCP and CLI.
• Versioned AI analysis kept as local Markdown, with its evidence and selectable history, and measured violations instead of an invented maintainability score. Analysis records.
• Documents of any format gather in the Library, kept byte for byte, with wiki pages required to cite their source on every fact.
• External MCP servers attach to the in-app chat — one switch per server, off by default, tokens only in the keychain. Atlas never sits in that path.
• JSON-LD and GraphML export off the same deterministic compile artifact, so the vault opens in rdflib, Protégé, Gephi, Cytoscape, NetworkX, or Neo4j.
• init installs the agent's procedures where the agent runs, and prints the one sentence to paste into your own CLAUDE.md or AGENTS.md. Atlas does not edit files you wrote.

Shipping, not settled

• Windows x64 is an intentionally unsigned public beta — same folder and MCP surface as macOS, no signature.
• The vault format is v2.0-rc, an RFC open for comment that documents behavior already enforced by contract tests here and carries its own kill criterion. Specification §0.
• Linux has no packaged build — the browser app or a source checkout, same vault, fewer screens.
• Web and desktop do not promise the same screens, and that is not a backlog. Git history and offline work are desktop capabilities; the web cannot run git or native bridges.

What we decided not to build is What this is not.

The journey

1. Open a folder

When several folders are known, the app opens a single list with Open folder and Create new above it. The page scrolls as a whole; folder rows keep their paths, last-use details, and recovery actions together.

Choosing Map in the sidebar or with G M shows a live preparation scene, then reveals the first drawn frame. Section tabs use a flat shared treatment with a clear bottom selection indicator.

Point the app at a directory of Markdown and it reads it in place. Ask it to start from your code instead, and it creates exactly one folder inside the project you picked:

your-repo/
├── src/
├── package.json
└── atlas/                 ← the whole ontology, and nothing else
    ├── project.md         one project document
    ├── domains/           what the product is made of
    ├── capabilities/      what each area can do
    ├── elements/          the implementation pieces they work with
    ├── architecture/      reviewed role and dependency profiles, when you have one
    ├── sources/           the documents around the code, kept exactly as they arrived
    ├── wiki/              one page written from those sources, each fact cited
    └── .ontology-atlas/   gitignored, local only: bindings, audit log, activity

That location is a decision, not a default. A map kept outside the repository travels on one laptop, and the change to the code lands in a pull request while the change to its meaning does not. Inside, the two move together in one diff — so commit atlas/, push it, or copy it to another machine, and the map goes with it. The exact path is shown before anything is written, and an existing atlas/ is reused and reported rather than overwritten.

Every screenshot below reads samples/storefront, an example folder in this repository; node cli/src/index.mjs overview samples/storefront prints its current census.

Library → Ontology opens only the folder's explicitly typed project, domain, capability, element, and document nodes without the canvas: preview or edit Markdown, inspect the frontmatter that becomes the graph, follow backlinks, and jump back to the map. There is no imported copy to synchronize. Sources, Wiki, Ontology, and Collections share one Library destination. Collections lists saved Galaxy constellations, their purpose, and resolved ontology members; each member opens its actual Ontology document and each constellation returns to the whole saved set on the map. An existing /docs/?slug=… link to ordinary Markdown opens that exact file in a single-document compatibility reader with a return to Library. The Ontology tree's name-and-path search matches localized display names as well as canonical paths.

2. Connect your agent

Agents finds the coding tools already installed on this computer and opens a conversation beside the map. MCP holds the folder's own connection, the setup for each client, and the Connectors that attach external servers to that conversation.

• Connect once, with visible scope. The flow names the folder and config it will change, and writes plain text you can inspect. Claude Code, Codex, Cursor and Antigravity get one button each; any other client uses the snippet.
• Then prove it from the agent's folder. mcp-verify starts the bundled server, reads the active vault, and reports the real result or failure.
• The conversation does not stop at the first map. Up to three next steps derived from the current vault appear under a completed answer; choosing one fills the composer for review and never sends or writes on its own.
• Nothing stays running. The server speaks stdio, opens no port, and makes no network request (Security).

3. Read the map

Selecting a node dims everything unrelated and opens its record without hiding the node behind the inspector — a visual hierarchy for a person and typed parents, evidence and actions for an agent, from the same fact. Recent changes can narrow the map while keeping project and domain context, and Footprints record the order in which you opened concepts.

Five views keep their questions explicit: Flat is the normal 2D map and Galaxy turns every real concept into a stable three-arm sky: the project is the core, domains anchor contiguous constellations, and their owned concepts form nearby star clouds. Its default overview hides the relationship mesh so the groups read first; pointing at or selecting a star reveals only its actual adjacent relations as luminous filaments. Each star flares on its own intermittent cadence while its steady brightness still derives from connection count, never live activity. Diffuse gas flows gently inside the fixed arms while the stars and their spatial neighborhoods stay anchored; reduced motion freezes the whole atmosphere. Cone draws containment as nested cones, Strata separates kind tiers onto planes, and Neural groups related concepts in three dimensions with lit cell bodies and short connections. Keyboard focus remains visible while following related concepts, and Fit provides an explicit overview return on touch screens too. Inspecting a Galaxy concept keeps the expanded constellation in place and smoothly approaches the selected star in the free canvas beside the inspector, without zooming out a closer view. Closing restores the prior camera unless you navigated meanwhile. Every 3D view uses shallow, bounded relation curves shared by rendering and picking. Changing the view never changes the graph.

4. Gather and read documents in the Library

A codebase's meaning is rarely only in the codebase. The plan, the spreadsheet, the handover note, the page somebody wrote on a wiki — the Library keeps those exactly as they arrived, under sources/, and nothing is parsed on arrival. Each row carries only what a folder listing can say: format, byte size, and whether it has been written up. Open one and Atlas says so in as many words — it has never read the file, and the hash it shows exists because a page claimed the source.

What is written from them is the other half, and the counts stay honest about it: two of these three are not written up yet, and the folder says so rather than presenting one page as coverage. A wiki page cites its source on every fact, from the same template whether a person or the in-app agent writes it, and wiki-validate names the lines that do not carry a citation rather than grading the page. Compile starts one conversation that reads the sources and writes the page; the traffic goes from your coding agent straight to its own provider, which the screen states instead of implying that Atlas sits in the middle.

Markdown source headings open their original cited lines inside Library, including the surrounding passage. No converted file is stored.

Creating a Wiki page opens a centered, background-blocking dialog that previews its live wiki/<slug>.md path, Markdown draft state, and five required section headings before any write. The current local-work receipt stays visible while earlier receipts remain under History. A successful app write produces one actionable notification; the folder watcher suppresses its matching duplicate.

Library also works without code or ontology nodes. Keep a question and its cited answer, inspect source changes, request an updated draft through Claude Code or Codex ACP, and compare before saving a new revision. Earlier answers remain available. Local Compile has its own read and approval path. See retained answers.

Galaxy can also save the current ontology-node selection as a named constellation with a purpose. Atlas stores that compatible v1 task scope in the selected vault, uses immutable node UIDs for membership, and keeps the manifest's exact document.path only as display context. Library → Collections shows resolved and unresolved members without turning membership into an ontology relation. Use ontology-atlas constellations [vault] or ontology-atlas constellation <id> [vault] when an agent session cannot attach MCP; MCP exposes the equivalent read-only list_constellations and get_constellation tools.

The source workbench also offers task-bound ontology review: summary, comparison and full request details, with separate meaning acceptance and write permission. You can request a correction without losing a draft or defer a live request and resume it. Missing or changed comparison evidence stays explicit. For supported single-document patches in the installed app, exact Markdown previews and saved meaning decisions can be reopened from the existing History tab. Writer readback, code checks, merge and deployment remain separate facts. Supported scope and limits.

5. Plan against reviewed architecture

_{This screen reads Atlas's own repository rather than the storefront example, because measured import traffic needs a connected code folder.}

Architecture stays separate from the map. It sets what a person reviewed beside what an agent observed in the code, one role per row, with the difference in the middle; every stroke states its own sentence, and the same profile always draws the same picture. Findings & history keeps every inspection receipt. Pattern names such as Feature-Sliced Design, Hexagonal or Clean Architecture are reviewed declarations: conformance is derived from source evidence, never inferred from folder names.

6. Review a relation beside its node

Atlas shows a directional preview on the map, then a compact review of the source, type, target, reason, and exact frontmatter fields. Confirm and write is the only point that changes the file.

7. Review the change, then record it

Whatever wrote — you, the map editor, the CLI, or an agent over MCP — lands here first as a diff you read before it becomes history. Above is the change confirmed in step 6: two frontmatter lines, still unsaved. Git is scoped to the vault, and files outside the folder you picked are never touched.

The CLI writes the same two lines, says what it would do before touching a file, and refuses a dependency nobody explained ($ATLAS is the entrypoint set in Running from source):

$ node $ATLAS relate capabilities/order-cancel capabilities/refund dependencies ./storefront --dry-run \
    --why "Cancelling a paid order has to give the money back, so cancellation cannot finish without refund processing."

capabilities/order-cancel --dependencies--> capabilities/refund
  verdict matches_existing_schema · exists no
  schema  capability --dependencies--> capability
  pattern count 53 · resolved 53 · external 0 · unresolved 0
  recommendation safe_to_add · No exact or inverse edge found; capability --dependencies--> capability is an existing schema pattern.

dry-run would write dependencies on capabilities/order-cancel → capabilities/refund (no file changed)

Drop the --why and it stops rather than guessing one. An edge in a shape the vault has never used comes back as new_schema_pattern · review_new_schema, so a drifting agent is visible before it writes.

8. Keep it healthy

Insights opens on four measurements: concepts by kind, relations by type, the folder's health in words rather than a score, and the last four weeks of change. Do next is one row per kind of finding, and the counts add up to the title, always. Where a missing back-link can be repaired from two facts already on disk, one sheet names each file it would touch and nothing is written until you apply.

Growth replays the folder's own Git history week by week and stores nothing — the numbers are recomputed from commits each time the tab opens. A folder with no commits is told there is no history to show rather than drawn as a row of zeroes, because a zero would claim the folder was empty.

9. Choose a project by its purpose

The project index stays compact: each row shows the project name, its explicitly authored one-line description, a recent update, and direct routes to details and the map. Composition and construction controls remain on the project detail page.

What your agent gets

Ask which recorded dependencies deserve inspection for a change. Atlas follows declared relationships; their presence alone does not establish human approval or complete runtime impact:

$ node $ATLAS blast-radius capabilities/mcp-server docs/ontology --depth 2
capabilities/mcp-server — blast radius (depth 2, incoming)
  risk unknown · 1 node · 1 relation · 0 cross-domain

impact certainty unknown · declared 1 · rationale 0 · source-backed 0
Counts below follow declared depends_on only. Use reachability/subgraph for structure;
do not read unknown as low risk.

• Focused context, not a repository dump. A brief carries the project, domain, evidence, impact boundary, first tools, and stop conditions; for a task that only reads, OATLAS_READ_ONLY=1 returns one compact batch.
• Typed answers. Paths and reachability explain structure, blast radius follows declared dependencies only. No graph database, no hosted memory.
• Writes that survive review. Analysis is side-effect free by default, destructive operations dry-run first, renames repair backlinks, and mtime guards protect concurrent human edits.

The CLI carries the same authority for sessions that cannot attach a connector: MCP guide · CLI reference.

What we measured, and the mistake we found in it

A paired benchmark gives two sides the same source and question — one with a prepared vault, one with nothing. The first run looked like a large win, 0.25 against 0.875, until re-scoring showed most of that gap was not a comparison: the answer key mostly required Atlas's own concept names, which exist only inside the vault. We had published, in part, a vocabulary test that only one side could sit.

Each cell reads without Atlas → with Atlas. The control side named 100% of the source files it should have named in every run, and the gap left over rests on one word: the key wanted excludes, and an answer saying "explicitly outside it" scored zero.

So the honest status is that we have not yet measured a difference in answer quality, and Atlas was slower — a median of 17 and 33 seconds here, 28.2 and 51.1 in a separate run that carried one change through code, tests, commit, merge and cleanup on both sides. What it does show is narrower: only the Atlas side returned names you can look something up by. capabilities/checkout is an address a person or an agent can resolve next session, in another tool, months from now; "the checkout feature" is not. The re-scoring found a bug on our side too — the Atlas run dropped its own concept names in a third of the harder cases. Blind human grading is next; a stronger claim waits on unfamiliar repositories, that grading, and the measured cost of maintaining a vault. Method and every raw answer: paired findings · the correction · change-flow run · benchmark log.

Why not just use a notes tool

Local Markdown, git diffs, and MCP are table stakes; notes tools such as Basic Memory already provide them. Atlas adds a product ontology and a workbench where people and agents judge the same facts. If you only need an agent to remember conversations, a notes tool is lighter.

The argument and its sources are in Foundations.

A vault is just files

Everything below is the contract rather than the tour: how the folder is stored, what Atlas will never do, and how to run and verify it from source.

One Markdown file is one node. Frontmatter is the machine-readable record; the body is the explanation a person judges.

---
uid: 71890f3e-7b5d-4c0a-8f14-123456789abc   # permanent identity, kept through renames
slug: capabilities/token-issue
kind: capability
title: Token issue
domain: domains/auth
path: src/auth/token-service.ts          # a path — code evidence
elements:
  - elements/jwt-signer                  # a slug — an implementation-role node
dependencies:
  - capabilities/session-refresh         # a slug — another node
---

Issues access and refresh tokens for authenticated users.

A path points at code; a slug points at a node. Mixing them is the most common first mistake, and node $ATLAS validate reports it as a dangling reference. uid is the permanent identity, minted once and kept through a rename; the slug is the readable current address; a source location belongs in path:, never in a slug. Relations sit on the declaring file the same way, one frontmatter line from which Atlas derives the edge and its backlink — dependencies directed, relates symmetric, so the map never turns similarity into causality.

The reading spine is small on purpose — project → domain → capability → element, with document describing concepts anywhere on it — and an artifact earns a node only when it helps someone understand a capability, trace impact, or run the right proof. Curated, not exhaustive. There is no cap on how many nodes a vault holds: a wide hub is a review signal, not a limit, an analyzer's packet bound keeps one proposal readable and is never a graph bound, a bridge node has to earn its layer, and an external field trial's ontology is never merged into this product's vault. Each rule's authority is the quality authority map, and the practical test is what becomes a node?.

Three kinds of file share the folder, and only one is the graph:

Inside wiki/, _template.md is the shape every page is held to and _log.md records each compile or check; _-prefixed files are furniture, not pages. The folder is always named atlas/ (step 1), fixed so a teammate can say it and an agent's config can point at it without guessing, and init --documents writes the same folder without the node starters for people who have documents and no code. Full contracts: the relations guide and the vault specification.

Local-first, by construction

• Your disk is the database. Frontmatter is the graph, confirmed writes go back to the folder you picked, and Git is the history. There is no other store.
• No Atlas backend, account, or telemetry. The web app is a static export; the desktop app checks the public updater manifest once a day and uploads no vault content. A connected coding agent talks to its own provider only when you ask.
• Two ways in, one folder. The hosted web app can open a local folder through the File System Access API. The desktop app uses a Tauri bridge to your selected folder and keeps it open as a workspace.
• The Tauri macOS shell is a shell, not a silo. MCP and CLI still read the selected folder directly, and the bundled server is a file your agent launches itself, so it keeps working when the app is closed.

What this is not

• Not a general-purpose ontology editor. The ontology describes a codebase; a business concept belongs there when it explains what that codebase builds, why a boundary exists, or what a change can affect. The Library takes general sources and wiki pages with no code nodes at all.
• Not a code index, and not an IDE. Grep, language servers, AST indexes and CodeGraph answer where a symbol lives and what calls it; Atlas replaces none of them and answers why that artifact matters, which capability it serves, and what to verify before changing it. An IDE for codebase meaning is the useful analogy, and it stops there: Atlas does not edit, build, run, or debug code.
• No automatic acceptance of generated knowledge. Saving a wiki page or answer preserves it for review; it does not make its claims true or promote it into accepted ontology meaning.
• Not an RDF, OWL, SKOS, or SHACL implementation. The export is a bounded graph shape; the vault is not an RDF serialization, the validator is not a SHACL processor, and the query engine is not a reasoner. A persisted relation is a declared claim, never an entailment; an absent one is a visible gap, never a negative fact. Specification §5.2.
• Not a service, and not on npm. No backend, account, telemetry, daemon, or port; npx ontology-atlas is a 404 and not a future feature. The MCP server still reaches the ecosystem's registries as a release bundle or a container image, neither of which is a package registry.
• Not extensible by running other people's code. There will be no third-party plugin runtime. Extension happens through MCP tools, agent skills, and files in your own vault — things a git diff shows you before they run.
• Still evolving. The download page records current release availability and platform status.

Running from source

Linux and every other platform without a packaged build run the browser app, or the CLI and MCP server from a source checkout: Node.js 24 and pnpm, one clone outside the project you are describing, then init inside your own repository and mcp-verify to prove the live connection. The exact commands, the two required installs, and the reason init refuses to run inside the Atlas clone are in set up from a source checkout.

Documentation

Use it: hosted guide · features · MCP setup · CLI reference Model a vault: what becomes a node? · relations · v2 specification · quality authority map Understand it: product direction · foundations · architecture · security · decisions

Contributing

Issues and pull requests are welcome, and the most valuable report today is pointing Atlas at a real repository and showing where the proposed meaning, the agent handoff, or the validation falls short.

Read CONTRIBUTING.md first — external pull requests come from forks, and that is a security boundary rather than a formality. Inside this repository AGENTS.md is canonical for people and agents alike, and product decisions route through pnpm po:route -- --help from change facts rather than a self-declared risk.

Pre-push keeps quick checks local; full contract and Knip scans belong to PR CI. Main CI reuses a successful PR only for the identical Git tree with complete live required-check proof; unproven pushes use their diff. Daily and manual runs remain exhaustive. Exact test-file duplicates are collapsed within a local check run. Browser CI shares one build and balances whole test files by measured duration; node --test scripts/run-playwright-ci.test.mjs verifies allocation. MCP harness probes use pnpm test:mcp:rpc; full CI keeps the unique CLI boundary through pnpm integration:cli:architecture. Catalogue checks use captured inputs; pnpm mcp:catalogue:check-online explicitly checks current registry facts. Details: development checks.

Verification starts with pnpm checks:changed, which picks the focused gates for the files you changed; -- --run executes every recommendation and stops at the first failure, and it is the last command before a pull request.

Open the pull request as a draft (gh pr create --draft), which runs no CI, and land it with pnpm pr:land <number>. That one command serializes against every other agent: it takes a shared lock, merges today's main into the branch, runs the local lanes on the merged source, marks the pull request ready (which fires the single CI run for that branch), squash merges, deletes the branch and releases the lock. pnpm pr:queue shows who holds the lock and who is waiting; pnpm pr:ci <number> buys an early CI run without landing. Never run gh pr merge or gh pr update-branch by hand: a guard refuses both, because outside the lander neither waits for the landing already in flight.

For independent backlog-record additions, opt into earlier CI feedback with pnpm pr:land <n> --parallel-ci. Final merge and validation of newer main remain serialized; see eligibility and rerun limits.

Development checks is the full gate reference, one entry per area; map testability owns canvas performance, readability, contrast, and instrumentation.

License

MIT