From Profile Composition PoC to a Scalable Runtime Conditions Architecture

[ksteffe]

The dev-container Profile composition PoC has now landed in rc-demos:

runtimeconditions/rc-demos#2

That experiment gave me a much clearer picture of one possible workflow:

application signals
    ↓
application Profile
    ↓
application-owned completion
    ↓
validation
    ↓
composition with execution-context requirements
    ↓
composed workload Profile
    ↓
validation
    ↓
downstream platform consumption

One thing I particularly like about the result is that the application and the dev-container remain distinct workloads with distinct identities, while the composed result is still an ordinary Runtime Conditions Profile.

Colin asked on the PR whether I’d be interested in thinking through what this could look like as a scalable real-world architecture. Definitely yes.

Rather than jump straight into another implementation, I thought it would be useful to start identifying the architectural boundaries we want to preserve and the questions a scalable design needs to answer.

A downstream experiment that helped expose some of those boundaries

In parallel, I’ve been experimenting with Runtime Conditions as input to PADE:

https://github.com/After-Certainty/rc-pade

The goal there has not been to make PADE part of Runtime Conditions. It has been useful as a concrete downstream consumer for testing the boundary between a Profile describing workload demand and a platform interpreting that demand as capability intent.

One experiment took the actual composed dev-container Profile from rc-demos and projected its source-control requirement:

kind: source_control
interface:
  type: git
  provider: github
  access:
    - fetch
    - pull
    - push

into PADE capability intent:

github.repo.read
github.repo.write

The Runtime Conditions Profile did not contain credentials, repository identity, tokens, broker configuration, or fulfillment mechanics.

The resulting PADE DevelopmentSession was also successfully consumed by the existing PADE fulfillment path for the read capability.

I don’t take that as evidence that PADE’s current projection mechanism is the architecture we should standardize around. It has mainly been useful for making assumptions concrete enough to discover where the interesting boundaries are.

White paper alignment

The current white-paper draft also seems like a useful architectural anchor:

runtimeconditions/white-paper-artifacts#1

I especially like its framing of Runtime Conditions Profiles as a common reference point between workload demand and platform fulfillment, without replacing service catalogs, deployment manifests, policy systems, or other platform tooling.

That makes me picture the boundary roughly like this:

workload / application
        |
        | describes demand
        v
Runtime Conditions Profile
        |
        | platform interprets / matches demand
        v
platform capability intent
        |
        | environment-specific policy + binding
        v
concrete fulfillment

The lower half could look completely different depending on whether the consumer is Kubernetes, Backstage, PADE, an internal developer platform, or something else.

Questions I think a scalable architecture needs to answer

1. Who owns Profile composition and lifecycle?

The PoC allows an application Profile to be materialized independently and then composed with requirements owned by another execution context, such as a dev-container.

Does that feel like the right fundamental model?

If so, what owns composition in a real system? How do we think about changes, recomposition, provenance, publication, and last-known-good artifacts?

2. What should downstream consumers know about extension-defined semantics?

One thing the PADE experiments exposed is that extensions are intentionally heterogeneous.

For example, different extensions currently express requirements through shapes such as S3 operations[].name, source-control provider + access[], HTTP method/path or a spec, Kubernetes verbs/resources/scopes, and NATS resource/action plus resource-specific fields.

Assuming a Profile has already gone through extension resolution and validation, what semantic view should a downstream consumer receive?

Should a generic downstream platform inspect the extension-defined fields directly?

Should extension-specific adapters translate them into whatever model the platform understands?

Or should extension resolution produce some intermediate representation that makes vocabulary ownership and semantics explicit to downstream consumers?

My main concern is avoiding a situation where every downstream consumer has to independently reproduce Runtime Conditions' extension-resolution semantics before it can safely interpret a Profile.

3. How should resolved extension identity and vocabulary ownership flow to downstream consumers?

The spec now allows multiple extensions to define the same Condition kind, with conditions[].extension selecting a particular definition when specified and the first matching definition in extension resolution order being used otherwise.

