[RFC] Runtime Conditions Profile Specification

[colinjlacy]

RFC: Runtime Conditions Profile Specification

This PR introduces a draft of the Runtime Conditions Profile specification and provides supporting artifacts for review. The new 2-spec-draft-and-support-artifacts/ directory includes:

• the Runtime Conditions Profile draft specification
• first-party extension definitions for common integrations and environment configuration
• an illustrative third-party object-store extension
• complete profile examples
• short review notes for security/privacy and adjacent ecosystem work

Areas Where Feedback Is Especially Valuable

• The name Runtime Conditions Profile
• Core Condition abstraction
• Overall extension explanation and structure
• Whether or not JSON Schema is sufficient for extension validations
• Downstream adapter requirements

Tooling and implementations, while demo-complete, are not part of the spec and therefore not considered part of this PR. You can find them here: https://github.com/colinjlacy/runtime-conditions-profiles.

You can also find a walkthrough guide explaining the core concepts here: https://colinjlacy.github.io/runtime-conditions-profiles/

Addresses #1797

[colinjlacy]

This is one area that needs more attention. The goal of including this field is to be able to match the requestBodySchema and responseSchema against an OpenAPI spec. However I definitely don't want to include the entirety of the OpenAPI spec in these two fields, so I'm curious to know what people think are the minimum necessary fields for an adapter to match against a downstream OpenAPI document.

[colinjlacy]

Feedback during a conversation with @salaboy Laurent and Yacine:

• "Conditions" and "profile" sound like everything is mandatory
  • need a way to have things that are optional
    • e.g. an observability endpoint that is optional
    • need a way to indicate a condition is optional or required
• need to be able to just specifify an OpenAPI spec as a condition
  • and a version
  • for those who can have it

    kind: service
    name: payment-api
    interface:
      version: 2.1
      specification: https://raw.githubusercontent.com/open-meteo/open-meteo/refs/heads/main/openapi.yml
      operations:
        - POST /path
        - GET /path
        - GET /path/{id}

• Laurent suggests that we just leave the service type as api
• Mauricio suggsts instead of saying service we say api
  • other API-ish integrations:
    • serets stores
    • message buses
    • etc

[colinjlacy]

Reverted to draft status. More changes coming after the end-to-end demo was built out, specifically around the inclusion and importance of the extension model. I also want to reduce the narrative prose of the spec so that it reads like...well, a spec. And not an essay.

[colinjlacy]

Re-opened as ready for review. I noticed the spec doc is truncated as too large in the changes tab. It's the second-to-last file in the list. You can view the rendered markdown here: https://github.com/colinjlacy/toc/blob/48f70dd83e8024066256ceb7f08ceee9bcdccfd8/tags/tag-developer-experience/initiatives/spec-for-declaring-app-integration/2-spec-draft-and-support-artifacts/runtime-conditions-profile-specification.md.