Product Availability
LyftData capabilities can vary by release, edition, deployment mode, enabled features, and installed Catalog content. Use the Applies to note on a page when it is present, and compare the page with the version and configuration of the installation you are operating.
Read availability as a set of boundaries
Section titled “Read availability as a set of boundaries”A capability description can be true while still being unavailable in a particular environment. Check each boundary separately:
- Release identifies the product version containing the described surface.
- Edition distinguishes Community and Enterprise availability.
- Deployment mode identifies whether the behavior applies to a single-node server, distributed workers, or a hybrid topology.
- Maturity distinguishes established behavior from beta or preview behavior whose contract may still change.
- Feature state covers licensed, configured, or explicitly enabled subsystems.
- Catalog state covers the exact version and publication state of managed jobs, workflows, and Provider Packs.
If a page does not name a boundary that matters to your deployment, verify it against your installed release before relying on it in production.
Product and environment states are different
Section titled “Product and environment states are different”Keep these questions separate:
- Does the product release contain the capability?
- Is it available in the selected edition and deployment mode?
- Is the required feature or Catalog item installed?
- Is it configured with the required credentials, storage, and network access?
- Can the selected worker service it?
- Has this exact operation run successfully?
- Does the evidence confirm any claimed external effect?
For example, an installed Provider Pack is not necessarily configured or ready. A connected worker is not necessarily able to service every assigned job. A staged definition is not proof of installed execution.
Interpret evidence labels
Section titled “Interpret evidence labels”Documentation may refer to different forms of evidence:
| Evidence | What it establishes |
|---|---|
| Source proof | The capability exists in reviewed source or configuration |
| Component or integration proof | A bounded test path passed |
| Installed proof | The capability or artifact is present in a selected installation |
| Runtime proof | A named operation ran in a selected environment |
| Provider receipt | The external effect explicitly recorded by that receipt |
| Benchmark | A measurement for a named workload, topology, and time window |
One form does not automatically imply another. In particular, source proof is not installed proof, and a local success result is not an external provider receipt.
Version-sensitive procedures
Section titled “Version-sensitive procedures”Before following a procedure that changes state:
- Record the server and worker versions.
- Check the page’s Applies to note and required edition.
- Confirm the relevant feature, Catalog item, or Provider Pack version.
- Check the page’s limitations and recovery section.
- Use a read-only status or plan operation before applying a change where the product provides one.
Historical release notes remain evidence for those releases. Do not treat an older release page as the current operating procedure unless your installation is on that release.