You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The project was initiated with ambiguous architectural assumptions. In some project material, S-CORE is described as a reference integration of independently evolving projects/modules. In parallel, discussions and expectations emerged that treat S-CORE as a coherent, continuously working stack.
32
32
@@ -41,7 +41,7 @@ Two categories of modules must be distinguished:
41
41
1. Existing open-source projects/modules originating from other contexts and managed independently. These modules may be integrated into S-CORE if they are a good technical fit and align with S-CORE's functional goals. Their independent planning cadence and processes are explicitly acknowledged.
42
42
2. Modules that do not yet exist and are created specifically to fulfill the purpose of S-CORE within the S-CORE GitHub organization. These modules are directly affected by this architectural decision.
43
43
44
-
## Decision
44
+
### Decision
45
45
46
46
S-CORE is defined as a **continuously consistent stack**.
47
47
@@ -51,53 +51,68 @@ Modules created in the context of S-CORE exist to serve the stack. Their evoluti
51
51
52
52
Existing independently managed open-source projects/modules may be integrated where appropriate. Their independence is accepted, but their integration into S-CORE is evaluated and justified exclusively in terms of stack-level goals.
53
53
54
-
### No Constraint on Independent Module Delivery
54
+
#### No Constraint on Independent Module Delivery
55
55
56
56
This decision concerns architectural alignment and change justification. It does not impose constraints on modularity, packaging, or delivery models of the modules within the stack.
57
57
58
58
In particular, the consistent stack approach does not prevent modules or features from being independently buildable or releasable, nor from being used outside the S-CORE stack.
59
59
60
60
The decision only establishes that, when modules are integrated into S-CORE, their evolution and changes must be justified in terms of stack-level objectives.
61
61
62
-
## Options Considered
62
+
### Options Considered
63
63
64
-
### Option 1: Reference Integration of Independent Modules
64
+
The central question separating these options is not whether the S-CORE reference integration will be adopted directly and without adaptation in a downstream product (e.g. a series product) - it will probably not. The question is where integration effort is managed: driven by individual downstream needs at the module level, or consolidated at the stack level to maintain a continuously stable and transparent baseline.
65
+
66
+
#### Option 1: Reference Integration of Independent Modules
65
67
66
68
Modules evolve independently, with their own roadmaps and priorities. Integration occurs late and primarily before releases. Coordination effort is concentrated at integration time. Modules effectively behave as separate projects that are assembled into a reference configuration.
67
69
70
+
In this model, a downstream project (e.g. a series project) can drive module evolution directly. Modules are updated or extended to meet a specific downstream need first; the impact on S-CORE integration is resolved subsequently. This reduces short-term friction for that one downstream context but increases the integration cost for S-CORE and for other downstream projects, which must absorb the resulting divergence without having been part of the original justification.
71
+
68
72
This option favors module autonomy and minimizes continuous coordination. It shifts complexity to late integration phases and accepts reduced guarantees about the state of the full stack during development.
69
73
70
-
### Option 2: Consistent Stack as Leading Use Case
74
+
#### Option 2: Consistent Stack as Leading Use Case
71
75
72
76
The stack is the primary architectural artifact. Modules contribute to and are validated against the behavior of the full stack. Continuous integration is used to ensure the stack remains functional throughout development.
73
77
74
-
This option increases coordination and change management overhead during development. In return, it establishes a clear architectural contract. Changes are evaluated based on their impact on the stack, and the reference stack is expected to remain usable.
78
+
In this model, changes must be justified in terms of stack-level objectives before integration. This may require additional upstreaming effort for any individual downstream project compared to Option 1. However, it establishes a stable and transparent reference integration that all downstream projects and end users can build upon, without needing to absorb divergences introduced for another downstream context.
79
+
80
+
The reference integration is not necessarily expected to be adopted without adaptation in downstream products. Its goal is to provide a continuously integrated, validated baseline - making downstream adaptation as straightforward as possible and providing a shared, openly visible justification platform for all downstream projects involved.
81
+
82
+
This option also frames the reference integration as a continuous proof of integrability and quality, rather than a single downstream product delivery. In that framing, the reference integration is expected to:
83
+
84
+
- demonstrate continuous integrability of all S-CORE modules across functional, performance, safety, and security perspectives
85
+
- follow S-CORE process and quality expectations per module
86
+
- define clear expectations for externally managed modules (for example, OpenSOVD) regarding required artifacts and interfaces
87
+
- ensure gaps are addressed either by upstream artifacts or by explicit S-CORE maintenance responsibility
88
+
89
+
This option increases coordination and change management overhead during development. In return, it establishes a clear architectural contract. Changes are evaluated based on their impact on the stack, and the reference stack is expected to remain usable throughout.
75
90
76
-
## Consequences
91
+
### Consequences
77
92
78
93
The consistent stack model constrains module-level autonomy. Not all module-local use cases are valid by default. Changes, especially breaking changes, must be justified in terms of stack-level requirements.
79
94
80
95
The cost is increased coordination effort and earlier discussion of cross-cutting impacts. The benefit is architectural clarity and a shared basis for decision-making across teams.
81
96
82
97
Late integration risk is reduced. Architectural inconsistencies surface earlier, during development rather than at release time.
83
98
84
-
## Impact on Development Workflow
99
+
### Impact on Development Workflow
85
100
86
101
For modules created within S-CORE, development is guided by stack objectives. Features and changes are expected to consider their impact on the overall stack from the start.
87
102
88
103
Breaking changes in any module integrated into the stack require justification based on stack use cases. Module-specific arguments that do not align with stack objectives are insufficient.
89
104
90
105
This decision does not define concrete workflows, tooling, or CI/CD mechanisms. It establishes the architectural expectation that such mechanisms must support continuous stack consistency.
91
106
92
-
## Impact on Governance and Planning
107
+
### Impact on Governance and Planning
93
108
94
109
Planning and prioritization discussions must reference stack-level goals. Module roadmaps are not authoritative on their own when they affect the behavior of the stack.
95
110
96
111
This decision enables future decision records to define how architectural alignment is reviewed, how changes are discussed, and how conflicts between module and stack objectives are resolved.
97
112
98
113
No specific governance structure or role model is defined by this record.
99
114
100
-
### Handling of Breaking Changes and Integration Alignment
115
+
#### Handling of Breaking Changes and Integration Alignment
101
116
102
117
This decision does not prescribe a fixed procedural outcome for cases where module evolution and stack integration timelines diverge, for example when a breaking change in a module cannot be integrated into the stack shortly before a planned S-CORE release.
103
118
@@ -110,7 +125,7 @@ The decision record does not mandate either approach. Instead, it establishes th
110
125
111
126
In particular, breaking changes in modules intended to be part of the S-CORE stack require explicit consideration of their impact on stack consistency and planned stack use cases.
0 commit comments