# Concepts > The hub's vocabulary, from source and namespace to run, journal and decision. Generated from the project glossary so it always matches the code. Canonical page: https://capabilities.sh/docs/concepts Updated: 2026-11-06 These are the words the hub, its CLI and this site use, each with one meaning. They come straight from the project glossary (`CONTEXT.md`), copied into this site at a pinned commit and regenerated whenever that copy is refreshed. > [!STATUS] > The hub is in development, so these terms describe the design of record. Commands such as `capabilities hub serve` are planned for M1; see [Status](https://capabilities.sh/status.md) for what has landed. The two relationships that matter most: - A **source** yields a manifest of tools. Each tool has an **address** (`namespace.tool`) and a **contract** digest. The **index** is built from every manifest. - A tool call is decided by **policy** against the tool's address and the **connection** it uses, and recorded in the run's **journal** with that decision. ## The hub ### Hub The service that holds a person's sources, connections, policies and skills and serves them over one MCP endpoint. It runs locally (`capabilities hub serve`) or hosted (one tenant per account); both are the same engine behind different ports. Not to be called: gateway, proxy, executor. ### Source Where a hub's tools come from: a remote MCP server, a local stdio MCP server (local hub only), or an OpenAPI document. An MCP-server capability becomes a source when it is added to a hub. Not to be called: integration, plugin, connector. ### Namespace The identifier a source's tools appear under in code (`github`, `linear`). Unique per hub, chosen when the source is added, and stable across refreshes. ### Tool address `.`, how a run's code, policies and journals name a tool (`github.createIssue`). The tool part is the source's own name for it, normalized to a JavaScript identifier. ### Connection One named credential for one source (`github/work`). It holds references to secrets, never their values. A source has zero or more connections and at most one default; code picks another with a call option (`{ connection: "work" }`). Not to be called: account, binding, credential (the credential is the secret a connection points at). ### Policy The rule that decides a tool call: `allow`, `ask` (a person must approve) or `deny`. It attaches to a source or a tool, optionally narrowed to one connection. The most specific rule wins, except that a narrower rule can never loosen a `deny`. Not to be called: permission, guardrail. ### Tool contract The digest of what a tool claims to be (name, description, input and output schemas, annotations), recorded when a person approves the tool. A refresh that changes the digest puts the tool back to `ask` until it is reviewed, so the hub never widens its own authority. The tool-level counterpart of a Shape. ### Index The hub's searchable record of every tool and skill it can serve, built from each source's manifest. `search` reads it. Not to be called: catalog (that is the public listings repo), registry. ### Run One `execute` request's lifecycle: its code, status (`running`, `awaiting_input`, `completed`, `failed`, `cancelled`, `expired`), journal, result and logs. A run can take several sandbox attempts, one per resume. Its id is how the model and the person refer to it. Not to be called: session, job. ### Journal A run's append-only record of tool calls (address, connection, argument digest, outcome) and of the nondeterministic values its code read. Resuming a run replays its journal, so a call that already happened is never made twice. ### Profile A named, curated view of a hub: which namespaces, tools and skills are visible, and whether they are served in code mode or as direct tools. Each profile has its own endpoint. Profiles only curate; they grant nothing and carry no policy. Every hub has a `default` profile. Not to be called: toolkit, scope. ### Sandbox The isolated JavaScript runtime that runs a run's code: QuickJS compiled to WebAssembly on a local hub, a Worker Loader isolate on a hosted hub. It has no network, no filesystem and no secrets; its only way out is the tool bridge. ### Decision A person's answer to one pending tool call: `once`, `run`, `always` or `deny`, recorded with its channel (client prompt, approval page, CLI or dashboard). Never made by the model. Hub text calls asking for one "an approval"; it is distinct from a Shape **Approval**. Not to be called: consent, grant. ## Also used ### Capability One installable unit — an MCP server or a Skill. The Phase 0 contract accepts exactly three shapes: local MCP server (npm, stdio), remote MCP server (HTTP/SSE), and git-hosted skill pinned to a commit. Not to be called: plugin, extension, tool (a "tool" is what an MCP server exposes, not the capability itself). ### Client A coding agent whose config the stack workflow writes. Write-client coverage is defined in ADR-0002; the separate read registry follows ADR-0003. Not to be called: agent (ambiguous with the running LLM session), editor. ### Secret store Where secret values live on a machine: the OS keychain (macOS `security`, Linux Secret Service) with `~/.capabilities/.env` (mode 600) as fallback. Keyed by env var name, shared across capabilities. Values never enter the stack repo; the repo records names only.