> 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/visdom-control-plane/available-today.md).

# Available today

What the Control Plane does in release 0.3.32, and where each capability lives.

This page lists what works in the current release, **v0.3.32**, and nothing that does not. What is planned is on [Roadmap](/visdom-control-plane/roadmap.md); what is missing or rough is on [Known limitations](/visdom-control-plane/known-limitations.md).

## Projects and repositories

* **Project catalogue.** A project has a name, a description and a slug. The slug is immutable and unique (`^[a-z0-9][a-z0-9-]{0,62}$`), because every other product addresses the project by it. Projects are archived, never deleted.
* **Repositories per project.** Each repository has a name, a clone URL, a branch and an optional **GitHub App installation ID**. URL and branch are unique within a project. The Control Plane stores the configuration only; it never clones.
* **Connection test.** A read-only git smart-HTTP probe checks that the URL answers and reports the default branch. It is HTTPS only, refuses a cross-host redirect when a token is attached, and is advisory: a failed probe does not block saving.
* **Repository authentication.** One access token per project, stored encrypted. Its metadata is visible in the UI; the value is handed only to machine principals (the other Visdom products) and admins.
* **Selected project.** Each user's current project is shared across the suite, so switching project in one product switches it in all of them.

## Identity and permissions

* **Sign-in through Keycloak (OIDC).** The UI uses authorisation code with PKCE; the API accepts bearer tokens validated against the realm's JWKS. There are no session cookies.
* **Just-in-time users.** A person is created on their first request and matched on the identity provider subject. A disabled user is refused everywhere.
* **Machine principals.** Keycloak service accounts, used by the other products to call the Control Plane, get their own identity and no user record.
* **One permission catalogue for the suite.** Every product has a *sign-in access* key and a set of roles, each with a fixed scope: the workspace or a project. A role takes effect only together with its product's sign-in access. Deny by default: a new user has no access until someone grants it.

| Product        | Roles                                                                                                                             |
| -------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| Orchestrator   | Viewer (project), Operator (project), Building blocks viewer (workspace), Building blocks operator (workspace), Admin (workspace) |
| Context Fabric | Viewer (project), Operator (project), Administrator (workspace)                                                                   |
| AI Tracing     | Viewer (project), Operator (project), Admin (workspace)                                                                           |
| Control Plane  | Viewer (workspace), Operator (project), Admin (workspace)                                                                         |

* **Grants with provenance.** Each grant records who gave it and when. Revoking a product's sign-in access removes that person's other roles in the same product.
* **Effective permissions API.** `GET /api/v1/permissions/effective` answers for a user or subject, optionally narrowed to a project, and can group the result by project. It is cacheable (`ETag`, 60-second `max-age`), so a product can ask on every request without loading the Control Plane.

## Integration with the other products

* **Project sync.** Creating or archiving a project and adding, changing or removing a repository write an event in the same database transaction as the change. A worker delivers it to every configured product with an OAuth2 client-credentials token and W3C trace context, and retries with backoff until it lands. Context Fabric, AI Tracing and Orchestrator are sync targets today.
* **Repository list for agents.** Orchestrator reads the repositories, with their GitHub App installation IDs, from one cross-project endpoint; Context Fabric reads the repository token.
* **Suite dashboard.** The Home page asks each product for its own summary with the user's token and shows one view: runs in progress, what needs attention, what finished today and what failed, plus usage and cost from AI Tracing. It follows the selected project.
* **Suite shell.** The module rail (Home, Orchestrator, Context Fabric, Tracing), the project switcher, per-user light and dark themes and the workspace timezone are served by the Control Plane and used by every product's UI.

## Secrets

* **Encrypted at rest** with AES-256-GCM and a random nonce per value, under one master key supplied at start-up.
* **Workspace or project scope.**
* **Write-only values.** The API lists metadata, creates, replaces and deletes. No endpoint returns a secret's value, except the repository token for machine principals and admins.

## Operations

* **One container.** A Rust service with the UI embedded, distroless and non-root, listening on port 8080. PostgreSQL is the only dependency besides Keycloak. Migrations run on start-up.
* **OpenTelemetry.** Traces, metrics and logs over OTLP/HTTP when an endpoint is set; W3C trace context in and out. JSON logs.
* **OpenAPI.** The specification is served at `/_/openapi.json` and a Swagger UI at `/_/openapi/ui`.

See [Deploying and configuring](/visdom-control-plane/deploying-and-configuring.md) for the environment and [API reference](/visdom-control-plane/api-reference.md) for the endpoints.


---

# 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/visdom-control-plane/available-today.md?ask=<question>&goal=<endgoal>
```

`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.
