Current model
The new Flow model in #1 now gives every step an explicit component version. The diagram extends this to middleware, mappings, logical components, responses, and Sub-Flows. The migration requires component_version_id and stores runtime and step metadata alongside the versioned definition.
That settles how a step identifies a dependency. The remaining question is what stays immutable behind that reference. For example, runtime = NODE names a runtime family, but does not by itself identify the exact runtime build.
Behavior to clarify
Could adoption freeze the executable contents behind those references, including step metadata and input/output mappings, and define which configuration inputs remain live?
A few boundaries would help make that contract concrete:
- Which runtime build and function artifacts does an adopted version identify, and can their contents change without a new version?
- With reference validation initially in the Controlplane, how should it verify that a component version matches its component, type, and permitted owner? What prevents concurrent edits or deletion from invalidating the graph being adopted?
- Should an OpenBao secret reference pin a secret version or follow rotation? Permission revocation may need to take effect independently of executable versioning.
Tradeoffs
Freezing executable contents would make debugging and selecting a previous version more dependable. Tightly pinned configuration makes independent updates less convenient, though, and urgent secret rotation should not require rebuilding every affected Flow unnecessarily.
Which inputs should be frozen, which should remain live, and what needs to be prepared successfully before adoption can make the version available for routing?
Current model
The new Flow model in #1 now gives every step an explicit component version. The diagram extends this to middleware, mappings, logical components, responses, and Sub-Flows. The migration requires
component_version_idand stores runtime and step metadata alongside the versioned definition.That settles how a step identifies a dependency. The remaining question is what stays immutable behind that reference. For example,
runtime = NODEnames a runtime family, but does not by itself identify the exact runtime build.Behavior to clarify
Could adoption freeze the executable contents behind those references, including step metadata and input/output mappings, and define which configuration inputs remain live?
A few boundaries would help make that contract concrete:
Tradeoffs
Freezing executable contents would make debugging and selecting a previous version more dependable. Tightly pinned configuration makes independent updates less convenient, though, and urgent secret rotation should not require rebuilding every affected Flow unnecessarily.
Which inputs should be frozen, which should remain live, and what needs to be prepared successfully before adoption can make the version available for routing?