Glossary
This glossary is the source of truth for Infrared's vocabulary. The app, the API, ir, these docs and the AgentRoles all use these terms, and only these terms. When a word you are about to write is in the "never say" column, use the term beside it instead.
Change management
| Term | Meaning | Never say |
|---|---|---|
| Product | What Infrared builds, deploys and manages change for: one or more repos that are deployed and released together. The Product resource. | project, app (when you mean the whole Product), service |
| Change | One unit of work on its way to production: a request plus the pull request that carries it out, whoever wrote it. A Change's page is the page of the AgentWorkflowRun that carries it. | ticket (for the whole unit), task, job |
| request | The issue a Change works on, in the words it was asked in. Changes opens on the requests, grouped as Waiting for you, In progress, Done and Stopped. | ticket, story |
| Changes | The page that lists every change in an org, on the rail at /changelog, and the Changes tab of each Product. It opens on Requests and has a second view, Every entry, the log of every agent run, merge, approval, build, deployment and rollback, newest first. Pull requests and pushes made outside Infrared aren't listed. The API's changelog operations and the /changelog address keep that name. Not a repo's CHANGELOG.md. | Changelog (in UI text), change log, audit log, activity feed, history page |
| backlog | A Product's open issues headed for production, each in a column by its infrared: label on the forge: Backlog, Arch reviewed, Todo: human, Todo: agent, Doing and Done. Ask for a change on a Product's Changes tab adds to it and starts the issue's Change. | sprint board, kanban (in UI text) |
| hydration | The architect's first pass on a new request: it adds acceptance criteria, design notes, a verification plan and an estimate, then moves the issue to Arch reviewed. | grooming, refinement |
| triage | The human gate after hydration where a person decides who builds a request: Todo: agent hands it to the agents, Todo: human hands it to a person and ends the Change. | intake, routing |
| Deployment | One version of a Product on its way through its environments: built by kpack, tagged with the next patch version, then promoted zone by zone, each zone watched by its release guard. A merged Change starts one on its own, and Start a deployment starts one by hand. Its phase is Pending, Building, Tagged, Promoting, AwaitingApproval, Released (Deployed in the app) or Failed. Deployments on the rail lists them. The API calls it a Release: the kind, its paths and its fields keep that name, and ir deployment works with them. Not a Kubernetes Deployment, which these docs always call by that full name. | release (for a deployment), version bundle, drop |
| Release | A release cut: the deployments of a Product that reached production since the last release, gathered under one version, with release notes for engineers and a post for everyone else. Releases on the rail lists them. The ReleaseCut resource; its phase is Pending, Tagging, Publishing, Released or Failed. | deployment (for a release), version bundle, drop, sprint |
| track | A release's major.minor version: the 1.6 release is every patch under 1.6. A Product's Releases tab lists its tracks, each with the deployments that reached production under it. | branch, line |
| cut | Make a release. An org admin opens Announce on the Product's Releases tab: Announce 1.6 writes the notes onto the GitHub release of the version production runs, marks it latest and sends the post; cutting the next minor or major also tags the commit and the image running in production with that version. Either one sends release.cut once. ir release cut. | cut (for starting a deployment), tag (for the whole cut) |
| release nudge | The note on a Product's Releases tab that says how many changes reached production since the last release, by kind, and suggests announcing the track when there is enough to tell. | reminder, alert |
| AgentRole | A defined job an agent performs: its mission, triggers, evidence, guardrails, permissions and the org's opinions. The AgentRole resource. | persona, bot, agent type, skill |
| AgentWorkflow | An ordered set of steps (AgentRoles, human gates, promotions and automatic actions) that a Change or a scheduled job moves through. The AgentWorkflow resource. Column heads may shorten it to "Workflow". | pipeline, flow definition, playbook |
| AgentWorkflowRun | One run of an AgentWorkflow, with each step's phase, verdict, usage and evidence. The AgentWorkflowRun resource. Column heads may call it "Change". | pipeline run, job run, execution |
| Opinion | A named, editable piece of guidance inside an AgentRole that an org can change or switch off. | rule (unless it is enforced), prompt |
| Verdict | A step's final word, such as VERIFIED, CHANGED, MERGE WITH FOLLOW-UPS or BLOCK. Stored in capitals; the app shows it in sentence case (Verified, Changed) on the step's verdict card. | result, score |
| Evidence | A proof a step captures and attaches to its AgentWorkflowRun: a screenshot, video, report, log, comment, diff, SARIF file, metric or document. A deployment also keeps a screenshot of each zone it reaches, taken once the zone passes its smoke check. | artifact (ambiguous), attachment |
| guidance | What a person tells an agent when they retry a step, such as the answer to a question the agent stopped to ask. The step sees it in its prompt. | prompt (for guidance), hint |
| Dead-letter | Hand work an agent cannot finish to a named person, with the run paused at that step (phase DeadLettered). | fail silently, drop |
| summary video | A short narrated video of a Change that finished or stopped and needs a person, on the Change's page. Each org also gets a weekly video of the last seven days across its Products, at the top of Products. | recap, reel |
| Catalog | The default set of AgentRoles, AgentWorkflows and Teams seeded into every new org, versioned (for example v0.29.0). Not the gitops catalog. | template library |
| Tailoring | Rewriting an org's AgentRoles from analysis of its repos. Planned; an AgentRole already records whether it was tailored. | fine-tuning |
Workforce
| Term | Meaning | Never say |
|---|---|---|
| Workforce | The rail item where an org's people and agents are, in four views: Teams, People, Agents and Access groups. | org chart, directory, staff |
| Team | Where people and AgentRoles work together under one discipline: a charter, a manager, its people, its AgentRoles, and the Products it owns or contributes to. Every org starts with the catalog's default Teams. A Team grants nothing and is not an access group. The Team resource. | squad, group, access group (for a Team) |
| person | Someone in an org, on Workforce → People: their name, job role, manager, handles and Teams. The Human resource. Being listed grants nothing; access comes from access groups. | user (for a person on Workforce), employee, member (for a person) |
| Agents | The Agents view of Workforce: the org's AgentRoles and AgentWorkflows, each AgentRole in its Team's colour. | bots, assistants |
| You | Your own page, opened from your name at the foot of the rail: your profile, avatar, linked accounts, availability and preferences, and how you signed in. | profile page, account page |
Tenancy
| Term | Meaning | Never say |
|---|---|---|
| org | The tenancy and RBAC boundary in Infrared. Each org's resources live in the namespace ir-org-<org>. The Organization resource. | tenant, workspace, account |
| platform org | The one org that administers the control plane itself, created by the setup wizard. | root org, admin tenant |
| access group | A group of people inside an org with one role: the people of its Workspace group, and people by GitHub login. It grants a role and nothing else. spec.accessGroups on the Organization. | team (for an access group), squad |
| role | What an access group's members may do in an org: platform-admin (platform org only; every org), org-admin, member or viewer. | permission level, access tier |
| cluster allowlist | The workload clusters an org may place zones on, set by a platform admin. spec.clusterAllowlist on the Organization. | cluster quota, cluster permissions |
Identity and access
| Term | Meaning | Never say |
|---|---|---|
| platform admin | Anyone with every role in every org: the root user, the people of a platform-admin access group of the platform org, the root user's and the chart's API tokens, and, until a platform-admin access group's Workspace group resolves someone, anyone who signs in with Google from an allowed domain. | superuser, root (for a platform admin other than the root user) |
| root user | The install's first platform admin, made by the setup wizard: a break-glass account that signs in with its email and a password kept only in a vault outside Infrared. The BreakGlass resource named root. | admin account, superuser |
| break glass | Signing in as the root user when people can't sign in with Google. Also Access → Break glass: where the root password lives, the group of people who should be able to open that vault, and every use. | backdoor, emergency login |
| allowed domain | A Google Workspace domain whose people may sign in with Google, set by a platform admin in Settings → Sign-in. spec.signIn.google.allowedDomains on the Installation. | whitelist, trusted domain |
| Workspace group | A Google Workspace group, by its address, whose people hold an access group's role when they sign in with Google. spec.accessGroups[].googleGroup on the Organization. | mailing list, distribution list |
| GitHub team | GitHub's own team, in an org's GitHub organization, that Infrared keeps in step with one of the org's access groups. spec.accessGroups[].githubTeam on the Organization. GitHub teams also serve as ownership and escalation handles like @platform/reviewers. | team (alone, for the GitHub one) |
| Infrared user | A person who signs in with Google, as Infrared knows them: their Google account and their linked accounts. The User resource, named google-<subject>. A person on Workforce points at their Infrared user once they have signed in. | profile, account (for the Infrared user) |
| linked account | A person's account on a forge, linked to their Infrared user through a git connector. A linked GitHub login is for git, not for signing in. | connected account, alias, identity |
| git connector | A forge, at an address, that people link their accounts on, and how Infrared reaches it: an org's GitHub App, an OAuth application, or the install's Gitea. The GitConnector resource; not an org's GitProvider. | integration, git provider (for a connector) |
| forge | A git server that people and Infrared work on: GitHub, GitLab or Gitea. | SCM, code host |
| API token | A bearer token for ir, CI and MCP clients, minted on the You page. It acts with the roles of the person who minted it. | API key (for an Infrared token), PAT |
| sign-in link | A link that opens a browser session as an API token's owner, once, within 60 seconds. ir open makes one. | magic link |
| Access | Where platform admins see and change who signs in and how: People, Access groups, Git connectors and Break glass. | admin panel, user management |
Clusters and gitops
| Term | Meaning | Never say |
|---|---|---|
| management cluster | The cluster Infrared runs on. It runs Argo CD and manages itself and every workload cluster. | hub, control cluster, admin cluster |
| workload cluster | A cluster that runs Products' zones, managed from the management cluster. | spoke, child cluster, runtime cluster |
| cluster template | A tagged module in infrared-iac-modules that builds a cluster: gcp/gke-cluster (GKE on Google Cloud) or aws/eks-cluster (EKS on AWS). | blueprint, cluster recipe |
| gitops repo | An org's git repo that holds the desired state of its clusters and Products. Infrared creates, hydrates and bootstraps it. The GitopsRepo resource. | config repo, deploy repo, manifests repo |
| gitops catalog | The component definitions (cert-manager, kpack, Argo CD and others) that the gitops template hydrates into a gitops repo. Not the AgentRole catalog. | charts folder, addons |
| registry | The registry/clusters/<cluster>/ tree in a gitops repo: one folder per cluster listing the Applications that cluster runs. | inventory, cluster list |
| cloud account | A Google Cloud project or AWS account an org gives Infrared, reached through a role or an impersonated service account, never a key. The CloudAccount resource. | cloud credentials, cloud key |
| container registry | Where images are pushed and pulled from, such as Amazon ECR or Artifact Registry. In Settings → Registries, one in an org's own cloud account. The Registry resource. Not the gitops repo's registry/ tree. | image repo (for the whole registry) |
| build registry | The container registry an org's Products build into: one of its registries, or the install's default. | push target |
| app-of-apps | The Argo CD pattern where one root Application points at the registry and creates every other Application. | root chart, umbrella app |
| Application | An Argo CD Application: one component or Product zone synced from git to a cluster. Capitalized. | app (lowercase, for the Argo object), deployment (for an Application) |
| AppProject | An Argo CD AppProject: the boundary for which repos and clusters a set of Applications may use. | project |
| sync wave | The Argo CD ordering annotation. Lower waves sync and become Healthy before higher waves start. | phase, stage, order |
| Synced / OutOfSync | Argo CD's sync status: whether the cluster matches git. Always verbatim, with an icon and the word. | in sync, drifted, up to date |
| Healthy / Progressing / Degraded / Suspended / Missing | Argo CD's health status, verbatim, with an icon and the word. | green, red, broken, OK, down |
| environment | A class of zones with the same purpose: Pre-production or Production. In a Product's spec.delivery.zones[].environment they are pre-release and release. A Product's Environments tab shows one tile per zone, titled by its environment. | stage, tier |
| Pre-production | The environment for zones that run candidates, such as <product>-rc. Deployments arrive automatically by default. pre-release in the spec. | staging, dev, Pre-release (in UI text) |
| Production | The environment for zones that serve users. Deployments arrive after approval by default. release in the spec. | prod (in UI text), Release (for the environment) |
| zone | One running instance of a Product on a cluster, such as zippy-rc or zippy-prod, belonging to an environment. Its name is its namespace. | namespace (for the zone), stage |
| instance | A zone's settings, on the Settings tab of its tile on a Product's page: its address, promotion, capacity and storage. Remove this environment deletes the zone. | (none) |
| address | Where a zone answers: its address on the platform domain plus any names under the org's domains. Who can open it is Signed-in only or Public. | URL (for the setting), route |
| Domain | A DNS name an org can put zone addresses under: its own domain, verified by a TXT record, or a subdomain Infrared manages. The platform org's domains can be shared with every org. The Domain resource; see Settings → Domains. | custom URL, vanity domain |
| promotion | Moving a Product's pin from one zone to the next through a pull request: one step of a deployment. Deployments arrive Automatically or After approval. | deployment (for one promotion), push, pin PR |
| rollout | How far a deployment has reached across a Product's zones. | deployment percentage |
| smoke check | A check that must pass after Argo CD reports a zone Healthy, before the deployment moves on to the next zone. spec.delivery.zones[].verify. | health check (for this), test |
| pin | An exact image reference, tag@sha256:<digest>, recorded in the gitops repo and changed only by a pull request. | version (alone), latest, floating tag |
| isolated delivery | The default delivery: each deployment ships one repo's image, pinned into each zone's chart. | single delivery |
| umbrella delivery | Each deployment is one version of the Product's umbrella chart, with every repo's image; a repo without a new build is carried, and every environment deploys that chart version. Any Product can use it (spec.delivery.strategy: umbrella); Infrared itself is delivered this way. See Deliver several repos as one chart. | bundle, monorelease |
| carried | A component an umbrella deployment keeps at the previous deployment's pin because it has no new build. Its opposite is changed. | skipped, unchanged (in UI text) |
| release guard | What watches a zone after a deployment reaches it: health, its checks, its SLOs' error budget and its hold. A zone that fails it is rolled back to what it ran before (rollback: rollback, the default for new zones) or reported and left on the new version (rollback: notify). Infrared's own upgrade is always rolled back. spec.delivery.zones[].guard. | canary, health gate |
| rolled back | A zone the release guard gave back what it ran before a deployment, through a pull request to the gitops repo, after the zone failed its guard. Images only: data stays as the failed version left it. | reverted |
| hold | How long the release guard keeps a deployment in a zone, Synced and Healthy with its checks passing and its error budgets read, before it moves on: 5 minutes unless the zone's guard.hold says otherwise. Go now ends it early. | bake time, canary |
| Guarded, Fast | How an environment deploys. Guarded, the default, holds each deployment for the zone's hold while the release guard watches it. Fast has no hold (guard.hold: 0s): once the zone is Synced and Healthy and past its smoke check, the deployment moves on, and nothing reads its error budgets or rolls it back on its own after that. Set on the environment's Settings tab, under Promotion. | canary (for Guarded), unguarded (for Fast) |
| Go now | Ending a zone's hold before its time, from the deployment's page or with ir deployment go. The release guard still reads the error budgets and runs the checks once more, then moves on, and can still fail the zone. Who pressed it and when are recorded on the zone's guard (wentAheadBy, wentAheadAt). | skip, override, force |
| metaphor | The sample app Infrared uses to demonstrate and test delivery end to end. | demo app, hello world |
Observability
| Term | Meaning | Never say |
|---|---|---|
| SLO | A service level objective on a Product: an indicator, an objective and a window, measured per zone, with an error budget. spec.slos on the Product. | SLA (for an objective), uptime target |
| Incident | Something wrong in a Product's zone that people are handling: Open, Acknowledged or Resolved, opened by an alert or by a person. The Incident resource. | ticket, outage (for every incident) |
| status page | A Product's page of its zones' state (its Production zones unless spec.statusPage.zones names others), objectives and recent incidents, at /status/<org>/<product>. Signed-in users only, unless spec.statusPage.public is set. | health page, uptime page |
| DORA | Deployment frequency, lead time for changes, change failure rate and time to restore, per Product, on the Product's Environments tab and across every Product at the top of Products. | velocity |
| week in review | The band at the top of Products: the week's story across every Product, the people behind it, what stands out, the activity chart, the weekly video and the week's figures against last week. | dashboard (for the week in review), digest |
Licensing
| Term | Meaning | Never say |
|---|---|---|
| license | A token signed by darkshift, starting irl1., that names the customer, plan, limits and expiry. Without a valid one, an install runs fully until the open beta ends and then pauses. | key (alone), activation code |
| license state | licensed, trial, grace or paused: what the install may do now, from the installed license and the time. | evaluation, locked |
| open beta | How Infrared 0.1 is provided: free, with no license needed, through November 30, 2026 (UTC), the same date for every install. Until it ends, an install with no valid license runs fully, with no limits, in license state trial; after it, such an install is paused. Nothing is billed during it. Later releases need a license bought from darkshift. | free trial, trial (for the open beta) |
| trial | The license state of an install with no valid license during the open beta. Everything works, with no limits. The app calls it Open beta. | evaluation, demo mode |
| grace | The days after a license expires, until the later of 7 days after it expired and the end of the open beta. Everything works, and a banner says how many days are left. | overdue |
| paused | The state after the open beta ends with no valid license, or after the grace ends: new agent steps and promotions to Production zones wait for a license. Everything else keeps working. | locked, disabled, suspended (Suspended is an Argo CD health status) |
Backups
| Term | Meaning | Never say |
|---|---|---|
| backup | One encrypted artifact of an install, written to object storage outside its cluster and named by its UTC stamp, such as 20261006T010500Z. | snapshot (for a backup) |
| point | A complete backup that a mirror run of the object store followed. A restore brings a point back whole. | restore point, checkpoint |
| recipient | An age public key (age1…) each backup is encrypted to. Any one recipient's private key opens a backup. | backup password |
| restore | Bringing an install back from one point onto new servers, before Infrared runs there. | recovery (for a restore), rollback |
Build (kpack)
| Term | Meaning | Never say |
|---|---|---|
| builder | A kpack builder: the ordered buildpacks and stack used to turn source into an image. | build image, Dockerfile |
| ClusterStore | A kpack resource listing the buildpacks available to builders cluster-wide. | buildpack registry |
| ClusterStack | A kpack resource naming the build and run base images. | base image set |
| Image | A kpack Image resource: one app's source-to-image definition. kpack rebuilds it when source, buildpacks or the stack change. Capitalized when you mean the resource. | build config, job |
Runner pools
Runner pools are not part of Infrared 0.1. Agent steps in 0.1 run as runner Jobs in the management cluster. The terms are kept here because the code and the API still use them.
| Term | Meaning | Never say |
|---|---|---|
| runner pool | Room on one person's machine for an org's agent steps: how many VMs at once, which RunnerTemplates and which step modes. Its node agent leases the work. The RunnerPool resource. | worker pool, fleet, farm |
| RunnerTemplate | What an AgentVM is made from: the runner image by digest, its CPUs and memory, its network, and the folders an ad hoc agent may mount. The RunnerTemplate resource. | flavor, VM image |
| AgentVM | One VM on a runner pool that runs one attempt of an agent step, or one ad hoc agent. Its phase is Pending, Leased, Running, Succeeded, Failed or Lost. The AgentVM resource. | sandbox, pod, container (when you mean the resource) |
| node agent | The process on a runner pool's machine that leases AgentVMs, runs each as a VM, sends a heartbeat with its stats and reports its result. | daemon, worker |
| lease | A runner pool's hold on one AgentVM. Exactly one pool wins it; every heartbeat renews it, and five minutes without one make the AgentVM Lost and run its step again. | claim, lock |
| placement | Where an org's agent steps run: jobs, as runner Jobs in the management cluster (the default), or pools, as AgentVMs on runner pools. The Organization's spec.agentSteps. | scheduling, routing |
Components
| Term | Meaning | Never say |
|---|---|---|
| Infrared | The control plane as a whole. | the platform (as a name), IR |
| infrared-operator | The controllers and CRDs. The CRDs are Infrared's data store. | backend, server |
| infrared-api | The REST API at /v1, described by OpenAPI. | backend |
infrared-cli (ir) | The command-line client. | tool |
| infrared-mcp | The MCP server over infrared-api. It gives agents read-only access to Infrared. | plugin |
| code index | The search index of an install's code: its own repositories and the open-source ones it runs on, each at named commits, read through the code_ tools and cited as repo@commit:path:L<start>-L<end>. Optional; see Code index. | code search engine, RAG |
| knowledge repository | The git repository that is the code index's record: its manifest of repositories and refs, and its repo cards. | knowledge base |
| repo card | A short page about one repository at one commit, in the knowledge repository, which code_card returns and marks stale once the ref moves past that commit. | README (for a card) |
| infrared-runner | The process that runs one AgentRole step of an AgentWorkflowRun in a Kubernetes Job. | worker, executor |
| setup wizard | The seven first-run steps in the app that take a fresh install to Ready. | onboarding, installer |