Pipeline Integrity

Pipeline integrity is the ability to distinguish what was authored, what was approved for deployment, what workers were asked to run, and what was actually observed. LyftData provides staged definitions, managed provenance, reconciliation, and runtime integrity controls for this lifecycle.

These controls reduce silent mutation. They do not by themselves provide end-to-end supply-chain certification or installed attestation.

The lifecycle and its evidence

State	Meaning	Evidence to keep
Draft	An editable job or workflow definition	Author, source revision, validation result
Published or staged	A selected definition entered the controlled deployment lifecycle	Version or hash, staging event, approval record
Planned	The Deployment Manager resolved intended jobs, placement, and change set	Plan identity and reviewed diff
Applied or deployed	The control plane recorded and sent the intended artifacts	Deployment history, worker targets, rendered identities
Observed	A worker reported bounded runtime state or execution evidence	Job status, logs, trace, runtime artifact
Externally effected	The final system reported the requested result	Correlated provider or destination receipt

Do not collapse these states into a single “deployed successfully” label. A staged record is not installed execution proof. Placement does not prove capacity or connectivity. A worker heartbeat does not prove the target job is serviceable. A runtime success flag does not prove an external side effect.

Protect authoring and staging

Keep source-controlled definitions in reviewed repositories.
Validate a draft before publication or staging.
Stage the exact selected job version; do not copy an untracked editor buffer into production.
Record who approved the transition and which environment it targeted.
Store production credentials in Credential Manager or the owning secret system, not in ordinary contexts or committed YAML.

Staging selects and locks the version intended for deployment. For workflows, publishing produces an immutable version and later changes begin as a new draft. These boundaries make review repeatable, but they are not release certificates on their own.

Treat managed artifacts as generated

Deployment Manager renders per-worker jobs from the published workflow and its bindings. Change the workflow or selected building block, publish a new version, and apply a new plan. Avoid editing a managed rendered job directly: reconciliation can replace that edit, and the edit separates observed state from reviewed intent.

When reviewing a plan, verify:

the workflow and item versions;
worker groups, replica intent, and environment;
generated adapter jobs or transports;
credential and variable bindings;
additions, updates, removals, and adoption of existing resources; and
warnings about unavailable workers or incomplete bindings.

Runtime verification and signatures

When runtime signature verification is enabled, workers verify staged execution material and refuse work whose signature cannot be validated. Keep signing keys, worker trust roots, and rotation procedures under the same change controls as other privileged credentials.

A valid signature proves that material passed the configured verification boundary. It does not prove:

that the build or author was otherwise trustworthy;
that the worker executed the material;
that the runtime was not compromised;
that an external destination accepted the result; or
that the deployment meets a formal supply-chain standard.

Pair signature evidence with deployment identity, worker status, traces or logs, and an external receipt where the outcome requires one.

Verify a rollout

Save the exact draft or source revision.
Validate, then publish or stage the selected version.
Review the Deployment Manager plan and record the intended worker targets.
Apply and wait for reconciliation to report the actual deployment state.
Confirm the target job is serviceable, not merely that its worker is online.
Run a bounded canary.
Capture a trace, runtime artifact, or job result as installed-runtime evidence.
Capture the destination or provider receipt when an external effect is part of acceptance.

If any identity changes between steps, restart the review from the changed boundary rather than combining evidence from different candidates.

Investigate drift or suspected tampering

Stop further promotion and preserve the current plan, deployment history, job status, and relevant audit logs.
Compare the authored or published identity with the staged and rendered identities.
Check whether a managed artifact was edited outside its owning workflow.
Check worker trust, authorization, and the exact target-job status.
Re-plan from the known-good published definition and inspect the diff before applying.
Rotate signing or credential material if compromise is plausible.
Rerun the canary and collect new evidence; do not reuse a receipt from the previous candidate.

Do not repair integrity state by directly editing LyftData SQLite databases. Direct writes bypass product authorization and audit paths and can leave the server, worker, and readiness views disagreeing.