Putting the pieces together: portable Runtime Conditions demand → Coder → downstream fulfillment

[ksteffe]

A few recent experiments have started to make a more complete development-environment integration possible, and I wanted to connect them here before building another experiment.

The question I am interested in is:

Can a project express only portable Runtime Conditions demand, while a development platform consumes that demand, evaluates what it supports, and binds supported capabilities to a downstream fulfillment mechanism — without requiring the project to carry platform-specific intent?

One concrete environment for testing this is Coder, with PADE as one downstream fulfillment implementation. The intent is not to make PADE part of Runtime Conditions; PADE is useful here because it gives us a concrete implementation against which the consumer boundaries can be tested.

Pieces that now exist

1. Validated Profile handoff

runtimeconditions/rc-demos#5 tests a downstream consumer receiving the exact Profile and extension artifacts that were resolved and validated upstream, with independently configured trust.

The consumer can then distinguish:

untrusted / invalid handoff
        ≠
valid Runtime Conditions demand
        ≠
valid but unsupported platform demand

Importantly, the downstream platform consumer does not need to become a Runtime Conditions validator itself.

2. A concrete Coder consumer environment

coder/registry#1166 contributes a PADE module for Coder.

The current integration establishes this boundary:

Coder owns workspace lifecycle
        ↓
runtime supplies workload identity
        ↓
PADE consumes that identity
        ↓
broker policy decides what authority is fulfilled

The currently proven path is intentionally narrow, but it gives us a real development platform in which to test the broader Runtime Conditions consumption model.

3. Dynamically derived capability bindings

The current Coder module requires PADE capability names to be supplied as Terraform configuration.

That is convenient when the platform already knows those names, but it becomes duplicate knowledge if they are supposed to be derived from Runtime Conditions demand.

After-Certainty/pade-coder#11 captures the generic missing seam: allow another platform integration to derive supported capability bindings later in the workspace lifecycle without teaching pade-coder about Runtime Conditions.

4. Runtime Conditions → platform capability projection

rc-pade has already been useful for testing the boundary between portable RC semantics and platform-owned support policy.

Conceptually:

validated RuntimeConditionsProfile
        ↓
platform support / projection policy
        ↓
PADE capability request
        ↓
broker authorization / fulfillment

The projection policy is intentionally downstream. Runtime Conditions defines demand; the platform decides what it supports and how it maps that support to its implementation.

The integration I would like to test

These pieces suggest an end-to-end development flow like:

project source
        ↓
Runtime Conditions generation / composition
        ↓
resolution + validation
        ↓
trusted validated Profile handoff
        ↓
Coder workspace
        ↓
platform support evaluation
        ↓
supported RC demand
        ↓
generated downstream capability intent + bindings
        ↓
PADE Consumer
        ↓
broker / fulfillment

The project would contain Runtime Conditions declarations, but would not need to contain a hand-authored pade.yaml or know that PADE is the mechanism being used by this particular development platform.

A PADE DevelopmentSession could still exist as an ephemeral/generated artifact. That seems useful because it makes the boundary observable:

what the workload requires        Runtime Conditions
             ↓
what this platform supports       platform policy
             ↓
what authority is requested       generated DevelopmentSession
             ↓
what authority is actually given  broker/provider policy

Another platform could consume the same validated Runtime Conditions Profile and map it into something entirely different.

Architecture question

Does this look like the right place to draw the boundaries?

In particular:

1. Should a development platform consume the validated Profile as its semantic input rather than requiring an additional platform-specific declaration from the workload?
2. Is the mapping from validated Conditions to platform capabilities correctly owned by the platform adapter / support policy?
3. Is it reasonable for the platform adapter to generate an implementation-specific intermediate artifact such as a PADE DevelopmentSession, provided that artifact remains downstream and is not part of the portable workload contract?
4. Would an experiment connecting the existing validated-handoff work to a real Coder workspace be useful in rc-demos?

The main thing I want to avoid is accidentally moving downstream platform concepts back into Runtime Conditions simply because they are necessary to make one implementation work.

The architectural test still seems to be:

Could the same validated Profile be handed to a different development platform or fulfillment implementation without changing the workload’s portable semantics?

If so, this feels like a useful next integration experiment.