Glossary
General terms
Section titled “General terms”Server
Section titled “Server”The server is the control plane for a LyftData deployment. It hosts the UI and APIs, manages workers and jobs, and stores metrics, logs, and traces.
Worker
Section titled “Worker”A worker is a process that connects to the server and runs jobs.
Worker group
Section titled “Worker group”A worker group is an operator-defined set of workers used for placement and scaling decisions in Deployments.
A job is a pipeline with one input, zero or more actions, and one output. The job definition captures that configuration.
Job definition
Section titled “Job definition”A job definition is the saved configuration for a job. Authors build and edit definitions in the visual editor before staging them for deployment.
Event data
Section titled “Event data”Event data is the payload that flows through a job from input to output.
The input is the first stage of a job and determines where event data originates (for example, S3, HTTP, or files).
Output
Section titled “Output”The output is the final stage of a job and controls where processed event data is delivered.
Action
Section titled “Action”An action transforms, enriches, or routes event data between the input and output stages of a job.
Visual editor
Section titled “Visual editor”The visual editor is the UI workspace for creating, inspecting, and modifying job definitions.
Staging
Section titled “Staging”Staging creates a fixed deployable revision of a job definition. Further edits create another revision. A staged revision records intended material; it does not by itself prove that a worker installed or executed it.
Deployment
Section titled “Deployment”In LyftData, “deployment” can refer to two related concepts:
- Job deployment: applies a staged job definition to a worker so it can execute the job (see Deploying Jobs).
- Workflow deployment: a Deployment Manager record that plans/applies a workflow across workers (see Deployments Overview).
Job deployment
Section titled “Job deployment”A job deployment applies a staged job definition to a worker.
Workload
Section titled “Workload”A workload is the running execution state of a deployed job on a worker (what is actually running after a deploy/apply).
Deployment Manager
Section titled “Deployment Manager”The Deployment Manager is the UI/API that plans, applies, and reconciles workflows (and some blueprints) into running jobs on workers.
Deployment record
Section titled “Deployment record”A deployment record captures the desired state for a workflow/blueprint deployment (what should run, where it should run, and with what parameters).
Workflow
Section titled “Workflow”A workflow is a versioned graph of steps and edges that composes multiple jobs/modules into a system.
Trigger
Section titled “Trigger”A trigger is a governed operator-facing action that can start a supported workflow or operation. Trigger availability, authorization, checkpoint behavior, and evidence depend on the published trigger definition.
Blueprint
Section titled “Blueprint”A blueprint is a reusable building block used inside workflows (connectors, adapters, and patterns). Some blueprints can also be planned/deployed directly.
Template
Section titled “Template”A template is a reusable job starter (snippet, sometimes parameterized) that you can apply when creating a new job draft.
Library job
Section titled “Library job”A library job is a managed job snippet stored in the Catalog. It is a known-good starting point when you want “one job that does X”.
Provider Pack
Section titled “Provider Pack”A Provider Pack is a versioned Catalog package for a reusable provider capability. It can bind jobs, workflows, triggers, credentials, readiness checks, policy, and receipts. Packaged or installed does not automatically mean configured, ready, live-proven, or available in every release.
Auto-enrollment
Section titled “Auto-enrollment”Auto-enrollment authenticates workers with a pre-shared key instead of individual API keys.
Worker API key
Section titled “Worker API key”A worker API key authenticates a specific worker when it connects to the server.
Metrics
Section titled “Metrics”Metrics are usage counters and rates generated by jobs and stored by the server according to retention settings.
Logs record operational messages from the server, workers, and jobs for troubleshooting and auditing.
Traces
Section titled “Traces”Traces record spans that describe the path and timing of supported distributed operations. They are distinct from the transient event inspection provided by Run & Trace.
Runtime artifact
Section titled “Runtime artifact”A runtime artifact is a bounded output, event, signal, result, or receipt recorded for a supported operation. Its type determines what it proves and how it can be fetched, retained, redacted, or cleared.
Receipt
Section titled “Receipt”A receipt is structured evidence produced by an operation. A source-side or LyftData receipt proves only the state it explicitly records; it is not proof of an external provider action unless the receipt says that action was confirmed.
Source proof
Section titled “Source proof”Source proof is evidence from code or configuration review that a capability is implemented. It does not prove that the capability is installed, enabled, or working in a selected environment.
Installed proof
Section titled “Installed proof”Installed proof confirms that a capability or artifact is present in a selected installation. It does not automatically prove configuration, worker serviceability, or a live external effect.
Benchmark
Section titled “Benchmark”A benchmark is a controlled measurement for a named workload, environment, and time window. It must not be generalized into a universal capacity or performance guarantee.
Message system
Section titled “Message system”The message system is the internal bus workers and jobs use to exchange events, metrics, and user-defined messages.
Context
Section titled “Context”Context is ordinary configuration data defined at the server, worker, or job
level. Jobs access context values with the {{CONTEXT_KEY}} syntax. Context
values are not a replacement for Secret Store or Credential Manager.
Variable expansion
Section titled “Variable expansion”Variable expansion resolves runtime values (event fields, context keys, job metadata) inside job definitions.
Control plane
Section titled “Control plane”The control plane is the server-side product surface that stores desired state, authorizes operations, exposes the UI and product API, and coordinates workers. It is separate from the data-processing work performed by jobs.
Capability
Section titled “Capability”A capability is a governed customer-visible or operator-visible ability with a stable identity, availability boundary, limitations, owner, and supporting evidence.
Model Context Protocol (MCP) is a protocol through which an AI client can discover and invoke selected LyftData tools. Tool registration or a model response is not proof of an external action; use the operation’s runtime evidence or provider receipt.