--- title: "Glossary" description: "Canonical definitions for every Axiom term — the single authority for terminology used across the docs, the CLI, the canvas, and the API." category: reference surfaces: [cli, canvas, console, sdk, http-api] related: [concepts/nodes-packages-flows, concepts/execution-model, concepts/sandboxing-and-tenancy, concepts/memory] last_reviewed: 2026-06-10 --- # Glossary This page is the authority for Axiom terminology. Every concept has exactly one name; the docs never use a synonym ("component", "workflow", "graph") where one of these terms applies. ## Node A **node** is the single unit of compute in Axiom: a user-written handler function with a typed input message and a typed output message, both defined in Protocol Buffers. Node code runs in an isolated container and interacts with the platform only through the sidecar. Nodes are declared in a package's `axiom.yaml` and become available to flows once the package is published. A node is either *unary* (one input message in, one output message out per invocation) or a *pipeline* node (a streaming generator that emits a sequence of output frames). ## Package A **package** is the unit of publishing: a versioned bundle of node definitions and Protocol Buffers message types, described by an `axiom.yaml` manifest (name, version, language, nodes, imports). Running `axiom push` publishes a package to the marketplace, where its nodes can be placed into flows. A *proto-only* package contains no nodes — only message types for other packages to import. ## Flow A **flow** is a directed graph of nodes composed in the canvas (or via the API). An edge from node A to node B means "A's output message is B's input message"; edge type compatibility is checked at compile time. Invoking a flow always means executing its compiled artifact, never an editable draft. ## Message A **message** is a Protocol Buffers message: the only data type that crosses a node boundary. Every node input, node output, and edge payload is a message. Message types are defined in `.proto` files inside packages and may be imported across packages. ## Execution An **execution** is a single run of a flow, from invocation to completion, identified by an execution ID that the platform assigns when the request is accepted. The execution ID is threaded through every hop — traces, debug events, results, and the HTTP API all reference it. ## Entry node The **entry node** is the node where an execution starts: the flow's single node with no incoming edges. The entry node's input message defines the flow's input schema — it is what callers send when invoking the flow via the API. ## Terminal node The **terminal node** is the node where an execution ends: the flow's single node with no outgoing edges. Its output message defines the flow's result schema; an execution completes when the terminal node finishes. ## Compiled artifact A **compiled artifact** is the immutable, optimized representation of a flow that the platform produces at compile time and that workers execute. Compile validates edge type compatibility and resolves every node placement; once compiled, an artifact never changes — editing a flow produces a new artifact. ## Sidecar The **sidecar** is the platform proxy that runs alongside every node container and is the node's only channel to the platform. All platform capabilities — logging, secrets, memory, telemetry — reach node code through the sidecar, and the sidecar enforces tenant isolation. Node code never calls platform services directly. ## Tenant A **tenant** is an isolated account scope. Every execution carries the tenant identity resolved from the authenticated API key, and the platform — not node code — enforces that one tenant's data (secrets, memory, results) is never visible to another. ## Pipeline mode **Pipeline mode** is the streaming execution mode of a flow: instead of one request producing one response (*unary* mode), frames flow continuously between nodes and results are delivered to the caller progressively as a stream. A flow runs in pipeline mode when it contains pipeline nodes. ## Session A **session** is the scope of one conversation or interaction in agent memory, identified by a session ID that always comes from the caller's typed input message — the platform never infers or injects it. Episodic memory (the record of what happened) is scoped to a session. ## Consolidation **Consolidation** is the background process that promotes episodic memories (session-scoped records of what happened) into durable semantic facts that persist across sessions — for example, turning repeated conversation turns into "this user prefers TypeScript." ## Flow config A **flow config** is a named profile of parameter values (and secret references) attached to a flow. Callers select a config by name at invocation time; the platform resolves the profile and injects the resolved values into the execution, so the same flow runs with different settings — say, `staging` and `production` — without recompiling. ## Secret A **secret** is a named, tenant-scoped credential (an API key, a token) stored in the console and read by node code through `AxiomContext` at runtime. Secrets never appear in package source or flow definitions; a node declares the secret names it needs in `axiom.yaml` (`required_secrets`) so users know what to register before invoking. ## Client A **client** is a named, account-scoped bundle of marketplace nodes and flows, assembled in **Console → Client Builder**, that compiles into a typed SDK. Each bundled node or flow is a *member* with a unique *alias* that becomes its method name in the SDK. Building a client produces an immutable, numbered *version* — a frozen snapshot of its members — that can be compiled into any of six languages (Python, Go, TypeScript, Java, C#, Rust). See [Build a client SDK](../guides/build-a-client-sdk.md).