That makes me wonder what information survives resolution for a downstream consumer.

For example, after resolving:

kind: source_control

should a consumer receive or be able to determine the exact immutable extension identifier whose definition was selected?

Should that identity be preserved in provenance, including whether the selection was explicit through conditions[].extension or implicit through resolution order?

There also seems to be a related question about scope. conditions[].extension selects the extension defining the Condition kind, while interface types, extension-defined fields, and field values have their own resolution rules.

Should downstream consumers therefore think in terms of one extension owning a whole Condition, or in terms of resolved ownership for each extension-defined vocabulary element?

Put another way: after validation, how much of extension resolution should a downstream consumer ever need to repeat?

4. Where exactly does demand end and fulfillment begin?

The white-paper draft talks about allowing workloads to express requirements without unnecessarily specifying provider or implementation details.

That makes cases such as this interesting:

type: git
provider: github
access: [fetch, pull, push]

Is github intrinsic workload demand because the resource being accessed really is GitHub?

Or are there cases where the portable demand should simply be Git read/write, with the provider selected later by the environment?

My suspicion is that the distinction depends on whether the provider is part of the identity of the thing being requested or merely one possible implementation.

5. Where does concrete resource identity enter?

The source-control Profile deliberately does not contain a repository URL, credentials, token, account identity, etc., which feels like a useful separation.

But eventually a platform has to join something like:

"this workload needs Git read access"

with:

"this repository, through this provider,
 under this policy, for this workload identity"

Does that binding belong in a platform capability catalog, deployment configuration, a policy/binding layer, or some combination?

---

Those are the main boundaries I’m trying to understand before building much more.

I’m less interested in defending the particular implementation choices in the PoC or rc-pade than in finding the points where those experiments stop matching the model we want Runtime Conditions to have.

If some of these questions already have an intended answer, that would be especially useful context. And if there are other architectural questions we should be asking before thinking about a scalable implementation, I’d love to add them here.

[colinjlacy]

Diving into some of the questions:

1. Who owns Profile composition and lifecycle?

The hand-wavy answer is a CI pipeline. That probably doesn't go into enough detail for a scalable architecture, but it's a good foundation to build on top of.

One question I have that could help steer the direction of how we approach this is where the dev-container for a repo is defined. In my ultra-limited experience, it's usually in the .dev-container folder or JSON file living alongside the code. If that's going to be the case, then one single GH Actions pipeline could kick off both the application profile generation, and the dev-container profile generation. If they're separate, then it's probably more of a discussion.

2. What should downstream consumers know about extension-defined semantics?

Yeah, this is a good one. The goal of the extensions is to provide the minimum actionable information for a downstream adapter to fulfill the listed conditions. Sometimes that means more information up front, in the extension, than others. For example, the S3 extension uses actual S3 operation semantics, which can then be turned into IAM privileges. The NATS extension does the same - lists the streams and specific operations that are needed by the application. In both cases, authn/authz is built into the core understanding of what provisioning means. You legit can't have an S3 bucket or a NATS stream without some sort of clear authz declaration. Meanwhile, the rc/ extensions focus on less restrictive technologies like Postgres and Redis. Many services will get their own, with near-root privileges.

As for how much the adapters need to know and understand, ideally it should be that they can hook up to a service with an admin account (so AWS or NATS service) and use the extension semantics listed in the profile to directly take action against that service's management API. If a profile lists PutObject on s3://some-bucket then that should be all an adapter needs in order to make sure it's applied.

3. How should resolved extension identity and vocabulary ownership flow to downstream consumers?

This is a big question, so I'll answer the bits that I can. Further discussion is 100% warranted.

To me, the profile and the extensions that it leverages in order to define conditions is meant to indicate which capabilities are being requested from the downstream platform. If the platform has those capabilities already enabled, then the fulfillment should be easy and the validation/consumption of the profile. But it really only works if the platform knows how to interpret that condition into an actionable integration. Each platform is going to handle that differently.

