Skip to content

Glossary

Audience: anyone. This exists because the project has accumulated a vocabulary, and most of it is not guessable from the words.

Where a term means something else in the wider industry, that is called out — those are the ones that cause trouble, because people do not ask about a word they are confident they already know.

If you read only five

These five carry most of the others.

Term In one line
Harness The reusable half that Red Alpha owns and licenses. Runs agents, enforces the rules, writes the log. Knows nothing about any particular customer.
Tradecraft The customer's half. Their judgment about what is suspicious and what to do about it, written as data the harness reads — never as code inside it.
Tier (T0–T3) How much a machine may do on its own, from look only to act alone. Earned, not configured.
OT Operational technology — the physical plant. Power, cooling, building controls. The things that, if an agent gets it wrong, stop being a computer problem.
Verdict What the customer's rules concluded about an alert. A function of their playbook and the facts — the model does not decide it.

The two layers

The whole product rests on one split, so these matter more than their length suggests.

Harness · also platform
The Red Alpha–owned, reusable software. Agent orchestration, the policy engine, the
tool gateway, the audit chain, the model router. It is the same software for every
customer and contains no customer content. Lives in platform/.
Elsewhere: "harness" usually means test scaffolding. Not that.
Tradecraft
A customer's accumulated professional judgment — what counts as suspicious, which
assets matter, how bad it is, what to do. Held as declarative data in tradecraft/,
loaded at runtime, never compiled in.
Elsewhere: in security, "tradecraft" more often means the attacker's methods. Here it means the defender's.
The boundary
The line between those two. Enforced contractually and mechanically: customer judgment must be expressible in a playbook, and platform code must never name a tenant, threshold, asset class or detection rule.
Boundary check
tools/boundary-check/boundary_check.py. Derives forbidden terms from the committed tradecraft and fails the build if any appears in platform/. Runs in CI. It is the reason the boundary is a fact rather than an intention.
Playbook
One scenario's worth of tradecraft, as a YAML file validated against schema/playbook.schema.json: what to enrich, what the rules are, how severe, what responses are permitted, what evidence is required.
Swap test
Run the same alert against two customers' playbooks and get two different verdicts, with no change to the platform. The demonstration that tradecraft really is data.

Autonomy and the approval gate

Tier
How much a machine may do without a person. Ours are T0–T3.
Tier Name What it means
T0 Observe Read and analyse. No actions at all.
T1 Recommend Propose an action with evidence. A person acts, outside the harness.
T2 Approve-to-act The agent executes, but only after a person approves, and only within set limits.
T3 Autonomous The agent acts alone — pre-approved, reversible, low blast radius actions only.
Elsewhere: the industry often uses an AL1–AL4 autonomy scale. Ours is a different scale with different boundaries; do not map them one to one.
Approval gate
The point where a state-changing action stops and waits for a person. Nothing reaches the estate before it.
Earned autonomy · the autonomy ledger
A tier is not configured, it is earned. An action type moves up only after a record of clean runs, and one failure demotes it immediately. The ledger is where that record lives.
Blast radius
How much a single action can affect. A bounded action touches one named account; an unbounded one could touch an entire estate. T3 is reserved for small radii.

IT, OT, and the seam between them

IT
Ordinary computing: identities, endpoints, networks, cloud, email.
OT · operational technology
The physical plant — power distribution, cooling, building management systems, SCADA, PLCs. The distinction matters because the consequences differ in kind, not degree.
Asset class
What kind of thing a target is — it, ot, or unknown — according to the environment's inventory. Never according to a playbook: a customer cannot declare that something is not operational technology.
OT adjacency
Different from asset class, and the two are easy to confuse. An ordinary IT account
is OT-adjacent when it has a reachable path toward operational technology. That is
a fact about reachability, and whether it matters is the customer's judgment,
expressed in their playbook.
The short version: adjacency can raise severity; asset class caps the tier. One is their call, the other is not.
The OT cap
No agent may act on an OT-classified asset. Capped at T1 regardless of what a playbook asks for, enforced in platform code, and not configurable downward.
Seam · seam detection
The crossing point from IT toward OT, and catching an attack as it moves across it. A first-class use case rather than a feature.
Jump host
The brokered, allow-listed hop that is the only path from IT to OT. In the lab environment the platform genuinely has no route to the OT host, so a seam check must go through it.
Fail closed
When something is unknown, choose the more cautious answer. An asset the inventory cannot classify is treated as OT. Not knowing what something is must never be safer than knowing.

What happens to an alert

