> For the complete documentation index, see [llms.txt](https://docs.visdom.virtuslab.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.visdom.virtuslab.com/the-thesis.md). # The thesis Software delivery has two sides. One is the capacity to produce a change. The other is the capacity to **absorb** it: to understand it, check it, accept responsibility for it and deploy it safely. For fifty years the two grew together, because the same people did both and were bounded by the same hours, so nobody had to tell them apart. AI pulled the pair apart. Production became elastic: it is bought with a credit card. Absorption stayed rigid, because it still rests on people, their attention and their accountability. In any system where supply is elastic and validation is fixed, the surplus does not disappear. It accumulates: first in the review queue, then, once the queue stops being passable, in the quality of the review itself. ## Failure that looks like competence There is a second reason the surplus is hard to see coming. Code from a model does not fail the way bad code usually fails. Badly written human code tends to look bad (odd names, a truncated comment, a function three hundred lines long), and a reviewer has a signal telling them where to slow down. Code from a model has correct names, consistent style, sensible comments, and a decision three levels down that is wrong for this particular system. Twenty years of reviewer heuristics rested on a correlation between care of form and knowledge of the thing. The model severed it: **the form is immaculate, the knowledge of your system is zero.** None of this is an argument that AI does not work. The same technology, in a different organisation, genuinely delivers a multiple. Everyone uses the same models. The difference is what surrounds them. Visdom is that surround: a composable, fully self-hosted platform that supplies context, orchestration, validation, oversight and operational control, turning AI-generated code into software you can trust in production. ## The resource that is actually scarce Absorption capacity sounds like a property of a process, and it is not. It is made of people: the dozen or so in any large organisation who can look at a change and say whether it is safe, because they remember why that module looks strange, know what happened the last time, and carry enough authority to say no. You cannot hire those people in a quarter or train them in a year. That is what makes the arithmetic work. If the constraint is the attention of your best engineers, the most valuable thing to build is not more output. It is the removal, from those people, of everything that never needed their judgement in the first place: guarding layer boundaries, catching a deprecated library, scanning another diff for a small mistake, explaining the same convention again, working out who owns a module. None of it needed a senior. It got one because there was nobody else to do it. {% hint style="info" %} **The optimistic reading.** AI does not replace your best engineers. For the first time it gives them a chance to do only what they are irreplaceable at. {% endhint %} Every decision described in this documentation reads that way. Architecture rules exist so a senior does not have to be a linter. Risk classification exists so their attention lands on the few per cent of changes that need it. Context exists so they do not answer the same question for the tenth time. The audit trail exists so they do not spend a week reconstructing what happened. ## Design principles **Composability.** The platform is a set of independent components. A deployment can start with a single capability (automating one flow, or nothing but the audit trail) and expand at the organisation's own pace. The control plane is optional. **Customer ownership.** Everything runs inside your environment: Kubernetes, databases, secrets, models. Visdom sends no data to the vendor and does not train models on your code. **Human-in-the-loop where you want it, not everywhere by default.** Approval is a node you place in a flow, with a role, a timeout and its own branches, not a tax every change pays. A team that wants a person on every merge configures that; a team that wants a documentation fix to go through unattended and a change to a payment path to stop for review configures that instead. What the platform guarantees is that wherever the line is drawn, it is drawn explicitly in a versioned definition rather than left to whoever is reviewing that day. **Auditability as a foundation, not an add-on.** Every prompt, model call, tool use, file change and commit is recorded in a cryptographically signed, tamper-evident chain of events. **Model agnosticism.** The platform is not tied to one model vendor. Agents are separated from models by a driver layer and an OpenAI-compatible gateway (LiteLLM and equivalents), with native support for Anthropic models and for IBM's platform, which lets an organisation use its own subscriptions or models served on its own infrastructure. ## Isolation as an architecture, not a deployment mode Visdom was built for environments where isolation is a requirement, rather than adapted to them afterwards. The distinction has practical consequences. A cloud product adapted to run on-premises keeps the assumptions, mechanisms and dependencies of the environment it was built in, and it is exactly at the seams of such adaptations that data leaks. In Visdom there is no "cloud variant" from which things have to be switched off: no outbound telemetry, no dependency on vendor services, and a cryptographically signed audit trail are the starting point of the design. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.visdom.virtuslab.com/the-thesis.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.