Provider Registry
Discussion
A Provider Registry records and resolves the available Provider Plugins, their identities, supported contract versions, capabilities, compatibility information, and loading mechanisms.
The registry provides a controlled discovery point through which core software locates and selects a plugin for a specified Provider or deployment requirement.
A Provider Registry may validate plugin metadata, reject incompatible implementations, expose supported capabilities, and enforce a single approved loading path.
Within the Crucible architecture, the Provider Registry helps preserve the cloud-agnostic boundary by ensuring that provider-specific implementations enter the system through the defined Provider Contract.
Definition
registry that records and resolves available provider plugins, their identities, supported contract versions, capabilities, compatibility information, and loading mechanisms
Source
Generalized from plugin registries, service registries, dependency injection, extension management, and provider-integration usage and specialized for the Crucible architecture and operational model.
Note
A Provider Registry does not necessarily store the Provider Plugins themselves. It may store metadata and loading information that identify where and how the plugins become available.
The Provider Registry differs from an image, package, container, or artifact registry because it resolves software extensions rather than deployable content.
Example
At startup, Crucible queries the Provider Registry for a plugin that supports the selected cloud provider and the required Provider Contract version. The registry returns the validated plugin and its declared capabilities.
© 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.