> 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/products-and-packages.md). # Products and packages The products Visdom is made of, the layers they share, and the packages built from them. Visdom is a set of products. Each one is useful on its own; together they work on three shared layers, so the second product an organisation adopts adds capability rather than another set of permissions, policies and reports. A **package** is products pre-combined for one common problem. ## The shared layers | Layer | Provided by | What it gives every product | | ----------------------- | ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | **Identity and policy** | Visdom Control Plane (Policy Gate on the roadmap) | The same people, projects, repositories and permissions everywhere; later, one policy decision before every model and tool call | | **Context** | Visdom Context Fabric | The same knowledge of the organisation's systems for agents, IDEs and reviewers | | **Evidence and cost** | Visdom AI Tracing | One signed record and one cost ledger for every AI action | Two more runtimes are shared the same way: **model and tool access** through the Visdom AI Gateway, and **containment** of agents through Visdom Security. ## Products | Product | What it does | Today | | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------ | | **Visdom Control Plane** | Manages the ecosystem: projects, repositories, people, permissions and secrets for every Visdom product | In use; release 0.3 | | **Visdom AI Gateway** | One governed door to every model and every MCP tool, on the organisation's own contracts | Reference deployment of both gateways, tested; the Visdom layer on the roadmap | | **Visdom Context Fabric** | Compiles what the organisation knows – ownership, dependencies, conventions, history – and serves it to agents over MCP and as `AGENTS.md` | Beta | | **Visdom Orchestrator** | Runs coding agents as versioned, supervised flows on Kubernetes, with approvals, budgets and egress policy | Beta | | **Visdom AI Tracing** | Records every prompt, model call, tool use and edit in a signed chain, with cost and line-level attribution | Research preview; the CLI is open source | | **Visdom Code Review** | Review effort in proportion to risk: a deterministic gate, then AI review lenses for what the change touches | Reference implementation | | **Visdom Testing** | Architecture, property, mutation and contract tests that stay honest when a model wrote both the code and the tests | Methodology available; the Crucible engine in design | | **Visdom Security** | Contains the agent while it works (Sandcat) and scans what it ships | Sandcat open source; AppSec with partners | Each product has its own section in the tabs above, with what is available today, the roadmap, and its known limitations. **Visdom Machine CI** is optional and outside the core. For organisations where build time limits how fast agents can iterate, it adds build caching, selective testing and Bazel-based acceleration. It matters most where a full build runs in tens of minutes, and no package requires it. ## How the products use the layers | Product | Control Plane | Context Fabric | AI Tracing | | -------------- | -------------------------------------------------- | --------------------------------------------- | ---------------------------------------------------------------------------------- | | Orchestrator | Today: permissions, project sync, repositories | Today: `AGENTS.md` and MCP for agents | Next: runs and commits in the signed chain (today: its own hash-chained audit log) | | Context Fabric | Today: permissions, project sync, repository token | – | Next: indexing cost as platform cost | | AI Tracing | Today: permissions, project sync, dashboard | – | – | | AI Gateway | Next: teams, keys, budgets, kill switch | Next: offered as an MCP server in the gateway | Next: every call in the chain | | Code Review | Next | Next: blast radius and owners for deep review | Next: findings and review cost | | Testing | Next | Next: conventions and risk | Next: evidence per change | ## Packages ### AI-ready repositories **Problem.** Teams want agents and AI review on the repositories they already have, without migrating source control or rewriting the hooks and merge rules that took years to get right. **Products.** Context Fabric, Orchestrator, Code Review (with Testing as an option) and Security, on the shared layers, with model access through the AI Gateway. **How it works, on GitHub.** 1. Agents authenticate as the organisation's GitHub App with short-lived installation tokens and commit under its identity. The app is on no bypass list: required reviews and status checks apply to it exactly as to a person, and Visdom holds no merge path. 2. Context Fabric builds `AGENTS.md`, the dependency and ownership graph and the wiki, and serves them over MCP to any agent or IDE. 3. A pull request, opened by a person or an agent, triggers review: the deterministic gate always, AI review when the risk warrants it. Results arrive as one summary comment, inline suggestions, a status check a branch rule can require, and SARIF for code scanning. 4. A person merges. Undoing agent work is an ordinary revert. **No migration.** Source control stays the system of record for code, pull requests, protected branches and merge checks. Visdom works as a layer above it and connects through an adapter, so changing the platform underneath changes the adapter while rules, policies, evidence, costs and agent configuration stay. Every phase ends with something working and can be the last one; nothing forces a point of no return. **Today and next.** On GitHub today: the GitHub App identity, `AGENTS.md`, graph, wiki and MCP, the review-and-fix flow and status checks; triggers through the generic webhook. Next: a first-party adapter contract – GitHub first, then Bitbucket Data Center and GitLab – plus a deterministic readiness score per repository, scaffolding from a template, and one exclusions file honoured by indexing, agents and review. ### Governed AI access **Problem.** AI use spreads across IDEs, applications and agents, each with its own keys, no shared policy, no chargeback and no audit. **Products.** AI Gateway, Control Plane and AI Tracing; optionally Context Fabric as an approved MCP server and Sandcat so workstation tools can reach only the gateway. **How it works.** Two addresses, one for models and one for tools, and one virtual key per person or application. Allow-lists and budgets per team, with an alert before the limit and a stop at it. Later, a policy decision before every call and every call in the signed chain. This package does not depend on source control at all, which makes it the second door into the same platform. ### Issue to pull request **Problem.** Routine bugs and small changes wait in the queue, and an agent pointed straight at them produces pull requests nobody trusts. **Products.** Orchestrator (the issue-to-PR flow), Context Fabric, Code Review and Testing, and containment, on the shared layers. **How it works.** A ticket triggers the flow. If it does not say enough to act on, the flow comments and stops. Otherwise Context Fabric supplies the repositories, modules, owners and blast radius; the agent works in a sandbox with an egress allow-list and secrets it never sees; the gates run with a bounded fix loop; and the result is a pull request carrying the ticket, the rationale and the evidence. A person approves the merge. Cost and evidence are reported per ticket. ### Entry points * **AI evidence and cost** – AI Tracing on its own: what did AI do in our repositories, and what did it cost. * **Pull request quality gate** – Code Review as a CI step, for organisations already generating code with any assistant. * **Contained agents** – Sandcat on workstations, open source. Each grows into a package by adding products, not by replacing anything. ## Principles * **Runs on your infrastructure.** Single-tenant, on your Kubernetes, against your database, identity provider, secret store and model endpoints. No SaaS path. * **Works without internet access.** No telemetry, no online licence activation. The only outbound traffic is to the models and tools you approve. * **No migration.** A layer over the systems you already run, connected through replaceable adapters. * **Reversible.** No hard cutover; scope and pace can change at every phase. Configuration is in Git, evidence and costs export in open formats. * **Your models, your contracts.** Models run on your own provider contracts or locally, passed through at cost. The coding agent and the model are replaceable parts. * **A person approves.** An agent never merges on its own authority, and every step leaves evidence that can be verified offline. * **Honest status.** Every capability is labelled *available today*, *next* or *later*, and every product section has a page of known limitations.