Provider Packs

A Provider Pack is a versioned Catalog package for a reusable provider capability. It can bring together jobs, workflows, triggers, credential requirements, readiness checks, policy, and execution evidence without adding provider-specific business behavior to the LyftData server.

Provider Packs build on the same generic runtime primitives used by ordinary jobs: HTTP and protocol components, Credential Manager, workflows, triggers, worker placement, runtime artifacts, and receipts.

Applies to

The Provider Pack substrate is a beta Enterprise capability for single-node, distributed-worker, and hybrid deployments. Exact Pack availability and maturity remain release- and Pack-specific.

Caution

A Pack appearing in a Catalog does not by itself mean it is configured, serviceable on your workers, proven against a live provider, or available in every LyftData release. Check the Pack’s status and prerequisites in the Catalog you are using.

Provider Pack, recipe, or runtime primitive?

These three building blocks solve different problems:

Building block	What it provides	What it does not prove
Runtime primitive	A typed input, action, or output such as HTTP polling, S3, Kafka, or OpenTelemetry	That a complete provider workflow is configured or ready
Recipe	Documentation showing how primitives can be combined for a use case	That the combination is a managed or supported Catalog item
Provider Pack	A Catalog-authored package with a stable identity, version, requirements, and governed capabilities	That credentials, workers, provider consent, and live execution are ready in your environment

Use an integration recipe when you need a transparent job-level pattern. Use a Provider Pack when your Catalog contains a governed package for the complete capability and you want its version, policy, and evidence boundaries.

What a Pack can contain

A Pack can describe:

• one or more jobs, workflows, or triggers;
• required provider accounts, scopes, credentials, and source bindings;
• worker labels, capabilities, network access, or other readiness checks;
• read-only, write-gated, or unavailable operations;
• result and receipt shapes;
• redaction and evidence requirements; and
• related MCP tools or other governed automation surfaces.

The exact contents are Pack-specific. A Pack can intentionally publish only read operations while leaving mutations disabled, or require an approval before a write operation is exposed.

Read the lifecycle correctly

Keep the following states separate when deciding whether a Pack is usable:

1. Authored means the Catalog has a versioned Pack definition.
2. Packaged means the definition and its referenced assets pass the Catalog’s structural checks.
3. Released means the Catalog record has completed its declared source-side release gate.
4. Published is Catalog source metadata that permits promotion. It does not by itself prove Portal promotion, app synchronization, enabled state, or discovery in your installation.
5. Installed means the exact Pack version is present in the selected LyftData environment.
6. Configured means its required settings, credentials, sources, and policies have been supplied.
7. Serviceable means the selected workers, jobs, credentials, network paths, and runtime requirements can service the Pack.
8. Live-proven means the declared operation ran against its live target and produced the required evidence.
9. Externally confirmed means the evidence explicitly confirms the provider-side effect being claimed.

A later state is not implied by an earlier one. In particular, source publication is not installed-product discovery, installation is not serviceability, and a successful internal result is not automatically proof that an external provider accepted a change.

Before you install or activate a Pack

Review the Pack details in Catalog and confirm:

• the Pack id and version match the change you reviewed;
• the Pack is published for your release and edition;
• required provider accounts, tenant consent, scopes, and network routes are available;
• Credential Manager contains the required credential without placing secret material in job definitions or ordinary context values;
• allowed workers and job bindings match the intended execution boundary;
• write operations have the required approval and idempotency controls; and
• the Pack explains which readiness result or receipt proves each important outcome.

Provider consent, rate limits, tenant policy, and outages remain controlled by the external provider.

Operate and verify a Pack

After installation:

1. Open the Pack details and resolve every failed or unknown readiness check.
2. Confirm that the selected worker is connected and can service the Pack’s assigned jobs, credentials, network destinations, and required components.
3. Start with a read-only or fixture-backed operation where the Pack provides one.
4. Inspect the resulting status and runtime evidence.
5. For an external write, require the Pack’s provider receipt or an independent provider-side readback before treating the effect as confirmed.

Do not infer readiness from a green worker heartbeat alone. Do not infer an external effect from an MCP or model response alone.

Catalog authority and local copies

The Catalog is the authored source for managed Provider Packs. A Pack copied into or bundled with a LyftData release is a pinned snapshot for that product version; it does not replace the Catalog record or silently inherit a newer Catalog status.

Use Catalog to understand discovery and installation, Credential Manager for sensitive material, and Integrations for primitive and recipe-based options.