At the end of the day, the extensions are only meant to provide standard vocabulary that we can/should all agree on. Once the condition has been validated against the extension, we no longer need the extension itself. We've proven that the condition meets the structure that was expected, and we can now move on to provisioning.

It would be good for a platform to be able to support as many capabilities listed within the extension, e.g. S3 PutObject and ListObjects, as well as identify a boundary beyond what they'll allow, e.g. maybe not supporting CopyObject. Even better if that's clearly laid out in some sort of a capabilities catalog for what they support, so that it can easily be addressed as profile conditions are consumed and acted upon.

4. Where exactly does demand end and fulfillment begin?

This is a good one. And a tough one. With no "right" answer. It really depends on the level of abstraction that makes something actionable to the downstream adapter. If we can say "git" without specifying a specific platform and still provide value, that's fine. If we need to or can say "github" and still be actionable and provide value, also fine.

The same can go for data storage, which is why we have kind, type, and engine in the first-party extension. You can say "I need a relational database" if your ORM is going to handle the different dialects. Or you can say "I need a Postgres" if you're specifically targeting one dialect. I see this as something similar.

To be fair, maybe "git" would have been the right abstraction point instead of "github." Open to feedback on that one.

5. Where does concrete resource identity enter?

IMO, that's 100% a platform responsibility. Unless the codebase specifically indicates or hard-codes the resource (and I'd have questions for the developer if they did that), then it's purely a fulfillment consideration. The goal is specifically to leave that downstream of the condition YAML, so that the platform can decide and take action.

[ksteffe]

Thanks, this helps a lot. The CI/composition model and especially the distinction between actionable Condition semantics and downstream resource binding line up pretty closely with what the experiments have been suggesting.

Your answer to #3 gives me one thing I want to think through a little more. I like the idea that once a Condition has been validated, an adapter shouldn’t need the extension artifact itself. I’m wondering whether there’s still a distinction between not needing the extension artifact and not needing the resolved semantic identity/provenance at all — particularly now that multiple extensions can define the same kind.

In other words, I wouldn’t want every adapter to repeat extension resolution, but I also want to understand what ensures that the semantics the adapter acts on are the same semantics that were validated.

I’ll think about that one a little more before proposing anything.

The git vs github question is interesting too. The experiments are making me think the useful rule may be exactly what you described for databases: preserve the more abstract requirement when multiple implementations are genuinely interchangeable, and name the provider when the workload actually depends on that provider.

[ksteffe]

A quick follow-up after trying to turn this discussion into something executable.

I finished Experiment 009:

After-Certainty/rc-pade#11

One of the things I wanted to test was the boundary you described here: once a Condition has been resolved and validated against its extensions, can the downstream platform move on without needing the extension artifacts themselves?

For the cases I tested, that worked.

RuntimeConditionsProfile
        ↓
RC resolution + validation
        ↓
same Profile bytes
        ↓
unchanged rc-pade
        ↓
platform capability policy

A couple of useful behaviors fell out of that:

• source_control/git with access: admin was rejected during RC validation and never reached rc-pade.
• access: clone was accepted by RC validation, but could still be rejected by the platform policy as unsupported.
• The exact Profile bytes accepted by validation were handed to rc-pade.
• rc-pade did not load or re-resolve any extension artifacts.

So Experiment 009 seems to support the separation you were describing: RC can establish that the requested vocabulary is valid, and the platform can separately decide which parts of that vocabulary it supports.

That leaves me with a narrower version of the extension-identity question.

I've started a design-only Experiment 010 here:

After-Certainty/rc-pade#12

What I'm trying to understand now is the distinction between:

• no longer needing the extension artifact after validation, and
• no longer needing any resolved semantic identity from that validation.

The concrete edge case I'm trying to reason about is this:

Could two different immutable extension IDs, in two independently valid Profiles, legally define Conditions that appear downstream with the same kind + interface.type and compatible field shape, but attach different semantics to that vocabulary?

If that cannot happen by design, then there may be a useful RC invariant here and kind + interface.type may be enough for an adapter.

If it can happen, then a downstream adapter matching only those names may not know which semantic contract was actually validated.

