DR-001-Arch: Consistent Stack vs. Reference Integration (#2560)

added arch dr 001 consistent stack vs reference stack

Author: qor-lb

.github/CODEOWNERS

@@ -28,6 +28,9 @@ safety_analysis/                      @aschemmel-tech @masc2023 @PandaeDo
 safety_planning/                      @antonkri @FScholPer @qor-lb @johannes-esr
 verification/                         @eclipse-score/automotive-score-committers
 /docs/design_decisions/*infra*        @AlexanderLanin @dcalavrezo-qorix @MaximilianSoerenPollak
+# setting TLs until codeowners of architecture are defined
+/docs/design_decisions/*arch*         @antonkri @FScholPer @qor-lb @johannes-esr
+/docs/design_decisions/*strat*        @antonkri @FScholPer @qor-lb @johannes-esr
 /docs/glossary/                       @eclipse-score/automotive-score-committers
 /docs/introduction/                   @eclipse-score/automotive-score-committers
 /docs/manuals/                        @eclipse-score/automotive-score-committers

docs/design_decisions/DR-001-strat.md

@@ -0,0 +1,138 @@
+<!--
+Copyright (c) 2026 Contributors to the Eclipse Foundation
+
+See the NOTICE file(s) distributed with this work for additional
+information regarding copyright ownership.
+
+This program and the accompanying materials are made available under the
+terms of the Apache License Version 2.0 which is available at
+https://www.apache.org/licenses/LICENSE-2.0
+
+SPDX-License-Identifier: Apache-2.0
+-->
+
+# DR-001-Strat: Consistent Stack vs. Reference Integration
+
+- **Date:** 2026-02-07
+
+```{dec_rec} Consistent Stack vs. Reference Integration
+:id: dec_rec__strat__consistent_stack_vs_reference
+:status: accepted
+:context: Strategy
+:decision: S-CORE as consistent stack
+```
+
+---
+
+## Consistent Stack vs. Reference Integration
+
+### Context
+
+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.
+
+This ambiguity creates friction in technical discussions, feature planning, and change justification. Contributors and committers currently lack a clear architectural baseline to decide whether modules, processes and tools are expected to optimize for individual evolution of modules or for the behavior of the overall stack.
+
+This decision record clarifies the intended architectural role of S-CORE and establishes a foundation for subsequent technical and procedural decisions.
+
+The scope of this decision applies to the entire S-CORE project, including all existing and future modules.
+
+Two categories of modules must be distinguished:
+
+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.
+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.
+
+### Decision
+
+S-CORE is defined as a **continuously consistent stack**.
+
+The primary architectural goal of the project is the consistency and correctness of the full stack. All modules within S-CORE are expected to align with the objectives of the stack.
+
+Modules created in the context of S-CORE exist to serve the stack. Their evolution is guided by stack-level use cases, not by module-local objectives in isolation.
+
+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.
+
+#### No Constraint on Independent Module Delivery
+
+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.
+
+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.
+
+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.
+
+### Options Considered
+
+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.
+
+#### Option 1: Reference Integration of Independent Modules
+
+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.
+
+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.
+
+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.
+
+#### Option 2: Consistent Stack as Leading Use Case
+
+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.
+
+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.
+
+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.
+
+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:
+
+- demonstrate continuous integrability of all S-CORE modules across functional, performance, safety, and security perspectives
+- follow S-CORE process and quality expectations per module
+- define clear expectations for externally managed modules (for example, OpenSOVD) regarding required artifacts and interfaces
+- ensure gaps are addressed either by upstream artifacts or by explicit S-CORE maintenance responsibility
+
+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.
+
+### Consequences
+
+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.
+
+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.
+
+Late integration risk is reduced. Architectural inconsistencies surface earlier, during development rather than at release time.
+
+### Impact on Development Workflow
+
+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.
+
+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.
+
+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.
+
+### Impact on Governance and Planning
+
+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.
+
+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.
+
+No specific governance structure or role model is defined by this record.
+
+#### Handling of Breaking Changes and Integration Alignment
+
+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.
+
+Both outcomes remain architecturally possible:
+
+- delaying integration to align the stack with the new module version, or
+- releasing the stack with a previously integrated module version.
+
+The decision record does not mandate either approach. Instead, it establishes that such trade-offs must be evaluated and justified in terms of stack-level objectives rather than module-local priorities alone.
+
+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.
+
+### Explicit Non-Goals
+
+This decision record does not:
+
+- Define concrete development processes or workflows.
+- Specify CI/CD implementations or quality gates.
+- Define release cadences or versioning strategies.
+- Provide a migration plan for existing modules.
+- Specify how architectural discussions are conducted or moderated.
+
+These topics are expected to be addressed in follow-up decision records, using this decision as a shared architectural foundation.

docs/design_decisions/index.rst

@@ -15,6 +15,14 @@
 Decision Records
 ================
 
+Strategy
+~~~~~~~~
+
+.. toctree::
+   :maxdepth: 1
+   :glob:
+
+   DR-*-strat*
 
 Architecture
 ~~~~~~~~~~~~
@@ -25,7 +33,6 @@ Architecture
 
    DR-*-arch*
 
-
 Infrastructure
 ~~~~~~~~~~~~~~