Glossary
Terms are grouped by area. Each heading is a stable link target, so the console can point at a definition from the page where the term appears.
Workspace and services
Section titled “Workspace and services”Platform account
Section titled “Platform account”The account you sign in to Helmhive with by default, identified by a verified email address. A workspace can add Company SSO (its own OpenID Connect provider) as an alternative or a requirement; see Configure sign-in.
Recovery owner
Section titled “Recovery owner”The workspace Owner whose platform-account sign-in always keeps working, even when the sign-in policy requires Company SSO, so the workspace can never lock itself out.
Workspace
Section titled “Workspace”The tenant that owns services, people, settings, runners, and the audit trail. Workspace roles (Member, Administrator, Owner) apply to the workspace itself, not to individual services.
Repository source
Section titled “Repository source”A Git provider identity, a Gitea bot or a GitHub App installation, whose permissions define which repositories Helmhive can discover. Connecting a source creates candidates; it does not enroll any repository. See Connect a repository source.
Repository candidate
Section titled “Repository candidate”A repository a source can see. It carries the provider permission and the detected capabilities that form the ceiling for any service enrolled from it. Its access state is accessible, archived, or lost.
Service
Section titled “Service”An explicitly enrolled repository with its own execution policy, environments, people, and activity. Service roles (Requester, Developer, Administrator) are assigned per service and do not follow from workspace roles. See Enroll a service.
Execution policy
Section titled “Execution policy”The revisioned, content-hashed document that defines how a service may be worked on: repository root, approved commands, protected paths, expected checks, environments, links, and enabled AI capabilities. Every change appends a new revision; revisions are never edited.
Capability
Section titled “Capability”An explicit permission the server grants for one operation, such as creating a change request or approving a deployment plan. The console shows or hides controls based on capabilities, and the server checks the capability on every request regardless. See Roles and capabilities.
Operator
Section titled “Operator”The team that deploys and runs your Helmhive installation and its runner hosts. For installations managed by Wavyzz, that is the Wavyzz team. Operators hold what lives on hosts (bootstrap secret, runner images and deployments, provider logins, email, the execution gate) and have no standing authority inside your workspace. See Before you begin.
Support grant
Section titled “Support grant”A named, expiring grant that lets one platform operator read the audit trail or administer the workspace. Created only by a workspace Administrator or Owner, never by the operator.
Changes
Section titled “Changes”Change request
Section titled “Change request”A Requester’s title and desired outcome for one service, plus their own confirmed success criteria and clarification thread. It is the input to planning and remains visible for the life of the change.
Success criteria
Section titled “Success criteria”Measurable outcomes, one per line, that the original requester confirms before planning can start. A Developer may ask the AI to draft them, but only the original requester confirms.
Exact plan
Section titled “Exact plan”An immutable implementation plan bound to a repository and base commit, service-policy revision, execution environment revision, affected paths, checks, scope, assumptions, risks, rollback text, expiry, and a hash of all of it. Approval always refers to one exact hash, so any change to the inputs makes the plan stale.
Approval
Section titled “Approval”A recorded decision bound to one exact, current plan. Approving an implementation plan, a deployment plan, and a rollback plan are three separate permissions, and approval never merges, releases, or deploys by itself.
Independent review
Section titled “Independent review”A separate runner job, preferring a different provider and always using fresh context, that evaluates the patch and check evidence. It approves only with an approve verdict, every check passing, and no blocking finding.
Broker
Section titled “Broker”The server-side component that opens the pull request with a separate bot credential. It revalidates every authority, fetches the exact base, applies the patch, refuses files outside the plan, and opens one deterministic pull request.
Bounded evidence
Section titled “Bounded evidence”The limited, hashed record Helmhive keeps of what a runner did: commands and exit codes, output hashes, review findings, and timeline events, capped in size and redacted at the write boundary. Raw transcripts and secrets are never stored as evidence.
AI delivery
Section titled “AI delivery”Provider
Section titled “Provider”The AI service a runner talks to: Codex or Claude, and Hermes when its adapter is installed. A runner serves exactly one provider and holds that provider’s login on its host.
Provider adapter
Section titled “Provider adapter”The runner-side integration for one provider. It is versioned; a runner whose adapter version differs from what the control plane expects is rejected. Not to be confused with a deployment adapter.
Provider turn
Section titled “Provider turn”One request against a runner’s provider subscription. Every AI job, connection test, and validation run consumes turns; heartbeats do not.
Runner
Section titled “Runner”An isolated process that performs AI work for one workspace. It connects outbound over HTTPS, keeps its provider login local, and reports the provider, models, capabilities, labels, and execution environment it offers. AI runners and deployment runners are separate trust domains.
Envelope
Section titled “Envelope”The immutable, code-defined maximum for one kind of job: tools, filesystem access, output contract, required capabilities, labels, and network policy. Profiles narrow envelopes and never expand them.
Execution profile
Section titled “Execution profile”A named, revisioned configuration that gives a job its purpose, instructions, provider model mapping, reasoning effort, tool and output policy, session continuity, memory scope, and required labels. See Configure profiles and models.
Execution environment
Section titled “Execution environment”The immutable toolchain a runner guarantees: an image pinned by digest, one platform, a bounded list of executables, an ephemeral filesystem, and no direct network access from commands. See Execution environments.
Revision
Section titled “Revision”One published version of an execution environment, an execution policy, a profile, or a deployment environment or connection. Services and plans bind to exact revisions; revisions are never edited.
Descriptor
Section titled “Descriptor”The exact content of one execution environment revision: image digest, platform, sorted tool list, ephemeral filesystem, and no command network. Its hash is the fingerprint.
Fingerprint
Section titled “Fingerprint”The hash of an execution environment’s canonical descriptor. The console shows a shortened fingerprint next to a runner so you can confirm it matches the revision a service expects.
Binding
Section titled “Binding”A recorded link: a service to an environment revision, or a profile, runner, and scope to a provider session. Resetting a session binding forces the next job to start fresh.
Placement constraints
Section titled “Placement constraints”Labels that steer work to compatible runners, such as domain:code or environment:production.
Labels route work; they never grant authorization.
Memory scope
Section titled “Memory scope”Whether a job receives the workspace’s curated memory records, only the records for one service, or none. Governed change jobs always run with none.
Session continuity
Section titled “Session continuity”Whether a job starts a fresh provider session, resumes the previous one, or forks it. Governed change planning, implementation, and review always start fresh.
Registration token
Section titled “Registration token”A one-time, short-lived token shown once when a runner is registered or its login rotated. The runner exchanges it for its own revocable credential; Helmhive stores only a hash.
Deployment
Section titled “Deployment”Deployment runner
Section titled “Deployment runner”An isolated, outbound-only process that executes deployment adapters. Its SSH, encryption, registry, cloud, and platform credentials stay on its host; it publishes adapters, labels, and authority aliases.
Authority alias
Section titled “Authority alias”A runner-local name for a credential or target that a deployment runner publishes to the workspace. Connections bind to an alias and revision without the workspace ever seeing the secret behind it.
Runner-local
Section titled “Runner-local”Anything that exists only on a runner host and never enters the control plane, prompts, API responses, or audit details: credentials, keys, and the values behind an authority alias.
Connection
Section titled “Connection”The non-secret configuration a deployment adapter needs to act, bound to one authority alias and revision. Its states are Pending, Ready, Error, and Disabled; every status change increments its revision.
Deployment environment
Section titled “Deployment environment”One destination for one service: a tier (development, staging, production), a revisioned workflow of adapter steps, its connections, required runner labels, and an approval window. See Create a deployment environment.
Adapter
Section titled “Adapter”One typed deployment operation, such as running an Ansible playbook or checking an HTTP readiness endpoint. Each adapter declares its category, risk, required tools, and whether it supports verification and rollback. See the adapter catalogue.
Release
Section titled “Release”The immutable description of what to deploy: a version, a source commit, and named artifacts with digests, attached to a plan.
Trusted provenance
Section titled “Trusted provenance”Facts about a release that server-side connectors verified and hashed: the observed commit, the CI run that produced the artifact digests, and the registry manifest for each digest. Required outside the sandbox before a run can be queued.
Mutation boundary
Section titled “Mutation boundary”The event a deployment runner records before its first mutating step. After it, no outcome is guessed: any interruption produces Reconciliation required.
Reconciliation
Section titled “Reconciliation”The immutable decision an administrator records after verifying a remote system whose deployment outcome could not be proven: an observed outcome, an evidence reference, and a reason. See Reconcile an uncertain run.
Execution gate
Section titled “Execution gate”The server-side allowlist, adapter set, and production switch, controlled by the people operating your installation, that decides which approved plans may actually execute.