A few things I'd like to clarify before making 010 executable:

1. Is conditions[].extension intentionally scoped only to selecting the extension that defines the Condition kind, while things like interface.type, fields, values, and schemas continue to resolve independently?

2. Can two different extension IDs legally define the same kind + interface.type names in separate Profiles with different semantics, or is there an invariant that makes those names globally stable once validated?

3. When you say the extension itself is no longer needed after validation, should I interpret the validated vocabulary as the complete downstream semantic contract? Or is there some resolved identity/provenance that may still matter even though the extension document itself is gone?

I'm holding off on adding any extension-aware matching or capability catalog machinery to rc-pade until I understand that boundary better.

[colinjlacy]

The spec states:

Extension-defined vocabulary SHOULD use namespaced identifiers when the vocabulary is vendor-specific, platform-specific, experimental, or likely to conflict.

Namespacing applies to:

• kind values
• interface.type values
• Condition field names
• Interface field names
• Field values that are not intended to be shared vocabulary

The only reason it's not MUST is that a platform could, in theory, only allow internally sourced extensions (e.g. file://corporate-drive/extensions/oidc and oci://quay.some-company.com/some-org/rc-extensions/blah-blah) and still be valid. Even then, I'd say that it would be a bad design practice, and for the most part the vast majority of users would be looking for a globally centralized registry in the form of the growing https://github.com/runtimeconditions/extensions/tree/main/catalog. We're strictly enforcing namespacing within that catalog via GH Actions.

Point is, this isn't a problem we need to focus too hard on, especially this early when no one's even using it yet. We'll address it with more detail or enforcement if we need to, but it's so far downstream from where we are right now that I can't see getting hung up on it yet.

As for the questions:

1. interface.type and all other subsequent fields and values are tied to their kind.
2. While it's possible for someone to create a kind that isn't namespaced, doing so would be a bad design choice that they're free to make and totally put their end users at risk. Therefore, it's also possible for kind + interface.type to be duplicated. If that happened, I'd look to the author and say that they made a risky and poor design choice in doing that. The bigger question, though, is whether or not it matters. At the end of the day, what's important is the semantic meaning behind the vocabulary. Leading to the answer to the next question...
3. There's only so many ways to interpret a condition that's calling for a database, for example. It's still up to the downstream adapter to know how to resolve the profile's conditions, regardless of which extensions are used. If, for whatever reason, the adapter wants to or needs to key off of the specific extension ID, they can. But then I'd wonder if they're baking hidden semantic meaning into the extension, which would be questionable at best and purposely cryptic at worst. Namespacing kind would be the right way to solve that problem, which would eliminate the entire conversation altogether.

Fact is there's nothing in the spec stopping people from making really bad and uninformed design choices, since the entire purpose of a condition is to provide the subjective semantic value that a downstream consumer (a platform adapter, or even just a platform engineer talking it over with their dev) needs to derive from it. Many, if not all, of the extensions in https://github.com/runtimeconditions/extensions/tree/main/catalog will try to provide semantic meaning that is generally global, e.g. a reids is a redis, a postgres is a postgres. But platforms will still have to apply their own interpretation of what that means for them anyway - scale, compliance, cost, access control, security, secrets provisioning, network isolation - the list goes on.

[ksteffe]

Thanks, this clears it up for me.

My takeaway is that the semantic contract for a downstream consumer is the validated Condition vocabulary itself. Extension identity can still be available if a platform has a specific reason to use it, but it shouldn’t be necessary to recover hidden semantic meaning. If two things genuinely mean something different, that distinction should be expressed in the vocabulary, using namespacing where appropriate.

So for rc-pade I’m not going to carry resolved extension identity across the validation boundary or add identity-aware dispatch just to defend against vocabulary collisions. The platform will continue to interpret the visible validated vocabulary through its own explicit support/projection policy and fail closed on things it doesn’t support.

I captured that conclusion in Experiment 010 and closed it without any production code changes. Thanks for helping me avoid building machinery for a problem that belongs at a different layer.