--- title: Glossary description: Definitions of the terms the Cascades API docs use — cascade, node, execution, step outputs, batch, decision, scope, idempotency key, webhook event. canonical_url: "https://cascades.crscreditapi.com/docs/concepts/glossary" doc_version: "1.0.0" last_updated: "2026-10-05T19:24:37Z" source: docs/concepts/glossary.md --- # Glossary One definition per term, each linking to the page that covers it in depth. The reference pages, the code samples and the MCP tool manifest all use these words with exactly these meanings. ## Cascades and runs **Cascade** (API resource: `workflow`) — a decision workflow: which reports to pull, in what order, which rules to evaluate, and what happens on each outcome. The visual builder and the API expose the same object; over the API it is named `workflow` and its node graph lives in `definition`. See [Cascades](/docs/concepts/cascades) and the [Workflow schema](/docs/api/schemas/Workflow). **Workflow** — the API name for a cascade. `GET /workflows` lists them; `active: false` marks a draft that can run once in test mode but not live. See [Cascades](/docs/concepts/cascades). **Node** — one step in a cascade's `definition`: an `ApplicantSource` entry point, a `BillingProduct` that pulls one report, an `IfElse` that branches, a `Wait`, a `GoTo`, an `Action` (approve, email, adverse action, notification) or a terminal `ShowResults`. Nodes are wired by edge keys such as `next_step`, `pass_steps`, `human_review_steps` and `fail_steps`. See [What is in the definition?](/docs/concepts/cascades#what-is-in-the-definition) and the [CascadeNode schema](/docs/api/schemas/CascadeNode). **Execution** — one run of a cascade for one applicant. `POST /workflows/{id}/trigger` creates it and answers `202 Accepted`; the work happens in the background and everything about it hangs off `GET /executions/{id}`. See [Executions](/docs/concepts/executions) and the [Execution schema](/docs/api/schemas/Execution). **Step outputs** (`step_outputs`) — a map of node id to that node's output on an execution: the report fields a product node returned, which branch an `IfElse` took and why, what an action did. Returned only to keys with the `executions:read:full` scope because it routinely contains per-step PII. See [How do I read the decision?](/docs/concepts/executions#how-do-i-read-the-decision). **Batch** — one cascade run against many applicants in a single request. Cascades pre-creates a child execution per row and works through them in the background; the batch tracks progress and exports the results. See [Batches](/docs/concepts/batches) and the [Batch schema](/docs/api/schemas/Batch). **Decision** — the outcome an `IfElse` node reaches for an applicant: pass, fail or send to human review, each resuming its own branch of nodes. The execution's final status, `step_outputs` and any adverse-action notice are the API view of that decision; the operator app and the tenant-screening ScoreCard present the same run as a summary page. See [Executions](/docs/concepts/executions) and [Human review](/docs/concepts/human-review). ## Modes and access **Sandbox vs live** — the two hosts and the two ways a run can execute. Every run carries an `execution_mode` of `test` (synthetic mock data, nothing billed) or `live` (real consumer reports, billable, requires an approved account and an active cascade). See [Sandbox vs live](/docs/concepts/sandbox-vs-live). **`execution_mode`** — the per-request field that selects `test` or `live`. It is chosen per trigger, not per key, so the same integration moves to production by changing one value; keys minted from these docs are pinned to `test`. See [Sandbox vs live](/docs/concepts/sandbox-vs-live) and the [TriggerRequest schema](/docs/api/schemas/TriggerRequest). **API key** — the bearer token sent as `Authorization: Bearer ` on every request. Keys are minted at [/api-keys](/api-keys), carry a set of scopes, and see only the workflows, executions and subscriptions of the account that issued them. See [Keys, scopes and rate limits](/docs/concepts/scopes-and-keys). **Scope** — a permission attached to an API key, such as `workflows:read`, `executions:write` or `executions:read:full`. A request that needs a scope the key lacks returns `403 insufficient_scope`; each operation's reference page lists the scopes it requires. See [Which scopes exist?](/docs/concepts/scopes-and-keys#which-scopes-exist). **Idempotency key** — the `Idempotency-Key` header required by every endpoint that creates a run (`trigger`, `batches`, `re_evaluations`). A retry with the same key and body returns the original result instead of starting a second run; the same key with a different body is `409 idempotency_conflict`. See [Idempotency](/docs/concepts/idempotency). **Test identity** (registered test subject) — a synthetic applicant authored in the CRS sandbox test-case registry with a specific history. `GET /workflows/{id}/test_cases` returns the subjects that match a cascade's products with ready-to-send payloads; a test-mode trigger for a subject registered for every product node in the cascade replays its authored reports, and other test runs return schema mocks. See [Test identities](/docs/sandbox/test-identities). **Registry** — the CRS sandbox test-case registry that holds the test identities and the bureau responses replayed for them. See [Test identities](/docs/sandbox/test-identities). ## Events and notices **Webhook event** — a named change Cascades delivers to your endpoint as an HTTPS `POST` with a JSON envelope `{ id, event, created_at, data }`, for example `execution.completed` or `adverse_action.sent`. Subscriptions choose which events they receive. See [Webhooks](/docs/concepts/webhooks) and the [webhook events reference](/docs/api/webhooks). **Signing secret** — the per-subscription secret returned once by `POST /webhook_subscriptions`. Every delivery is signed with it (`X-Cascades-Signature: t=,v1=`), and `rotate_secret` replaces it with a 24-hour grace window. See [Verify webhook signatures](/docs/guides/verify-webhooks). **Adverse action** — the FCRA notice owed to an applicant declined on the basis of a consumer report. In Cascades it is an `Action` node with `action_type: "AdverseAction"` that picks the reasons, renders the notice PDF, emails it and archives it, either automatically or as a draft a reviewer sends. See [Adverse action](/docs/concepts/adverse-action) and [Adverse action notices](/docs/compliance/adverse-action-notices). **Human review** — the branch an `IfElse` node can route to instead of pass or fail. The execution pauses at `status: awaiting_review` until a reviewer posts a decision, which resumes `pass_steps` (approved) or `fail_steps` (denied). See [Human review](/docs/concepts/human-review). ## Reference and tooling **MCP server** — the Model Context Protocol server that exposes the Cascades API to AI assistants as tools. It is a thin wrapper: every tool is exactly one authenticated REST call using your own API key and scopes. See [MCP server](/docs/mcp). **`operationId`** — the stable identifier of one operation in the OpenAPI spec, such as `triggerWorkflow` or `getExecution`. It names the reference page (`/docs/api/workflows/trigger-workflow`), the generated code samples and the matching MCP tool, and it is the id to quote in error reports. See the [API reference](/docs/api) and [/openapi.json](/openapi.json). **OpenAPI spec** — the machine-readable contract the reference pages, code samples and MCP manifest are generated from, served at [/openapi.json](/openapi.json) and [/openapi.yaml](/openapi.yaml). See the [API reference](/docs/api). ## Related - [Overview](/docs) — what the API does and how to integrate, in order - [API reference](/docs/api) — every operation, schema, error code and webhook event - [llms.txt](/llms.txt) — the machine-readable index of these docs ## Sitemap See the full [sitemap](https://cascades.crscreditapi.com/sitemap.md) for all pages.