This project has been archived by its maintainers, and is no longer receiving any updates.
DomainTome
The living knowledge graph for your software project.
Status: pre-1.0, solo-maintained. DomainTome is functional and used in production projects, but the API, the schema and the MCP surface may still break between minor versions. Bug reports are welcome; feature PRs may not be merged while the design stabilizes. The repository will open up to broader collaboration once the API is stable (target: 1.0).
DomainTome captures the business logic of a project — modules, capabilities, flows, events, rules, forms, entities and decisions — as a typed graph backed by SQLite, and exposes it over MCP so AI coding assistants (Claude Code, Claude Desktop) can query and maintain it as part of normal work.
It answers questions like "how many ways of registering a payment exist?", "what breaks if I touch flow-checkout?" or "which rules protect this entity?" in a single tool call, with provenance, without re-exploring the codebase each time.
Why
- Persistent memory across sessions — the graph survives context resets.
- Zero documentation overhead — the assistant writes as concepts get decided, not as a separate chore.
- Auditable — every node carries
source,confidence,source_context. Every MCP call is logged. - Token-efficient — summary-only listings, batch ops, cheap sub-agents for exploration, WAL-mode SQLite.
Token economics (measured)
Bytes-on-the-wire to the model when answering structural questions, with vs. without DomainTome. Reproduce on your machine via examples/booking-api/ (full protocol in examples/booking-api/README.md).
| Project | Files | Question | Without | With | Ratio |
|---|---|---|---|---|---|
booking-api |
5 | How many ways can a Reservation be cancelled? | 6,213 B | 1,485 B | 4.2× |
booking-api |
5 | What rules apply to a Reservation? | 4,032 B | 291 B | 13.9× |
booking-api |
5 | What does deactivating a Resource affect? | 4,654 B | 543 B | 8.6× |
domaintome (this repo) |
62 | What capabilities does DomainTome expose? | 49,726 B | 729 B | 68.2× |
domaintome (this repo) |
62 | Where do graph writes happen? | 14,566 B | 314 B | 46.4× |
Median 13.9×, range 4–68×. The "without" column is a floor — minimum file set, no Grep/Glob overhead. Real sessions read more. The pattern is clear: ratios grow with project size and how scattered the answer is across the codebase.
Maintenance cost (what Claude pays to keep the graph in sync): a typical "new flow + 3 edges" write costs ~720 B total. Break-even is <1 query per new feature. Reads dominate writes by orders of magnitude.
Caveats: input-payload only (output answer not measured); does not include the one-time /dt:sync (INIT/EXTEND) cost; ratios are descriptive of the questions tested, not a guarantee for arbitrary questions.
Install (Claude Code plugin — recommended)
/plugin marketplace add YACB2/domaintome
/plugin install dt@domaintome
/reload-plugins
The plugin's .mcp.json uses uvx to fetch the domaintome package from PyPI on first run, so the only prerequisite is having uv installed (brew install uv or curl -LsSf https://astral.sh/uv/install.sh | sh). No separate pip install step.
Reload, then from the project you want to model run /dt:sync — one command, three auto-detected modes: INIT (no graph yet, interactive seed), EXTEND (graph exists, broad re-scan), DIFF (/dt:sync HEAD~10 to walk only what changed since a git rev). /dt:init is a permanent alias that lands in INIT mode. "Project" can be a single repo or a workspace that contains several repos — DomainTome has no opinion, .dt/graph.db is created relative to whatever directory you launched Claude Code from.
The plugin bundles:
- MCP server exposing
dt_overview,dt_add_node,dt_update_node,dt_delete_node,dt_get_node,dt_add_edge,dt_remove_edge,dt_query,dt_traverse,dt_list,dt_audit,dt_history,dt_stats,dt_schema,dt_export_markdown. (dt_add_nodeanddt_add_edgeaccept an optionalnodes/edgeslist for atomic batches.) - Auto-invoked skill (
dt-usage) that tells Claude to read before acting and write on decision, with provenance rules and lifecycle conventions. - Sub-agent
dt-explorer(Haiku, read-only) for broad exploration without burning expensive tokens. - Slash commands:
/dt:sync(INIT / EXTEND / DIFF, auto-detected),/dt:init(permanent alias → INIT),/dt:audit [<path>](active project, or another project's graph at<path>/.dt/graph.db),/dt:show <id>,/dt:recent,/dt:impact <id>,/dt:reconcile,/dt:verify,/dt:stats.
Install (standalone CLI / other MCP hosts)
pipx install domaintome # or: uv tool install domaintome
dt init
For Claude Desktop / other MCP hosts:
{
"mcpServers": {
"dt": {
"command": "dt",
"args": ["mcp", "--db", ".dt/graph.db"]
}
}
}
CLI reference
dt init # create .dt/graph.db
dt list [--type flow] # summary listing (id, type, title, status)
dt show <id> # full detail + edges
dt query "payment" # exact id → title substring → tag fallback
dt variants <capability-id> # flows implementing a capability
dt audit # orphans, cycles, id hygiene
dt stats [--since ISO] # token/usage analytics from the audit log
dt export --out .dt/export # one markdown file per node
Schema
Eight node types (stack-agnostic): module, capability, flow, event, rule, form, entity, decision.
Nine relations: part_of, implements, depends_on, triggers, validates, enforces, supersedes, references, conflicts_with. Type pairs are restricted (see schema.py).
Statuses: active | draft | deprecated | superseded | archived. Soft-delete is the default; dt_delete_node is reserved for typos and warns about edge loss.
The central abstraction is capability — a thing the system knows how to do, independent of how. Multiple flow nodes can implements the same capability, surfacing UX/logic divergences.
Model routing
Operations are split by cost:
- Reads (broad scans, traversals, audits): delegated to Haiku via the
dt-explorersub-agent ormodel: haikufrontmatter on slash commands. - Writes & modeling decisions: caller's model (Sonnet/Opus). A sub-agent proposes JSON; the caller reviews and persists.
Override per-project in .dt/config.json:
{
"language": "es",
"app_name": "my-app",
"models": { "exploration": "haiku", "write": "sonnet" }
}
Provenance & history
Every node carries metadata.{source, confidence, source_context} and, when relevant, source_ref (path:line), last_verified_at, deprecated_at, deprecated_reason, replaced_by.
dt_update_node(metadata_patch=…) merges without destroying provenance; metadata still exists for rare full replacements.
dt_history(id) returns every MCP event for a node (newest first) from the append-only audit log. dt_stats aggregates by tool/op and reports input/output bytes.
Status
Pre-MVP, alpha. Schema and MCP tool surface may change before 0.1.0.
Development
uv sync --all-groups
uv run pytest -q
uv run ruff check src tests
Tests live in tests/. The plugin layout is validated by test_plugin_structure.py.
License
MIT.
Release files for domaintome 0.6.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| domaintome-0.6.0.tar.gz | 114.9 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| domaintome-0.6.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 164.4 kB
Release files / domaintome-0.6.0.tar.gz
| Download URL | domaintome-0.6.0.tar.gz |
|---|---|
| Size | 114.9 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
624ba401ecfa5e88e7edb99c774d3acf9c54bc879ce9de409157b138a13bd031
|
|
BLAKE2b-256 checksum How to use checksums |
e54ba361770d6fa5929cea9cba67fb9316b306a55536a56721e1e944ae1a2ad9
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.12
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on May 27, 2026.
Transparency logRelease files / domaintome-0.6.0-py3-none-any.whl
| Download URL | domaintome-0.6.0-py3-none-any.whl |
|---|---|
| Size | 49.6 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
709974ad410d4383ffbe8115a3bf356f07f7fdf008968caa2caef3c127f616bd
|
|
BLAKE2b-256 checksum How to use checksums |
66fdf1b5f54d7e09ec6348a7acfd520c50c88db05257adade5596b5b98434df3
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.12
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on May 27, 2026.
Transparency log