Why We Open-Source Our Tooling, An Honest Capability Statement
Pull-quote: “A capability statement says what we claim we can do. A repository shows what we actually built when nobody was grading us.”
Why this matters
Every engineering firm produces documents asserting its competence: capability statements, case studies, slide decks. Evaluators read them with appropriate skepticism, because the genre rewards embellishment and punishes nothing. Published tooling is different in kind. A repository cannot be embellished after the fact. Its architecture decisions, its documentation, its handling of edge cases are all inspectable by anyone, including the technical evaluator deciding whether to trust you with their systems. That is why we open-source our internal tooling: a repository is a capability statement that cannot be embellished.
What the tools actually say
Each tool we publish is a work sample from a different layer of the practice, and each one answers an evaluator’s question no document can answer credibly.
| Tool | What it is | What it demonstrates |
|---|---|---|
| DocPrep-AI | Browser-based document preparation for RAG: six formats, a 25-column catalog schema, JSONL export, client-side processing | How we treat data preparation and privacy: local-first, structured, validated |
| MarkForge | Document conversion on Microsoft’s MarkItDown: twelve formats to Markdown, Markdown to styled PDF | How we handle the unglamorous plumbing, and that we build on proven foundations rather than rewriting them |
| Weaviate Local UI | A desktop studio for local Weaviate: collections, schemas, queries, an AI chat interface | How we think about developer experience and making systems inspectable |
| DevOps Monitor | Grafana, Prometheus, Loki, and Alertmanager as one composed, pre-wired stack | How we operate what we ship: observability as a default, not an afterthought |
Read the column on the right as a set of engineering values: local-first where data is sensitive, proven foundations over rewrites, inspectability over black boxes, operations as a first-class concern. We could assert those values in a deck. The repositories assert them in a form that can be checked.
The line, drawn deliberately
Open-sourcing tooling only means something if the line between open and proprietary is principled rather than accidental.
Open: the practice's tooling Proprietary: the platforms
───────────────────────────── ───────────────────────────
Document preparation (DocPrep-AI) The application platforms and
Format conversion (MarkForge) the domain engines behind them,
Vector DB workbench (Weaviate where the sustained R&D
Local UI) investment lives and the value
Observability (DevOps Monitor) flows to customers
│ │
▼ ▼
Better if everyone has it Better because not everyone has itThe test we apply is simple: tooling whose value grows when everyone uses it belongs in the commons; platform capability that represents sustained, differentiated R&D belongs to customers. Publishing the first category costs us nothing competitive and buys the ecosystem real utility. Publishing the second would be donating the reason clients hire us. Drawing the line clearly, and saying where it is, is itself part of the honesty.
The dogfooding clause
One more property makes published tooling credible: we use it. These are not portfolio pieces built for the repository; they are the tools our own work runs through, published. That has a disciplining effect that outlasts any release checklist, because the first user annoyed by a rough edge is us.
Closing
Trust between an engineering firm and the people evaluating it is built on evidence, and the strongest evidence is work product that can be inspected without permission. Our open-source tooling is exactly that: real tools, used in real work, published where any evaluator can read the code and judge the judgment. The capability statement is on the letterhead. The proof is in the repositories.