Terminology and conventions

ActionRail uses a deliberately small vocabulary. Consistent terms matter because configuration, runtime behavior, and operator-facing health all refer to the same objects.

Canonical terms

Term	Definition	Do not confuse it with
Agent	A registered runtime identity and configuration boundary. It can represent a framework-managed agent or a direct application integration.	A model, end user, conversation, thread, or individual run.
Action surface	The inventory of named operations a runtime can invoke and their argument schemas.	A log of past actions.
Tool	A callable capability exposed to the agent.	One invocation of that capability.
Action	A specific proposed or executed operation, identified by name and arguments.	The reusable tool definition.
Consequential action	An action capable of creating a material external effect.	Every tool call; read-only retrieval may not need enforcement.
Rule set	The enforcement configuration assigned to one agent.	A global policy applied implicitly to every agent.
Policy	A deterministic expression evaluated locally against tool arguments.	A prompt instruction or natural-language model policy.
Grounding	Live deterministic verification of proposed values against trusted facts.	RAG, semantic retrieval, or adding records to a prompt.
Source	A named, configured runtime-local verification endpoint or instance.	An adapter type or a control-plane traffic proxy.
Adapter	The implementation and configuration schema for a Source type, such as Postgres, MySQL, HTTP, MCP, or SQLite.	A configured customer system.
Check	One query, request, or MCP tool call against one Source, plus its match conditions.	An unrestricted database query written by a model.
Trusted context	Invocation-scoped values supplied by authenticated host code.	Model output or tool arguments.
Decision	The final allow, hold, or block result for a proposed action.	A model recommendation.
Console	The operator UI and packaged local control-plane distribution.	The runtime action gate.
Control plane	Configuration, agent registration, review, metadata, and operator APIs.	The path taken by tool or Source traffic.
Data plane	The customer-side runtime, Source connections, and tool execution path.	The Console UI.

Source and adapter

Use Source for the configured object a user creates and adapter for its reusable implementation type.

For example:

• production-billing is a Source;
• sandbox-billing is another Source;
• both use the postgres adapter.

A Source may connect to a system of record, a restricted read API, or an existing MCP gateway. System of record describes the role a Source can play; it is not the name of the product object.

Avoid using connector, integration, or data source for new ActionRail interfaces. Those terms collapse the distinction between an adapter and a configured instance.

Action wording

Use actions blocked for enforcement metrics and outcomes. “Prevented” is not an ActionRail decision term.

Use held for review when a decision requires a person. A held action has not executed and is not guaranteed to execute: approval, rejection, timeout, or Console unavailability can determine the final result.

Console and control plane

The Console is what an operator opens. The control plane is the broader API and storage boundary that supports the Console and managed SDK configuration.

In the open-source distribution, actionrail-console starts both together as a single-user local service. In a hosted deployment, the control plane can also provide authentication, workspace scoping, and managed operations without changing core pages or the runtime data path.