Skip to content

Glossary

  • actor — whoever or whatever performed an action: a person or an agent. The escalation log records the actor alongside the decision, so a decision can be attributed rather than guessed. See also AI agent.

  • agent plane — the layer where the agent itself is the thing that must be controlled, not the context it reads. Telling an agent never to push to main is an instruction; a check that refuses the push is a control, and this layer is where those controls live — the required check, the sandbox, the hook that refuses the call. See also AI agent.

  • AI agent — an AI system that acts on a repository rather than only answering: it reads files, edits them and runs commands. It is not a person, and it is not the machine it runs on; what it did is recorded, and what it may do is limited. See also agent plane.

  • architecture — the structure of a system: its parts, the boundaries between them, and the rules about what may depend on what. It is what a change has to fit, which is why a change that ignores it shows up as drift. See also drift.

  • blast radius — how much a failed change can break: one service, one environment, or the whole estate. Progressive delivery is chosen by blast radius, not by fashion. See also canary.

  • blue/green — a rollout that runs the new version beside the old one and swaps traffic to it atomically. It costs double the capacity for a short time; that cost is why it is chosen for changes whose blast radius justifies it. See also blast radius.

  • build artefact — a file a build produces and a later job consumes: a binary, an image, a report. GitHub spells it artifact. See also release.

  • canary — a rollout that sends a small share of traffic to the new version and watches a signal before widening it. A canary with no signal that can judge it is a delay, not a test. See also blast radius.

  • capability — what a system can do for the person using it, stated as an outcome that can be proved: this system can publish a chapter to staging, and here is the evidence. A capability is larger than a feature — several features may be needed before one capability is true. See also feature.

  • catalogue — the list of what exists, each item with its state and the evidence for that state. A capability catalogue says what the system can do and how each claim is proved; a feature catalogue says what is planned, in flight and shipped, and what proves each. A row that cannot cite its evidence is not yet true. See also capability.

  • CD — continuous delivery: every passing change is releasable at any time. Continuous deployment goes one step further and releases it automatically; delivery keeps the release a decision. See also release.

  • checkpoint — a measurement taken at a named point in a piece of work, before the work continues: state what must be true, compute what is actually there, compare, and refuse on the difference. It is not a gate — a gate is a checkpoint given a name, a moment and an environment, and wired to stop the change. Every gate began as a checkpoint someone took by hand. See also gate.

  • CI — continuous integration: every change is built and checked automatically, and the result is visible. Its point is that a break is found in minutes, not in a release — the commit and full moments are CI. See also gate tier.

  • command surface — the part of a tool a person and a script share: the operations it offers, the words and arguments that select them, and what each returns — text, and an exit code that says success, failure or refusal. It is the contract, not the window it is typed into. The industry calls the exposed operation set an API surface; on a command line it is the CLI's commands. See also command-line interface.

  • command-line interface — the typed form of a command surface: you type an operation, its arguments, and read what comes back. CLI is the industry's name for it, and it names the interface only — the commands and their grammar — not the screen, and not the panels a person looks at afterwards. See also command surface.

  • commodity — the part of a system nobody differentiates on, such as transport, storage or mail delivery. You buy it from a provider because the provider competes on it; the parts worth building yourself are the glue and the differentiator — the ones where your behaviour lives. See also the glue.

  • console — an administrative surface: where a person reads a system's state and acts on it. The console is the operator's own; a vendor console is someone else's, and it is where a setting can live that you cannot diff. See also dashboard.

  • contract — the declared shape two independent parts agree on, so either can change without breaking the other. A request shape, an exit code and a version range are a contract; a change that breaks one is a new version, not a patch. See also version.

  • control plane — the repository that governs other repositories: the rules, the manifest and the gates. It is where policy is written, as distinct from the applications that obey it. See also the repository.

  • dashboard — a view that reports state and cannot act: charts, colours, a number per panel. It answers what is happening; a console answers what do I do about it. See also console.

  • decision record — the strategic log of a choice: why this capability, which axes decided it, when it is revisited. It exists so the next reader inherits the reasoning instead of arguing the choice again.

  • deploy · verify · roll back — the three acts of a release: prove the change, prove the system, and design the return before it is needed. A deploy is not finished at upload; it is finished when the check of the deployed system passes. See also release.

  • deterministic — a step whose result is fixed by its input, so the same input gives the same output and the same verdict. A model is not deterministic; the parts around it — a schema, a policy check, the tests — are what decide whether the model's draft is allowed through. See also gate.

  • the door — the identity entrance: who may come in at all. It is not a gate — a gate decides whether a change may proceed, while the door decides whether there is anyone there to ask. See also gate.

  • drift — the distance that grows between what is declared and what is actually running. It appears when configuration is changed by hand, when a document and a repository disagree, or when a check stops being called — and it stays invisible until something compares the two. See also manifest.

  • drill — a restore that was actually run, into an isolated place, with its real duration recorded. A copy nobody restored is a hypothesis; the drill is what turns it into a number you can quote. See also recoverability.

  • escalation boundary — the explicit, checkable division between what an agent may decide and what it must stop for. The conditions are written so the agent can evaluate them before it acts, not after. See also AI agent.

  • estate — everything one person operates: the repositories, services and hosts. It is the whole surface, not the gates, not the tooling, and not one repository. See also portfolio.

  • eval — a scored test of behaviour: a fixed set of cases, run against an agent or a model, with the result compared to a threshold. An eval answers did the behaviour hold; it becomes a gate when a failure is wired to stop the build. See also gate.

  • evidence pack — what a release carries so a reviewer can decide without asking a question: what was verified, what was not, and how to go back. A tag without one asks the reviewer to trust instead of check. See also release.

  • exit drill — the rehearsed act of leaving a provider, performed before it is needed. Restoring the data somewhere else is how you learn whether you could leave; nobody rehearses it during the incident. See also sovereignty.

  • expand/contract — the only migration pattern that survives two versions running at once: add the new shape, write both, backfill, then remove the old. Each phase is its own deploy with its own verification, and removing the old shape in the same deploy removes the way back. See also version range.

  • feature — a unit of functionality that delivers value to a user, and the unit a delivery plan tracks through its lifecycle: planned, in progress, shipped. It is smaller than a capability — one capability may need several features before it is true. See also capability.

  • feature flag — a switch that separates behaviour from code, so a change can ship without being on. It is chosen when the blast radius is controllable by turning something off — and it costs a flag you have to remove later. See also blast radius.

  • fleet — many machines treated as replaceable rather than tended: each has an identity — a name and credential that say which machine it is — and a record; an unhealthy machine is replaced, not repaired, and its history is what survives it.

  • gate — a check a change must pass before it may proceed. It has a name, a moment and an environment, and it is not a report, a dashboard or a notification. See also gate estate.

  • gate estate — all the gates of one organisation, taken as a set. It is a design question — what the set covers, and what it deliberately does not — not a list of checks that accumulated. See also gate moment.

  • gate moment — when a gate fires: atomic (any time, one concern), commit (as the change is committed), full (when the change is complete), scheduled (when the clock decides). It carries a budget — the most time it may take before it stops helping. A moment is when, never where: the environment is a separate question. See also gate.

  • the glue — the integration, policy and approval work that belongs to you rather than to a provider. It is where your behaviour lives, which is why it is the part worth writing yourself. See also commodity.

  • governance machine — a policy applied by a gate, so a violation cannot merge rather than being reported later. The same rule as prose is advice; as a check that fails the merge, it is governance. See also invariant.

  • harness — the program that drives an AI assistant through a task: it routes the work, supplies the context and collects the result. One exchange is not a harness; a harness runs a sequence, which is why it is the thing a gate can be put around. See also AI agent.

  • idempotent — a step that can be run twice and leaves the same result as running it once. It is what makes a setup or a deploy safe to retry, and it separates a command you can run again from one you must not.

  • invariant — the sentence a gate exists to keep true — no credential is committed, every endpoint has a test. A gate without one is a check nobody can justify or retire. See also gate.

  • job — a unit of work executed by one runner. A stage holds jobs; the jobs in a stage may run in parallel, and each job is made of steps that run in order. See also runner.

  • the Law — the non-negotiable rules a repository must always follow: what must always be done, and what must never be. It is small and static, and it is written where the people and the agents both read it. See also the Map.

  • load unit — the set of files one task type needs, named once. A migration change loads the schema contract and the migration gate; it does not load the whole engineering chapter. See also context routing.

  • manifest — a declarative file that describes every repository, its tier, owner, lifecycle and policy. It exists so the set of repositories can be read rather than remembered. See also control plane.

  • the Map — the current state of a repository — how it is built, where the conventions are, what an agent needs to read before acting. It is large and task-dependent, which is why it is loaded by unit rather than in full. See also the Law.

  • observability — the evidence layer: every critical invariant — a rule that must always hold — checked by one piece of logic, with two consumers. The same check that fails a deploy also feeds the status surface, so health has no second source of truth. See also invariant.

  • operator console — the console in its acting sense: one surface that reports the state and changes it, acting only through the command surface. See also console.

  • orchestrator — the person who directs the work rather than typing every change, and in whom every change to the repository finally rests. The agent may read, parse, suggest and execute; the decision that a change lands is the Software Orchestrator's. See also AI agent.

  • pipeline — one executable definition of automated work: stages, each holding jobs, each job made of steps, run on a runner when a trigger fires. A pipeline is one artefact inside a workflow — the workflow is the sequence of work, and it includes the human gates between pipelines. See also stage.

  • plan — the written intent for a piece of work: the outcome, the scope, the steps, the validation, and the conditions that would stop it. It is approved before work starts and retired when the work is done — a plan that stays open after the work shipped is stale, not live.

  • the Playbook — the step-by-step procedures, each with a human approval gate: how exactly to perform a task safely. The Law says what must be true; the Playbook says how, in what order, and where to stop. See also the Law.

  • portfolio — many systems read as one estate rather than one system at a time. The question changes from is this system correct? to what is the state of the organisation?, and the answer comes from a curated file rather than from memory. See also manifest.

  • precedence — the order in which settings from different stores are resolved, when more than one of them sets the same thing. It matters because a platform applies an order whether or not anyone has read it.

  • procedure — the ordered steps of a repeatable change, each with a gate, written as a contract rather than a plan. A failure names the step it happened at because the steps were named in advance. See also the Playbook.

  • prompt regression — a test that re-runs a fixed set of prompts or cases and compares the result with a recorded baseline, so a change that degrades the behaviour fails before release. It is a regression test aimed at a model's behaviour rather than at a function's output. See also eval.

  • provenance — the record of where a change came from: who or what produced it, on top of what, and with whose approval. It turns review from reconstructing authorship into reading intent and evidence. See also evidence pack.

  • recoverability — the difference between a copy and a recovery: a restore that has been run. It is measured by how much data you can lose and how long you can be down, not by whether a backup exists. See also drill.

  • refusal — a designed non-action: the command declines, names why, and exits 2. It is not a failure (exit 1) — a refusal is an answer, and a caller can tell it apart from an error. See also command surface.

  • registry — the one table that declares every verb of a command surface. Help, completion and the dispatch all read it, so the surface cannot advertise one thing and implement another. See also command surface.

  • release — a decision with evidence. The deploy is only its mechanism; the release is where the change, its verification and its way back are judged together. See also evidence pack.

  • the repository — the work, the checks, the rules and the context, and the documents that make all of it readable by a person and an agent alike. A repository that holds code but not its gates, rules or context cannot be operated by anyone who did not write it. See also the Law.

  • roll back / roll forward / neither — the three answers to what if this fails, written before the release. Roll back when the new version is the problem, roll forward when a fix is faster than a revert, and neither when the change cannot be reversed — decided in advance, never during the incident. See also release.

  • RPO / RTO — how much data you may lose (recovery point objective) and how long you may be down (recovery time objective). Both are decisions, cheap to state and expensive to discover; a backup schedule is a habit, while a stated loss bound is an RPO. See also recoverability.

  • runbook — the operational document: when something breaks, what to do. It is not the Playbook — the Playbook is how to perform a task safely in the first place. See also the Playbook.

  • runner — the machine that executes a job: a hosted machine or a self-hosted one. It is execution capacity and a trust boundary; it decides nothing, it runs what the pipeline or the agent gives it. See also job.

  • seam — the integration point where two systems meet — and the place you design so it can be cut. A provider's interface behind an adapter of your own is a seam; the same interface called from forty places is a dependency you cannot leave. See also contract.

  • session continuity — the discipline of making the handoff between sessions explicit, verifiable and repository-owned, so the next session resumes the work instead of reconstructing it. A session is one continuous stretch of work with an agent — it ends when the conversation or the run ends, and everything the agent remembers ends with it. See also procedure.

  • shell — the program that reads the commands typed into a terminal and runs them. A terminal hosts it; the shell is not the terminal and not the console — it is the layer that interprets what is typed. See also terminal.

  • smoke test — the gate that judges the deployed system rather than its address. Pages answer, the primary interaction returns its contract, the data path returns records — the journeys that matter, not one status code. See also gate.

  • sovereignty — the four facts that prove you are not trapped: where the data lives, who can read it, who can move it, and what happens if the provider says no. Answers you can show, not a feeling about a vendor. See also exit drill.

  • stage — a phase of a pipeline that groups jobs: stages run in sequence, and the jobs inside a stage may run in parallel. It is not a gate moment: a moment is when a gate fires. See also gate moment.

  • step — the smallest unit of work in a pipeline: one command or task inside a job, run in order. The build order's Step 1–6 uses the ordinary sense: a move in a procedure. See also job.

  • terminal — the view you already have: the text window that carries input and output. It shows state badly — a week of runs scrolls away — which is why the merged console exists. See also the view.

  • terminal console — the console that lives in a terminal: it shows state and acts, in text. See also console.

  • the three structures — the prompt, the engineering and the workflow — the three things that together decide whether AI-assisted work is usable. A good prompt against a repository with no gates still produces a change nobody can verify. See also the repository.

  • trigger — the event that starts a pipeline: a push, a merge request, a schedule, a tag. A deploy or a release is a trigger too: it starts the check that judges the deployed system. See also pipeline.

  • upstream product — a whole application you deploy and configure, whose behaviour, data schema and upgrade path are its own. You wrap it, patch it deliberately and rehearse its upgrade — unlike a commodity, it carries opinions you inherit. See also commodity.

  • verb — one operation on a command surface, declared in the registry: a noun and an action that a person types and a script calls. It is not a wrapper — a wrapper stands for a vendor command, a verb is the operation itself. See also registry.

  • version — a number that carries a promise about compatibility: what a caller may rely on, and what a change is allowed to break. A version is a promise; the contract is what makes it true. See also contract.

  • version range — the disjoint span of migration numbers a repository owns, so two repositories never write the same version number. An applier can then apply its range without guessing whose change it is. See also expand/contract.

  • the view — whatever shows a person what the command surface knows: a terminal, a dashboard, a console. A view renders state; it must not own behaviour, because a view that acts is a second implementation of the operation behind it. See also command surface.

  • workflow — the sequence of steps through which work passes: what happens, in what order, and what decides each step. It is broader than any platform's file — a workflow includes the human gates and the review between pipelines. See also pipeline.

  • workflow file — the file in which a platform defines its automated work: GitHub's workflow, GitLab's pipeline configuration. The artefact, not the sequence of work. See also workflow.

  • wrapper — a verb that stands for a vendor command, kept for policy or for effectiveness. It is not a reimplementation: the vendor's tool still does the work, and the wrapper decides when and how it may be called. See also verb.