FR-MC-002 — Provider-Specific Extensions

Go to Crucible Multi-Cloud Management Requirements

Statement

Crucible SHALL load a Provider Plugin that conforms to the applicable Provider Contract.

Source Statement

The system shall support provider-specific extensions through plugins.

Source

Crucible System Requirements Specification, Version 1.1 Draft, Functional Requirements, FR-MC-002.

Assessment

The source statement identifies the intended extension mechanism but does not provide a fully testable formulation.

The following Specification Discipline and Authoring findings apply:

The system does not use the defined system nameshall does not follow the established uppercase normative conventionSupport is a weak verb that does not identify the required behaviorProvider-specific extensions does not identify the architectural subject that realizes the extensionPlugins does not use the defined Provider Plugin conceptThe source statement does not identify the contract governing the Provider PluginThe source statement does not prescribe a programming language, packaging format, loading mechanism, Provider, or plugin implementationThe normalized Statement:

Replaces The system with CrucibleReplaces support with the direct behavior loadUses the defined Provider Plugin conceptRequires conformance to the applicable Provider ContractRetains the source-required plugin extension mechanismPreserves implementation independence outside the source-mandated plugin boundaryRetains one primary required behaviorThe normalized Statement does not independently require Provider Plugin discovery, installation, activation, replacement, isolation, signing, version negotiation, or removal.

Rationale

A Provider may expose capabilities, interfaces, parameters, and lifecycle operations that differ from those exposed by another Provider.

A Provider Plugin isolates those provider-specific details from the core Crucible behavior.

A Provider Plugin may implement:

Resource type mappingsProvider interface interactionsAuthentication behaviorRegion selectionNetwork configurationStorage configurationMachine type selectionProvider-managed servicesImage conversionImage uploadImage signingImage verificationImage promotionInfrastructure initializationDeployment operationsTeardown operationsProvider-specific validationProvider-specific error handlingThe applicable Provider Contract specifies the capabilities, operations, inputs, outputs, constraints, errors, compatibility rules, and lifecycle behaviors that govern interaction with the Provider.

The Provider Abstraction defines the provider-independent architectural boundary. The Provider Contract formalizes that boundary, and the Provider Plugin realizes the contract for a particular Provider or class of Providers.

Provider Plugins preserve separation among:

Provider-independent Crucible behaviorCommon deployment intentThe Provider AbstractionProvider-specific deployment behaviorProvider-specific parametersProvider interfaces and software development kits

Applies To

This requirement applies to:

Provider-specific deployment behaviorProvider-specific parametersProvider interfacesProvider deployment workflows

Verification

Verification SHALL confirm that the tested provider-specific behavior resides in a Provider PluginVerification SHALL confirm that Crucible loads the tested Provider PluginVerification SHALL confirm that the tested Provider Plugin conforms to the applicable Provider ContractVerification may include:

Provider Plugin loading testsProvider Contract conformance testsProvider interface testsInterface conformance inspectionStatic dependency analysisProvider deployment testsProvider Plugin substitution testsThe verification record SHALL identify:

The tested Provider PluginThe applicable ProviderThe applicable Provider ContractThe Provider Plugin loading operationThe Provider Contract conformance resultThe observed resultThe generated Evidence

Outgoing Traceability

This requirement realizes:

This requirement relates to:

Referenced By

The wiki Backlinks function provides the current list of pages that reference FR-MC-002.

Incoming Traceability should be derived dynamically from backlinks rather than maintained as a duplicate manual list.

Backlinks identify incoming references but do not define the semantics of each relationship. Referencing pages should identify whether the relationship represents realization, refinement, verification, dependency, or another defined traceability relationship.

ConOps Relationship

The Crucible Concept of Operations permits provider-specific realization while preserving provider-independent deployment intent.

FR-MC-002 establishes the extension boundary through which Crucible loads a Provider Plugin that conforms to the applicable Provider Contract.

The Provider Abstraction defines the provider-independent architectural boundary, while the Provider Plugin implements provider-specific behavior for a particular Provider or class of Providers.

Delivery Phase

Phase 1

Implementation Status

Not Assessed

Implementation status requires verification that Crucible loads a Provider Plugin that conforms to the applicable Provider Contract.

Requirement Status

Draft

The source System Requirements Specification identifies Version 1.1 as a draft.

Notes for Editors

This requirement page should retain the stable requirement identifier FR-MC-002.

Changes to the Statement SHALL preserve the approved intent of the source requirement.

The Source Statement should preserve the original wording from the controlling System Requirements Specification.

The source explicitly requires plugins. Changes should not generalize the extension mechanism without a corresponding change to the controlling requirement.

The Statement should remain limited to loading a Provider Plugin that conforms to the applicable Provider Contract.

Requirements for Provider Plugin discovery, installation, activation, version compatibility, isolation, signing, substitution, and removal should remain separate unless added by the controlling source.

Verification criteria should test only the behavior stated in the normalized Statement and should not introduce additional normative obligations.

Incoming Traceability should use the wiki Backlinks function rather than a manually maintained list.

To reference this requirement Statement from another wiki page, insert:

{{section>dido:02-crusible:99-annexes:annex-c-requirements:03-functional-requirements:03-04-multi-cloud-management:fr-mc-002#Statement&noheader&nofooter&noeditbtn}}

Do not rename this page after an external citation unless a redirect or move plan is in place.

© 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.