In order, which is also the order the audit chain records them.

Alert
Something arrived that might matter. The input.
Incident
One alert's journey through the harness, and everything learned along the way.
Enrichment
Gathering the facts the playbook asks for — the sign-in, the account's normal pattern, the device, reachability. All read-only.
Fact
One retrieved value a rule can test, named like signin.country.
Rule
A customer's condition for reaching a conclusion. All conditions must hold.
Context set
A named group a subject may belong to, defined by the customer — for example "accounts that can reach operational technology".
Verdict
The conclusion: a classification, a severity, which rules matched, which could not be evaluated, and what responses are permitted. A deterministic function of the playbook and the facts. This is the sentence the whole design rests on.
Classification
What the customer's rules concluded this is. The vocabulary is fixed by the
playbook schema — benign, suspicious, likely_compromise, inconclusive — and
a playbook naming anything else is refused at load.
The split is worth being precise about, because it is the boundary in miniature: the words are the platform's, so that two organisations' verdicts can be compared and the console can render them. Which word a given situation earns is entirely the customer's, and so is what silence means — one example playbook calls an unmatched alert benign and the other calls it inconclusive.
Severity
How urgent. Like classification the scale is fixed by the schema — info, low, medium, high, critical — and where a situation lands on it is the customer's judgment, set by their default and moved by their modifiers.
Proposal
What the model suggested — a narrative, a recommended action, the evidence it cited. Treated as untrusted input and re-checked before anything happens.
Recommendation
A proposal that survived review, bound to the tier the playbook allows.
Capability
A named thing the harness can do, written <domain>.<object>.<verb> — for example identity.signin.read or identity.account.disable. A published contract: names are never changed, because a customer's tradecraft refers to them.
Response
An action a playbook permits for a scenario, with a maximum tier. An action the playbook does not list can never be proposed — by the model or by a person. Omission is a control.
Evidence requirement
The facts a customer insists on before any recommendation is offered. Missing one withholds the recommendation rather than qualifying it.

Incident states, as they appear on screen

State Meaning
awaiting_approval A state-changing action is proposed and waiting for a person. Nothing has been touched.
recommended_only Capped at recommend. No agent will act, and no approval can unlock it.
evidence_only No action proposed, or the proposal was refused. The findings still stand.
denied Policy refused outright.
approved A person approved; execution is under way.
executed The action ran, bounded to its target.
rejected A person declined. Nothing happened.
halted The kill switch was engaged. No further work was started.

Why an incident ended where it did, as the log names it

These appear as rule_id. Most are reasons an action was held or refused; one — evidence-only — is not a refusal at all, and the distinction is worth preserving. All of them are what an analyst should be told rather than left to infer.

Rule Means
ot-cap The target is operational technology. Capped at T1.
asset-class-unknown The inventory could not classify the target, so it is treated as OT.
kill-switch Everything is halted.
maintenance-window Systems are being serviced; actions are held for a person.
playbook-max The customer's own playbook caps this action at this tier.
earned-autonomy This action type has not earned the tier it would need.
capability-not-permitted The proposed action is not in the playbook.
evidence-incomplete · partial-evidence Required evidence is missing, so no recommendation is offered.
model-unavailable The model did not answer at all — distinct from declining to.
narrative-empty The model answered with nothing an analyst could read.
evidence-only Not a refusal. No action was proposed, deliberately — observing and reporting is a legitimate outcome, and the findings still stand.

Safety controls

Kill switch
One control that halts every agent — T0, nothing proceeds, no new work admitted. Anyone may engage it; only an administrator may release it. A halt that anyone can undo is not a halt.
Maintenance window
Weaker than the kill switch, and the pair is the point. Holds actions at recommend while systems are being serviced; analysis continues. For when engineers are inside the machine and an agent disabling an account a field engineer is using would be worse than a delayed response. Never expires on its own.
Closed action space
The model may only ever name an action the playbook already permits. This is the structural defence against prompt injection: a completely compromised model still cannot produce an action the customer never allowed.
Prompt injection
Instructions hidden in data the system ingests — an alert, a log line, a filename — intended to be obeyed by a model reading it. Treated as expected rather than exceptional: all ingested data is untrusted, and agents flag it rather than comply.
Approval token
The short-lived authority to perform one specific action against one specific target, minted when a person approves. Not reconstructable from the log — a token that could be rebuilt from a record could be replayed from one.

Who is calling

