Infrastructure, not a product.
digithings is an open-source, modular AI infrastructure repository. Nine shipping modules — orchestration, quant research, retrieval, chat, auth, tracing, heartbeat and audit, a markdown vault, and the shared library the rest sit on — plus two more marked roadmap in the registry rather than quietly counted as built. You run them on your own hardware, against your own provider keys, with every step of every run readable afterwards. It is a set of parts you assemble, not a platform you move into.
What that means, concretely.
Four claims, each one checkable against the repository rather than against a brochure.
MIT, and public
The whole repository is MIT-licensed and readable without an account — the orchestration graph, the quant engine wiring, the auth service, the tests, the CI. No open-core teaser with the useful half held back.
Self-hostable anywhere
One docker-compose.yml runs the stack on a laptop, a VM, or a cluster. Every service binds loopback by default, so nothing is on a public interface until you decide to put it there.
Bring your own tokens
Anthropic, OpenAI, or anything LiteLLM speaks. The stack persists no provider credentials — they are supplied per request or read from your own environment — so the model provider, the budget, and the data boundary stay yours.
A glass box, not a black box
A correlation ID enters at the edge and rides every hop; workflow steps land in a local JSONL audit trail — appended, never rewritten — and in digismith spans. You can read what the system did, step by step, after the fact.
It plugs into what you already run.
Compatibility is a design goal, not a migration story. digithings is not a replacement for your orchestration framework, your data stack, your model provider, or your execution venue — it is the wiring between them, and it uses the same tools you would have reached for.
- LangGraphsupervisor + sub-graph orchestration
- NautilusTraderevery backtest and optimise path
- Polarsdataframes by rule; pandas only at the Nautilus and yfinance edges
- Pydantic v2typed models at every boundary
- LiteLLMprovider routing and response caching
- MCPevery capability exposed as a discoverable tool
- Dockerone compose file for the whole topology
The corollary is that you can take a piece and leave the rest. The vector store and the LLM provider are both behind interfaces; swapping one is a configuration change, not a fork.
Traceable by construction.
“Explainable” is a claim about a model. This is a claim about a system: the path a request took through it is recorded, and you own the recording.
One id, every hop
All six FastAPI services install the shared X-Request-ID middleware from digibase.http. The id is read from the request or generated, attached to every log record, forwarded on outbound service-to-service calls, and echoed on the response — so one identifier stitches a whole run together.
An audit trail on disk
Workflow events are appended to a local JSONL audit log, redacted on the way in. It is a file you own on a host you control — not a retention policy you agreed to.
Tools you can enumerate
Capabilities are exposed as MCP tools with typed Pydantic schemas, so the set of actions an agent can take is a list you can read — not an emergent property of a prompt.
Where that recording has gaps — and it does — they are written down. The audit log is per-host with no signed chain, redaction is name-based rather than content-based, and live-trading adapters are stubs behind a review gate rather than a runtime interlock. The security page states each limit.
Start where you like.
The API reference is written from the codebase and merged with the same module data this site is built on. The repository is the rest of the answer.