Define portable artifact requirement satisfaction for RAES Source

[Brad-Edwards]

Context

RAES Source identifies a provider-neutral artifact and delegates resolution
to the backend. RAES also already distinguishes exact, constrained, and open
author intent under SEM-218. It does not yet publish one portable contract that
applies those semantics consistently to artifact requirements.

The earlier framing of this work as a choice between a published substitute and
a build path was too narrow. Pulling is an acquisition operation; baking is one
possible materialization operation. They are neither opposites nor exhaustive.
An artifact may be exact and mandatory, selected from a constrained set,
resolved by the backend, dynamically composed, prepared before realization, or
unneeded.

This gap blocks downstream environment-pack publication and Shifter artifact
resolution:

• Define the environment-pack publication profile for artifact satisfaction env-packs#141
• Resolve RAES artifact requirements against backend capabilities Brad-Edwards/shifter#1580
• Operate Shifter public and private distribution channels Brad-Edwards/shifter#1582

The ecosystem boundary remains layered: RAES owns portable meaning, author
authority, backend capability and conformance; Environment Packs owns release
packaging; products such as Shifter own catalog policy and operated
distribution.

Scope

Define the portable RAES contract for artifact requirements and their
satisfaction.

The contract must preserve these independent axes:

• Author posture: exact, constrained, open, or absent. An exact artifact
  MUST be used; a backend cannot replace it merely because it can compose
  something equivalent.
• Satisfaction mechanism: an exact immutable artifact, an existing
  backend-owned artifact, a published candidate, dynamic composition, an
  explicitly permitted materialization specification, or another declared
  backend mechanism. This is not a closed enumeration.
• Acquisition: pull, copy, import, local lookup, or no transfer. Acquisition
  does not determine semantic authority.
• Timing: publication, pack ingestion, explicit backend preparation, or
  realization. Timing is constrained by the requirement and backend capability,
  not inferred from artifact type.
• Availability: provider, account, project, region, registry, and mutable
  channel facts remain outside scenario semantic identity.
• Trust: integrity, authenticity, provenance, and admission reuse existing
  RAES trust and associated-artifact contracts.

The current Source.build surface records observable build/provenance facts; it
must not silently become a universal recipe or an alternative to an exact
Source.

Acceptance

• RAES publishes a backend-neutral artifact-requirement contract preserving
  exact, constrained, open, and absent author posture.
• Exact artifacts cannot be substituted, rebuilt, or approximated unless
  the authoring contract explicitly permits alternatives.
• Constrained and open requirements identify what the backend may choose
  without prescribing pull, bake, or another transport mechanism.
• Published artifacts, locked inputs, materialization specifications, and
  backend-native/dynamic mechanisms can participate without forming a closed
  two-option union.
• Backend manifests declare the requirement classes and satisfaction
  mechanisms they support.
• Realizability distinguishes unavailable exact artifact, unsatisfied
  constraints, unsupported open realization, missing locked input,
  unavailable candidate, and unsupported backend mechanism.
• The realized artifact and mechanism are disclosed with provenance, while
  published-output identity remains separate from scenario semantic
  identity and mutable location/channel metadata.
• The contract composes with reusable-asset trust, associated-artifact
  manifests, provenance, and SEM-218 rather than defining parallel
  semantics.

Requirements

• ASR-519

Non-goals

• Operating a registry, catalog, build farm, or hosted service.
• Defining environment-pack release layout or publication tooling.
• Requiring every scenario or node to have an image.
• Requiring every artifact to be reproducible or buildable.
• Defining credentials, entitlement, or product-specific resolution policy.
• Selecting when a particular product prepares VM images.
• Implementing a particular backend adapter.

Cross-repository consumers

• RAES Environment Packs publication profile:
  Define the environment-pack publication profile for artifact satisfaction env-packs#141
• Shifter requirement resolution:
  Resolve RAES artifact requirements against backend capabilities Brad-Edwards/shifter#1580
• Shifter channel operation:
  Operate Shifter public and private distribution channels Brad-Edwards/shifter#1582

[Brad-Edwards]

Scope corrected to preserve exact, constrained, open, and absent artifact requirements and to separate satisfaction mechanism, acquisition, timing, availability, and trust. The downstream Shifter ADR correction is Brad-Edwards/shifter#1867.