Tenant
One customer's isolated space. The examples are northwind and contoso.
Principal
Who is making a request — an id, a tenant, and a role. A principal's tenant is the only source of tenancy; a request parameter may narrow scope within it and may never name a different one.
Role
Four, fixed. Three describe jobs people hold: analyst (works incidents, approves
actions), tradecraft-owner (writes the rules), admin (operates the system).
Writing the rules and approving actions under them are deliberately different jobs.
The fourth, ingest, is a system rather than a person — see below.
ingest (the role)
Held by a bridge submitting alerts on a SIEM's behalf. It may submit alerts and do
nothing else: not approve, not edit tradecraft, not administer.
It exists because submitting an alert requires only authentication, so a bridge holding an analyst's credential could also approve actions — and a bridge is reachable from whatever the customer points at it. A tampered SIEM should be able to waste an analyst's attention and not disable an account. ADR 0014.
Keycloak
The identity provider that runs in the stack. Also the thing a customer's own provider is brokered through, so the harness learns one protocol rather than one integration per customer.
OIDC · OpenID Connect
The standard protocol for "who is this". The harness receives a signed token and checks its signature, issuer, audience, expiry, tenant and role before trusting any of it.
Claim
One assertion inside a token — the username, the tenant, the roles. Signed by the provider, which is why they can be trusted, and checked anyway.

Getting alerts in

SIEM bridge
The service that receives a customer's SIEM alerts and raises harness alerts from
them. Mechanism only: receive, authenticate, apply the customer's mapping, submit,
log.
It is the most exposed component here — reachable from whatever the customer points at it — so it sits on its own network with the SIEM, has no route to the audit chain, the tool gateway or the estate, and acts as a principal that can only submit.
Ingest mapping
Tradecraft, like a playbook. Says which of an organisation's SIEM alerts are worth
an agent, which field of the alert names the subject, and what kind of harness
event each one becomes.
Those are judgments about a particular estate — its log sources, its detection content, its tolerance for noise — so they are data the bridge reads rather than code inside it. The same SIEM alert reaches both example organisations and only one of them raises anything.
Raised · dropped · refused
The three things a mapping can conclude, and the distinction is operational. Raised: a rule matched and the alert names a subject. Dropped: nothing matched, which is ordinary — a SIEM emits far more than is worth an agent. Refused: a rule matched but the alert names no subject, so it is not forwarded. An alert with no subject gets enriched about nothing and produces a verdict resting on nothing.
Subject
The field of an incoming alert naming who or what it is about. Required: the harness enriches about a subject.

The machinery

Audit chain
The append-only record of every prompt, tool call, decision, approval, action and
model choice. Hash-linked: each event includes the previous event's hash, so altering
any one of them invalidates everything after it.
Elsewhere: "audit log" often just means a log file. The difference is that this one can be verified, and names the first event that no longer holds.
Replay
Re-running a recorded incident from its chain and reproducing the same decisions. Both a compliance property and how recorded model responses are sourced.
Tool gateway
The only way an agent touches anything. Tools are typed, permissioned, read-only by default, and bounded to a target. The only service with a route to the simulated estate.
Model router
One interface over every model — a canned stub, a recorded session, a local open-weight model, a hosted frontier model, Bedrock. Lets the model be swapped without anything else noticing, which is what makes "model-agnostic" testable.
Backend
One implementation behind the router. scripted, replay, local, anthropic, bedrock.
Air-gap
A mode in which no request may leave the host. Requests for a hosted model are routed to the local one instead, citing the rule; the egress proxy denies everything; and an overlay removes the external network entirely. Three mechanisms of different strengths, and the demonstration says which is which.
Egress proxy
The single chokepoint for outbound traffic, with an allow-list held as data. Every outbound call is attributable to the service that made it.
Tiered / brokered
Shorthand for "it goes through something that is allowed to check it" — the gateway for tools, the proxy for egress, the jump host for OT.
HW-1
"Hello World 1" — Suspicious Sign-In Triage, the one scenario the proof of concept implements end to end. Deliberately simple, so that what is being demonstrated is the platform rather than the detection.

Words that mean something else elsewhere

The ones most likely to cause a misunderstanding nobody notices.

Word Here Commonly
Tradecraft the defender's methods, owned by the customer the attacker's methods
Harness the product — the reusable platform test scaffolding
T0–T3 our four autonomy tiers nothing standard; the industry scale is AL1–AL4
Playbook declarative data the platform interprets often a SOAR workflow with code in it
Agent one role in the harness (triage, investigator) anything from a software daemon to a person
Seam the IT/OT crossing point a code or data join
Audit log a hash-linked, verifiable chain any log file