diff --git a/.github/workflows/pages.yml b/.github/workflows/pages.yml
new file mode 100644
index 0000000..a793792
--- /dev/null
+++ b/.github/workflows/pages.yml
@@ -0,0 +1,60 @@
+name: docs
+
+on:
+ pull_request:
+ push:
+ # branches:
+ # - main
+ workflow_dispatch:
+
+permissions:
+ contents: read
+ pages: write
+ id-token: write
+
+concurrency:
+ group: docs-${{ github.ref }}
+ cancel-in-progress: true
+
+jobs:
+ build:
+ runs-on: ubuntu-latest
+
+ steps:
+ - name: Check out repository
+ uses: actions/checkout@v4
+
+ - name: Set up Python
+ uses: actions/setup-python@v5
+ with:
+ python-version: "3.12"
+
+ - name: Set up uv
+ uses: astral-sh/setup-uv@v5
+ with:
+ enable-cache: true
+
+ - name: Configure GitHub Pages
+ uses: actions/configure-pages@v5
+
+ - name: Sync documentation toolchain
+ run: uv sync --frozen
+
+ - name: Build MkDocs site
+ run: uv run mkdocs build --strict
+
+ - name: Upload Pages artifact
+ # if: github.ref == 'refs/heads/main'
+ uses: actions/upload-pages-artifact@v3
+ with:
+ path: site
+
+ deploy:
+ # if: github.ref == 'refs/heads/main'
+ needs: build
+ runs-on: ubuntu-latest
+
+ steps:
+ - name: Deploy to GitHub Pages
+ id: deployment
+ uses: actions/deploy-pages@v4
\ No newline at end of file
diff --git a/.github/workflows/pr.yml b/.github/workflows/pr.yml
new file mode 100644
index 0000000..0817243
--- /dev/null
+++ b/.github/workflows/pr.yml
@@ -0,0 +1,32 @@
+# *******************************************************************************
+# Copyright (c) 2025 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
+# *******************************************************************************
+
+name: Pull Request Workflow
+on:
+ pull_request:
+ types: [opened, reopened, synchronize]
+
+jobs:
+
+ self_test:
+ name: 🔬 Self Test
+ runs-on: ubuntu-latest
+ steps:
+ - name: 📥 Check out
+ uses: actions/checkout@v6
+
+ - name: ⚙️ Setup uv
+ uses: astral-sh/setup-uv@v7
+
+ - name: 🛠️ Run pre-commit
+ run: uv run pre-commit run --all-files
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..6c5aca0
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,3 @@
+.venv/
+site/
+__pycache__/
\ No newline at end of file
diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml
new file mode 100644
index 0000000..235def0
--- /dev/null
+++ b/.pre-commit-config.yaml
@@ -0,0 +1,9 @@
+repos:
+ - repo: local
+ hooks:
+ - id: aggregate-status
+ name: Aggregate chapter statuses
+ entry: python scripts/aggregate_status.py
+ language: python
+ pass_filenames: false
+ files: ^(docs/chapters/.*\.md|docs/index\.md|scripts/aggregate_status\.py)$
\ No newline at end of file
diff --git a/README.md b/README.md
index 22a7505..615a234 100644
--- a/README.md
+++ b/README.md
@@ -1,2 +1,28 @@
-# infrastructure
-All general information related to the development and integration infrastructure
+# S-CORE Infrastructure Documentation
+
+This repository contains the sources for the S-CORE infrastructure documentation.
+
+The published documentation is available at:
+
+- https://eclipse-score.github.io/infrastructure/
+
+## How The Site Is Structured
+
+The README intentionally stays short to avoid duplicating the actual documentation. Use the published site for content and this repository for source files, local preview, and contribution work.
+
+## Run MkDocs Locally
+
+This repository uses `uv` for local toolchain management.
+
+Install dependencies and start a live preview:
+
+```bash
+uv sync
+uv run mkdocs serve
+```
+
+Build the site with strict checks:
+
+```bash
+uv run mkdocs build --strict
+```
diff --git a/docs/chapters/01-source-code-infrastructure.md b/docs/chapters/01-source-code-infrastructure.md
new file mode 100644
index 0000000..7ecb901
--- /dev/null
+++ b/docs/chapters/01-source-code-infrastructure.md
@@ -0,0 +1,89 @@
+# 1 Source Code Infrastructure 🟡
+
+*Infrastructure for hosting and organizing source code consistently across the S-CORE repository landscape.*
+
+**S-CORE**
+
+- GitHub is the canonical source-code hosting platform for S-CORE repositories.
+- Lifecycle and policy management are intended to be centrally defined and automation-driven.
+- Standards should be versioned, measurable, and continuously synchronized across repositories.
+- Hosting is established and operational; lifecycle and standards synchronization are only partially mature.
+- **Biggest gap**: cross-repository consistency of policy and standards is not yet reliably enforced and measured.
+
+## 1.0 Hosting 🟢
+
+*Provide a stable, discoverable, and scalable hosting foundation for all S-CORE repositories.*
+
+**S-CORE**
+
+- Repositories are hosted in GitHub aligned with Eclipse governance on https://github.com/eclipse-score
+
+
+## 1.1 Repository Lifecycle Management 🟠
+
+*Infrastructure for repositories and repository configuration.*
+
+### 1.1.1 Repository Provisioning & Lifecycle 🟡
+
+*Infrastructure for creating, initializing, updating, and archiving repositories and executing lifecycle operations.*
+
+**S-CORE**
+
+- Desired repository state is defined centrally via the infrastructure-as-code tool [otterdog](https://otterdog.readthedocs.io/en/latest/userguide/) in the [S-CORE configuration file](https://github.com/eclipse-score/.eclipsefdn/blob/main/otterdog/eclipse-score.jsonnet)
+- Lifecycle transitions are configuration changes instead of manual one-off actions.
+- **Biggest gap**: approval of changes is rather random and undefined.
+
+### 1.1.2 Repository Policy Management 🔴
+
+*Infrastructure for managing and synchronizing repository policies such as branch protection, and application thereof at scale.*
+
+**S-CORE**
+
+- Policy intent (for example branch protection and required checks) is expressed centrally via the infrastructure-as-code tool [otterdog](https://otterdog.readthedocs.io/en/latest/userguide/) in the [S-CORE configuration file](https://github.com/eclipse-score/.eclipsefdn/blob/main/otterdog/eclipse-score.jsonnet)
+- Exceptions are explicit, reviewed, and documented.
+- **Biggest gap**: policies are not yet uniformly applied to all repositories.
+
+---
+
+## 1.2 Repository Standards 🟡
+
+*Define standard elements expected across repositories to reduce unnecessary variation.*
+
+**S-CORE**
+
+- Standards are centrally defined and versioned.
+- Repositories adopt standards directly or through synchronized templates/configuration.
+- **Biggest gap**: consistency of adoption and conformance visibility remains limited.
+
+### 1.2.1 Repository Metadata 🟡
+
+*Define standard project metadata such as LICENSE, README, and governance files.*
+
+**S-CORE**
+
+- Metadata expectations exist, but rollout and conformance visibility are not yet complete.
+- Automated cross-repository conformance reporting is not yet in place.
+- **Biggest gap**: no continuous cross-repository visibility of metadata conformance.
+
+### 1.2.2 Tooling Configuration Standards 🟠
+
+*Define shared configuration for linters and development tools.*
+
+**S-CORE**
+
+- Shared conventions are emerging, but not yet uniformly synchronized; [chapter 4](04-static-analysis-infrastructure.md) is the canonical home for static-analysis tooling and rule-baseline details.
+- Baseline/override handling is not yet consistently defined across repository types.
+- **Biggest gap**: no clearly enforced baseline/override model across repository classes.
+
+---
+
+## 1.3 Synchronization of Standards 🔴
+
+*Keep repositories aligned with evolving standards through shared templates and configuration synchronization.*
+
+**S-CORE**
+
+- Automation applies and reconciles standards from central definitions.
+- Adoption and drift are tracked to prioritize migration work.
+- Cross-repository synchronization is a target capability and remains incomplete.
+- **Biggest gap**: drift metrics/reporting and migration playbooks are not yet consistently operationalized.
diff --git a/docs/chapters/02-build-infrastructure.md b/docs/chapters/02-build-infrastructure.md
new file mode 100644
index 0000000..6e0c1cb
--- /dev/null
+++ b/docs/chapters/02-build-infrastructure.md
@@ -0,0 +1,202 @@
+# 2 Build Infrastructure (Bazel) ⚪
+
+*Deterministic, reproducible builds across S-CORE repositories using Bazel as the shared build system.*
+
+⚠️ This chapter is written by ChatGPT and was not yet reviewed
+
+**S-CORE**
+
+- Bazel is the standard build system for S-CORE middleware repositories.
+- Shared build rules and toolchain definitions are intended to reduce per-repository configuration duplication.
+- Remote caching is available to reduce repeated build work across CI pipelines.
+- **Biggest gap**: shared build rule libraries, toolchain baselines, and remote execution are not yet consistently available across all S-CORE repositories.
+
+## 2.1 Build System ⚪
+
+*Core build tooling and workspace conventions shared across S-CORE repositories.*
+
+**S-CORE**
+
+- Bazel workspaces are the standard unit of build organization across S-CORE middleware repositories.
+- Shared Bazel rules are provided via the [eclipse-score/tooling](https://github.com/eclipse-score/tooling) repository.
+- **Biggest gap**: workspace structure conventions and target naming standards are not formally defined or enforced cross-repository.
+
+### 2.1.1 Project Structure
+
+*Standard organization of Bazel workspaces across S-CORE repositories.*
+
+**S-CORE**
+
+- Repository layout conventions emerge from shared rule usage but are not yet formally standardized.
+- **Biggest gap**: no centrally enforced or documented reference workspace structure exists.
+
+### 2.1.2 Build Rule Libraries
+
+*Reusable Bazel rules and macros shared across S-CORE repositories.*
+
+**S-CORE**
+
+- Shared Bazel macros and rules are provided via [eclipse-score/tooling](https://github.com/eclipse-score/tooling).
+- **Biggest gap**: rule coverage is incomplete; not all repository types have suitable shared rules.
+
+### 2.1.3 Build Conventions
+
+*Shared target naming and repository layout conventions.*
+
+**S-CORE**
+
+- Naming and layout conventions are expected from shared rule usage but not yet formally documented.
+- **Biggest gap**: no cross-repository convention enforcement mechanism exists.
+
+---
+
+## 2.2 Dependency Management ⚪
+
+*Managing external and internal dependencies in a consistent, auditable way across S-CORE repositories.*
+
+**S-CORE**
+
+- External dependencies are declared per repository in Bazel workspace files; pinning strategies vary.
+- **Biggest gap**: no unified dependency policy or cross-repository version alignment standard exists.
+
+### 2.2.1 Third-Party Dependencies
+
+*Integration and management of external libraries via Bazel.*
+
+**S-CORE**
+
+- External libraries are imported via Bazel's `http_archive` or Bzlmod; no shared registry or approved source list exists.
+- **Biggest gap**: duplicate declarations and version drift across repositories are unmitigated.
+
+### 2.2.2 Internal Module Dependencies
+
+*Managing build-time dependencies between S-CORE repositories.*
+
+**S-CORE**
+
+- Cross-repository artifact consumption relies on pre-built releases or per-repository Bazel rules.
+- **Biggest gap**: no consistent cross-repository dependency resolution model is defined.
+
+### 2.2.3 Dependency Policies
+
+*Rules governing allowed dependencies across S-CORE.*
+
+**S-CORE**
+
+- No formal cross-repository dependency policy currently exists.
+- **Biggest gap**: dependency choices are inconsistent and unaudited without policy guardrails.
+
+---
+
+## 2.3 Toolchain Management ⚪
+
+*Compiler and runtime toolchain configuration for C++, Rust, and Python across S-CORE builds.*
+
+**S-CORE**
+
+- Toolchains are provisioned via the devcontainer for both local and CI builds.
+- **Biggest gap**: toolchain versions diverge across repositories without a shared baseline definition.
+
+### 2.3.1 C++ Toolchains
+
+*Compiler and build configuration for C++ components.*
+
+**S-CORE**
+
+- C++ toolchain configuration is provided through the devcontainer and per-repository Bazel setup.
+- **Biggest gap**: no shared toolchain version target is enforced across S-CORE repositories.
+
+### 2.3.2 Rust Toolchains
+
+*Toolchain configuration for Rust components.*
+
+**S-CORE**
+
+- Rust toolchain rules exist in some repositories; no shared configuration is mandated.
+- **Biggest gap**: no standard Rust toolchain version or `rules_rust` configuration is shared across S-CORE.
+
+### 2.3.3 Python Toolchains
+
+*Python runtime and tooling configuration for build and test.*
+
+**S-CORE**
+
+- Python toolchains vary per repository; no shared Python version baseline is defined.
+- **Biggest gap**: no cross-repository Python toolchain standard is enforced.
+
+---
+
+## 2.4 Build Reproducibility ⚪
+
+*Ensuring builds are deterministic and produce identical outputs from the same inputs.*
+
+**S-CORE**
+
+- Bazel's hermetic execution model is the foundation for reproducibility across S-CORE.
+- **Biggest gap**: hermetic build compliance is not measured or enforced uniformly across repositories.
+
+### 2.4.1 Hermetic Builds
+
+*Isolating builds from host environments to ensure reproducibility.*
+
+**S-CORE**
+
+- The devcontainer provides a stable, isolated build environment for CI and local builds.
+- **Biggest gap**: full hermetic compliance (no host toolchain leakage) is not uniformly verified.
+
+### 2.4.2 Deterministic Artifacts
+
+*Ensuring builds produce identical artifacts from the same inputs.*
+
+**S-CORE**
+
+- Bazel's action graph model is designed for determinism; actual reproducibility is not validated at scale.
+- **Biggest gap**: no cross-repository determinism validation pipeline exists.
+
+### 2.4.3 Build Traceability
+
+*Tracking build inputs, outputs, and provenance metadata.*
+
+**S-CORE**
+
+- Build provenance (SLSA) and input tracking are target capabilities.
+- **Biggest gap**: no build provenance pipeline currently produces or publishes provenance metadata.
+
+---
+
+## 2.5 Build Execution Infrastructure ⚪
+
+*Infrastructure for executing Bazel builds efficiently across CI pipelines.*
+
+**S-CORE**
+
+- Builds run on GitHub Actions using GitHub-hosted and self-hosted runners.
+- A shared Bazel remote cache reduces redundant compile work across pipeline runs.
+- **Biggest gap**: remote build execution (RBE) is not yet available for S-CORE CI pipelines.
+
+### 2.5.1 Remote Cache
+
+*Sharing Bazel build outputs between pipeline runs to reduce rebuild time.*
+
+**S-CORE**
+
+- A shared Bazel remote cache is available to S-CORE CI pipelines.
+- **Biggest gap**: remote cache connectivity and configuration are not uniformly set up across all repositories.
+
+### 2.5.2 Remote Build Execution
+
+*Executing Bazel build actions on remote compute resources.*
+
+**S-CORE**
+
+- RBE infrastructure is not currently provisioned for S-CORE.
+- **Biggest gap**: no RBE backend is available; builds are constrained to single-runner execution.
+
+### 2.5.3 Build Resource Scheduling
+
+*Scheduling and allocating compute resources for build workloads.*
+
+**S-CORE**
+
+- CI runner allocation is handled via GitHub-hosted and self-hosted runner scheduling.
+- **Biggest gap**: no build-aware resource scheduling or prioritization mechanism is in place.
diff --git a/docs/chapters/03-testing-infrastructure.md b/docs/chapters/03-testing-infrastructure.md
new file mode 100644
index 0000000..b89c905
--- /dev/null
+++ b/docs/chapters/03-testing-infrastructure.md
@@ -0,0 +1,216 @@
+# 3 Testing Infrastructure ⚪
+
+*Infrastructure supporting automated testing across S-CORE repositories, excluding CI/CD execution.*
+
+⚠️ This chapter is partially written by ChatGPT and was not yet reviewed
+
+**S-CORE**
+
+- The verification process defines the expected test levels and evidence.
+- This chapter focuses on the implementation view: what exists, where it lives, and what is still missing.
+- Tests are executed via Bazel test rules, providing isolation and incremental caching of build targets.
+- Multi-language test support exists across C++, Rust, and Python, but repository-level conventions still vary.
+- S-CORE distinguishes test levels such as unit tests, component integration tests, feature integration tests, and platform tests.
+- `reference_integration` already provides shared integration-oriented execution and release-level aggregation for parts of the platform.
+- **Biggest gap**: testing infrastructure exists in several strong islands, but platform-wide standardization for aggregation, dashboards, and reusable conventions is still incomplete.
+
+## 3.1 Test Levels ⚪
+
+*Test levels used by the S-CORE verification process and supported by testing infrastructure, from unit scope to platform verification.*
+
+**S-CORE**
+
+- Four test levels are used across S-CORE: unit tests, component integration tests, feature integration tests, and platform tests.
+- Lower levels are mainly implemented in module repositories.
+- Higher integration levels increasingly rely on `reference_integration`.
+- **Biggest gap**: the named test levels are defined in process documentation, but their concrete implementation patterns are not yet equally mature across the whole project.
+
+### 3.1.1 Unit Tests
+
+*Infrastructure supporting verification of software units against detailed design.*
+
+**S-CORE**
+
+- Unit tests are expressed as Bazel `*_test` targets per language.
+- Test code usually lives in `/tests` directories or next to the implementation, depending on repository conventions.
+- C++ execution and coverage are established; Rust support is improving but less complete in some areas.
+- **Biggest gap**: no shared baseline for naming, layout, coverage treatment, and metadata conventions across all S-CORE repositories.
+
+### 3.1.2 Component Integration Tests
+
+*Infrastructure supporting verification of component architecture and component requirements.*
+
+**S-CORE**
+
+- CITs verify component architecture, interfaces, flows, and integration of units into components.
+- CIT execution is primarily handled inside individual repositories via Bazel.
+- **Biggest gap**: repository-specific CIT structure exists, but common patterns for reusable execution and reporting are not yet standardized project-wide.
+
+### 3.1.3 Feature Integration Tests
+
+*Infrastructure supporting verification of feature-level requirements and architecture across module boundaries.*
+
+**S-CORE**
+
+- FITs verify feature-level requirements and architecture across module boundaries.
+- FIT execution is centered in `reference_integration`, where features are integrated as external modules and exercised through shared scenarios.
+- FIT traceability is already being established in `reference_integration`.
+- **Biggest gap**: FIT infrastructure exists, but traceability, language support, and reusable documentation around scenario composition are still evolving.
+
+### 3.1.4 Platform Tests ⚪
+
+*Infrastructure supporting verification of stakeholder requirements on reference targets.*
+
+**S-CORE**
+
+- Platform tests are the highest named verification level in current S-CORE process descriptions.
+- They verify stakeholder requirements on reference hardware and consume evidence from lower integration levels such as FITs.
+- Enabling pieces already exist through `reference_integration`, release assets, and target-oriented frameworks such as ITF.
+- **Biggest gap**: a fully standardized and visible platform-test environment, with broad hardware coverage and unified reporting, is not yet established across S-CORE.
+
+#### 3.1.4.1 Cross-Repository Testing
+
+*Infrastructure supporting tests that span multiple S-CORE repositories.*
+
+**S-CORE**
+
+- Cross-repository testing already exists in practice through `reference_integration`, where multiple repositories are integrated and tested together.
+- This is currently the main shared place for assembling higher-level integration tests.
+- **Biggest gap**: cross-repository execution is available, but it is not yet generalized into a uniformly reusable mechanism for all repositories and all test levels.
+
+#### 3.1.4.2 Scenario Testing
+
+*Infrastructure supporting end-to-end usage scenarios across the middleware.*
+
+**S-CORE**
+
+- Scenario-based testing is used as an execution style for higher integration levels, especially in `reference_integration` and ITF-based environments.
+- The current direction is reusable scenario execution on different targets rather than one monolithic platform-wide harness.
+- **Biggest gap**: scenario authoring, reuse, traceability, and result correlation still require more consistent tooling and documentation.
+
+---
+
+## 3.2 Test Framework Integration ⚪
+
+*Integrating language-specific test frameworks with the Bazel build system.*
+
+**S-CORE**
+
+- Test framework rules for C++, Rust, and Python are configured per repository.
+- Higher-level integration and target-oriented testing additionally rely on shared frameworks such as ITF and repository-specific scenario support.
+- **Biggest gap**: no single shared framework baseline or packaging model is yet mandated across all S-CORE repositories.
+
+### 3.2.1 C++ Test Frameworks
+
+*Infrastructure supporting C++ testing frameworks.*
+
+**S-CORE**
+
+- C++ tests use frameworks such as GoogleTest integrated via Bazel rules.
+- C++ support is one of the more established paths for unit-test execution and coverage reporting.
+- **Biggest gap**: framework versioning and Bazel rule configuration still vary per repository.
+
+### 3.2.2 Rust Test Frameworks
+
+*Infrastructure supporting Rust testing frameworks.*
+
+**S-CORE**
+
+- Rust tests use the native test model mapped into Bazel via `rules_rust`.
+- Rust support is active, but traceability and detailed reporting are still less complete than in established C++ flows.
+- **Biggest gap**: consistent `rules_rust` versioning, coverage/report handling, and metadata support are not yet uniformly available.
+
+### 3.2.3 Python Test Frameworks
+
+*Infrastructure supporting Python testing frameworks.*
+
+**S-CORE**
+
+- Python tests use frameworks such as pytest integrated via Bazel Python rules.
+- Python also acts as an orchestration layer for some higher-level testing workflows.
+- **Biggest gap**: no shared Python test framework and plugin baseline is standardized across repositories.
+
+### 3.2.4 Scenario Test Framework
+
+*Infrastructure supporting scenario based testing for C++ and Rust.*
+
+**S-CORE**
+
+- Scenario-style test support exists for building common scenarios across languages and modules.
+- Shared scenarios can be executed while keeping implementation in language-specific backends.
+- **Biggest gap**: split execution and verification logic can make ownership, traceability, and failure diagnosis harder.
+
+### 3.2.5 ITF Framework
+
+*Infrastructure supporting target-oriented integration and system-like testing.*
+
+**S-CORE**
+
+- ITF is a pytest-based Integration Testing Framework designed for ECU-oriented testing.
+- Current public discussion describes ITF as moving toward a target-agnostic, plugin-based architecture.
+- Target environments include Docker, QEMU virtual machines, and real hardware, with plugins also covering concerns such as DLT handling.
+- **Biggest gap**: ITF Bazel targets do not allow adding test properties for traceability.
+
+---
+
+## 3.3 Test Traceability ⚪
+
+*Infrastructure for tracking traceability between test cases, requirements, and verification evidence.*
+
+**S-CORE**
+
+- Test implementation adds properties about tested requirements to the test report.
+- Docs-as-code consumes all available reports at the build time and creates testlinks in requirements.
+- Tests have their own `virtual needs objects`, which can be queried and referenced even though they are not implemented in the same way as textual requirements.
+- FIT traceability in `reference_integration` is already being established.
+- **Biggest gap**: Rust test targets and some higher-level frameworks still do not support the same degree of traceability metadata as established C++-centric flows.
+
+---
+
+## 3.4 Test Execution ⚪
+
+*Infrastructure for executing automated tests via the build system.*
+
+**S-CORE**
+
+- Tests are defined as Bazel targets and executed via `bazel test`, enabling incremental and cached re-execution.
+- Test re-execution can be forced by adding the `--nocache_test_results` flag.
+- Code coverage analysis always executes tests and does not use cache for correct instrumentation.
+- Higher integration levels additionally rely on shared orchestration, especially in `reference_integration`.
+- **Biggest gap**: test execution standards (target naming, timeout policy, sharding) are not uniformly defined across repositories.
+
+---
+
+## 3.5 Test Reporting ⚪
+
+*Infrastructure for collecting, aggregating, and presenting test results as verification evidence across S-CORE.*
+
+**S-CORE**
+
+- Test results are surfaced per pipeline run via GitHub Actions.
+- For S-CORE releases, test and coverage reports are aggregated and attached to release assets.
+- Some repository-level dashboards already exist, for example around traceability and unit-test or coverage summaries.
+- These outputs provide the evidence needed by the verification process.
+- **Biggest gap**: no centralized platform-wide dashboard or durable cross-repository trend reporting spans all of S-CORE.
+
+### 3.5.1 Result Aggregation
+
+*Infrastructure aggregating test results across CI pipeline runs.*
+
+**S-CORE**
+
+- Test result artifacts are generated per CI run, and release-oriented aggregation already exists for selected shared outputs.
+- `reference_integration` plays an important role in collecting and combining higher-level evidence.
+- **Biggest gap**: aggregation works for some release flows, but continuous project-wide aggregation across repositories and levels is still incomplete.
+
+### 3.5.2 Test Dashboards
+
+*Infrastructure providing dashboards for monitoring test results and trends.*
+
+**S-CORE**
+
+- Individual repositories already expose dashboard-style views for selected concerns such as traceability or unit-test and coverage summaries.
+- No unified dashboard currently gives one consistent view across all repositories and all test levels.
+- **Biggest gap**: test health visibility across S-CORE repositories is absent.
+
+---
diff --git a/docs/chapters/04-automation-integration.md b/docs/chapters/04-automation-integration.md
new file mode 100644
index 0000000..99aade6
--- /dev/null
+++ b/docs/chapters/04-automation-integration.md
@@ -0,0 +1,177 @@
+# 5 Automation Infrastructure & Continuous Integration (CI/CD) ⚪
+
+*Infrastructure integrating code changes safely across S-CORE repositories through automated workflows and quality gates.*
+
+⚠️ This chapter is written by ChatGPT and was not yet reviewed
+
+**S-CORE**
+
+- GitHub Actions is the CI/CD platform for S-CORE; workflows are triggered on pull requests and merges.
+- Reusable workflows shared across repositories reduce duplication and enforce consistent pipeline structure.
+- Pipeline execution relies on both GitHub-hosted cloud runners and hardware test runners.
+- **Biggest gap**: reusable workflow coverage and quality gate consistency across S-CORE repositories are incomplete.
+
+## 5.1 Runners 🟠
+
+*Execution infrastructure used by S-CORE CI pipelines.*
+
+**S-CORE**
+
+- Pipeline execution relies on GitHub-hosted cloud runners and dedicated hardware test runners.
+- **Biggest gap**: hardware runner availability and reliability remain a bottleneck for integration pipelines.
+
+### 5.1.1 SW Test Runners 🟡
+
+*GitHub-hosted runners providing execution environments for CI pipelines.*
+
+**S-CORE**
+
+- Cloud runners cover ARM, x86, and QEMU (with KVM) architectures with autoscaling to match pipeline demand.
+- **Biggest gap**: runner capacity constraints under peak load are not yet fully mitigated.
+
+### 5.1.2 Hardware Test Runners 🔴
+
+*Execution environments for hardware-based testing in S-CORE CI pipelines.*
+
+**S-CORE**
+
+- **Biggest gap**: availability and reliability of hardware runners are not yet at a level that enables consistent automated hardware testing across S-CORE.
+
+---
+
+## 5.2 Reusable Workflows ⚪
+
+*Shared GitHub Actions workflows reused across S-CORE repositories.*
+
+**S-CORE**
+
+- Workflows are defined in `.github/workflows/` per repository; reusable workflows are hosted centrally for cross-repository use.
+- Reusable workflows are intended to standardize build, test, and compliance steps across repositories.
+- Required status checks are configured centrally via [otterdog](https://otterdog.readthedocs.io/en/latest/userguide/) in the [S-CORE configuration](https://github.com/eclipse-score/.eclipsefdn/blob/main/otterdog/eclipse-score.jsonnet).
+- **Biggest gap**: reusable workflow coverage is partial and quality gate definitions are not yet consistently enforced via shared workflows.
+
+### 5.2.1 Workflow Library Coverage
+
+*Completeness of centrally maintained reusable workflows for common CI patterns.*
+
+**S-CORE**
+
+- A shared reusable workflow library exists but does not yet cover all standard S-CORE pipeline scenarios.
+- **Biggest gap**: a complete baseline library for standard build, test, and compliance patterns is not yet fully defined.
+
+### 5.2.2 Build Validation
+
+*Ensuring builds succeed before code is merged, using standardized workflow building blocks.*
+
+**S-CORE**
+
+- Build success is a required check for merges in S-CORE repositories via branch protection configuration.
+- **Biggest gap**: build validation implementation details still vary by repository maturity.
+
+### 5.2.3 Test Validation
+
+*Ensuring tests pass before code is merged, with reusable test workflow patterns.*
+
+**S-CORE**
+
+- Test results gate merges in repositories where test pipelines are set up.
+- **Biggest gap**: test gate coverage remains incomplete across S-CORE repositories.
+
+### 5.2.4 Static Analysis Enforcement
+
+*Executing shared static-analysis checks as reusable CI workflow steps and merge gates.*
+
+**S-CORE**
+
+- CI consumes the shared static-analysis capability described in [chapter 4](04-static-analysis-infrastructure.md) and turns it into workflow runs, status checks, and review-visible results.
+- Reusable workflows should encapsulate execution and reporting so repositories do not reimplement the same enforcement mechanics.
+- **Biggest gap**: reusable workflow coverage and required-check policy for static-analysis gates are not yet consistently applied across repositories.
+
+---
+
+## 5.3 Cross-Repository Integration ⚪
+
+*Validating integration scenarios across S-CORE components in CI beyond single-repository scope.*
+
+**S-CORE**
+
+- Cross-repository integration validation is a target capability; most repositories currently validate in isolation.
+- **Biggest gap**: no shared integration validation pipeline spans multiple S-CORE middleware components.
+
+### 5.3.1 Integration Validation Scope
+
+*Defining which component combinations and dependency chains are validated together.*
+
+**S-CORE**
+
+- Integration coverage is currently limited and often project-specific instead of platform-wide.
+- **Biggest gap**: no agreed minimum integration matrix is defined for S-CORE.
+
+### 5.3.2 Integration Pipeline Orchestration
+
+*Coordinating multi-repository builds and tests as one automated CI flow.*
+
+**S-CORE**
+
+- Multi-repository orchestration is a target capability and not yet standardized.
+- **Biggest gap**: trigger, artifact handover, and result aggregation patterns are not yet unified.
+
+---
+
+## 5.4 Secrets Management ⚪
+
+*Protecting credentials and establishing least-privilege access for CI workflows and runners.*
+
+**S-CORE**
+
+- CI workflows rely on repository, organization, and environment secrets for accessing external systems.
+- OIDC-based short-lived credentials are the preferred pattern where supported, reducing long-lived static secrets.
+- **Biggest gap**: centralized secret inventory, rotation policy enforcement, and usage audits are not yet consistently implemented.
+
+### 5.4.1 Secret Scope and Rotation
+
+*Managing where secrets are stored and how frequently they are rotated.*
+
+**S-CORE**
+
+- Secret scoping follows GitHub constructs (repository, organization, environment), but conventions differ between repositories.
+- **Biggest gap**: no uniform rotation cadence and ownership model is enforced across all CI secrets.
+
+### 5.4.2 Federated Identity (OIDC)
+
+*Replacing static credentials with short-lived identity federation for CI jobs.*
+
+**S-CORE**
+
+- OIDC adoption is progressing for cloud access use cases where providers support federated trust.
+- **Biggest gap**: OIDC usage is not yet standardized across all repositories and target environments.
+
+---
+
+## 5.5 CI Observability ⚪
+
+*Monitoring CI health, performance, and reliability to improve developer feedback loops.*
+
+**S-CORE**
+
+- CI observability relies on GitHub Actions logs, job outcomes, and repository status checks.
+- Key indicators include queue times, job durations, failure rate, and flaky test behavior.
+- **Biggest gap**: no shared observability baseline or dashboard is used consistently across S-CORE repositories.
+
+### 5.5.1 Pipeline Health Metrics
+
+*Tracking execution and quality signals to detect bottlenecks and reliability issues early.*
+
+**S-CORE**
+
+- Pipeline metrics exist in native tooling but are not yet normalized into common S-CORE KPIs.
+- **Biggest gap**: threshold definitions and trend tracking are not centrally aligned.
+
+### 5.5.2 Alerting and Incident Response
+
+*Reacting quickly to CI outages, widespread failures, or degraded feedback latency.*
+
+**S-CORE**
+
+- Notification and incident handling practices exist but differ between repositories and teams.
+- **Biggest gap**: no standard CI incident playbook with shared escalation paths is applied platform-wide.
diff --git a/docs/chapters/04-static-analysis-infrastructure.md b/docs/chapters/04-static-analysis-infrastructure.md
new file mode 100644
index 0000000..e61ac1f
--- /dev/null
+++ b/docs/chapters/04-static-analysis-infrastructure.md
@@ -0,0 +1,170 @@
+# 4 Static Analysis Infrastructure ⚪
+
+*Infrastructure for inspecting S-CORE source code and configuration without executing the software, to enforce quality, consistency, and security expectations across repositories.*
+
+⚠️ This chapter is written by ChatGPT and was not yet reviewed
+
+**S-CORE**
+
+- Static analysis complements testing by finding issues through code and configuration inspection instead of runtime verification.
+- This chapter defines the shared capability: analyzer scope, baseline expectations, rule governance, and ownership boundaries across repositories.
+- Local execution and CI gating consume this capability in their own chapters rather than defining separate analyzer baselines.
+- **Biggest gap**: static analysis is not yet defined and governed as one cross-repository capability with shared tooling, rule baselines, and ownership expectations.
+
+## 4.1 Tooling Baseline ⚪
+
+*Defining which static analysis tools are approved, recommended, or required for different S-CORE repository types and languages.*
+
+**S-CORE**
+
+- Static analysis in S-CORE includes linters, type/interface analyzers, style and import checks, and security-oriented analyzers where appropriate.
+- Tool choice is currently influenced by language ecosystems, repository classes, and existing engineering practice.
+- **Biggest gap**: no explicit cross-repository baseline defines which analyzers are expected by default for C++, Rust, Python, and workflow or documentation assets.
+
+### 4.1.1 Tool Selection Criteria
+
+*Choosing analyzers that fit S-CORE repository needs and can be maintained at scale.*
+
+**S-CORE**
+
+- Tooling decisions should favor analyzers that can be shared across repositories, versioned centrally, and consumed consistently by local and automated execution environments.
+- Shared tools should produce machine-readable results where possible so reporting and policy gates can consume them consistently.
+- **Biggest gap**: selection criteria are implicit and repository-specific instead of centrally documented and reviewable.
+
+### 4.1.2 Repository and Language Baselines
+
+*Establishing default analyzer sets for major repository classes and implementation languages.*
+
+**S-CORE**
+
+- Different repository types need different analyzer sets, but the expected baseline should still be centrally defined.
+- Repository-specific additions are valid when justified by language, framework, or safety needs.
+- **Biggest gap**: baseline analyzer bundles and ownership of deviations are not yet described in one shared place.
+
+---
+
+## 4.2 Shared Rule Configuration ⚪
+
+*Managing analyzer rules, severities, suppressions, and versioning as shared infrastructure instead of ad-hoc repository detail.*
+
+**S-CORE**
+
+- Shared rule configurations are an important part of repository standards and should be versioned like other infrastructure policy artifacts.
+- Repository overrides should be explicit, limited, and explainable rather than silent drift from the shared baseline.
+- **Biggest gap**: no documented baseline-versus-override model exists for static-analysis rules across repository classes.
+
+### 4.2.1 Baseline Rulesets
+
+*Defining centrally maintained defaults for analyzer configuration.*
+
+**S-CORE**
+
+- Central baselines should define default enabled checks, severity handling, and common exclusions.
+- Baselines should be reusable in templates, synchronized configuration, or shared workflow inputs.
+- **Biggest gap**: there is no visible authoritative baseline for static-analysis rules across S-CORE repositories.
+
+### 4.2.2 Overrides and Suppressions
+
+*Allowing repository-specific exceptions without losing visibility or governance.*
+
+**S-CORE**
+
+- Overrides and suppressions are sometimes necessary for migration, generated code, third-party constraints, or language-specific false positives.
+- Exceptions should be narrow, reviewable, and traceable so that debt can be reduced over time.
+- **Biggest gap**: suppressions and local overrides are not yet governed by a shared policy for justification, expiry, or review.
+
+---
+
+## 4.3 Execution Model ⚪
+
+*Defining where and how the shared static-analysis capability should be executed across the engineering flow.*
+
+**S-CORE**
+
+- Static analysis should be executable in multiple contexts, especially local development and CI, without redefining analyzer baselines per context.
+- Different execution contexts can use different subsets or frequencies, but they should all derive from the same shared rules and ownership model.
+- **Biggest gap**: there is no documented execution model that cleanly separates shared analyzer policy from local and CI-specific delivery.
+
+### 4.3.1 Local Execution Expectations
+
+*Defining what static analysis should provide before code reaches CI.*
+
+**S-CORE**
+
+- Contributors should be able to run the shared analyzer baseline early enough to catch common issues before opening or updating a pull request.
+- Local execution should favor fast feedback and alignment with the centrally defined ruleset, while the delivery details belong in [chapter 10](09-developer-environment.md).
+- **Biggest gap**: local execution expectations are not yet defined independently of specific tools such as devcontainers, IDEs, or pre-commit hooks.
+
+### 4.3.2 CI Execution Expectations
+
+*Defining what CI should enforce from the shared static-analysis capability.*
+
+**S-CORE**
+
+- CI should execute the agreed shared analyzer baseline in a consistent, review-visible way and use its outcomes for merge decisions where appropriate.
+- The workflow, reporting, and branch-protection mechanics belong in [chapter 5](04-automation-integration.md), not in the static-analysis capability definition itself.
+- **Biggest gap**: CI enforcement expectations are not yet clearly separated from workflow implementation details.
+
+---
+
+## 4.4 Boundary to Security Static Analysis ⚪
+
+*Clarifying how general static analysis relates to security scanning and SAST.*
+
+**S-CORE**
+
+- Static analysis includes both general code-quality checks and security-relevant inspection, but the security program and its policies remain part of [chapter 11](10-security-infrastructure.md).
+- This chapter is the canonical home for shared tooling, rule configuration, and ownership boundaries that are common across analyzer types.
+- **Biggest gap**: the boundary between quality-oriented analyzers and security scanning is not yet described clearly enough to avoid duplication and ownership gaps.
+
+### 4.4.1 Shared Foundations
+
+*Capabilities shared by quality and security analyzers.*
+
+**S-CORE**
+
+- Tool distribution, execution semantics, baseline configuration, and suppression governance are shared infrastructure concerns across analyzer types.
+- These shared foundations should be managed once and referenced by both engineering-quality and security documentation.
+- **Biggest gap**: SAST is discussed mainly as a security feature, while its shared infrastructure dependencies are not documented holistically.
+
+### 4.4.2 Security-Specific Ownership
+
+*Keeping security policy and risk handling in the security chapter.*
+
+**S-CORE**
+
+- Security-specific topics such as vulnerability triage, security ownership, risk acceptance, and required security gates belong in [chapter 11](10-security-infrastructure.md).
+- This separation keeps the static-analysis chapter focused on shared engineering infrastructure rather than security governance detail.
+- **Biggest gap**: ownership boundaries for SAST configuration versus broader static-analysis infrastructure are not yet explicit.
+
+---
+
+## 4.5 Results and Governance ⚪
+
+*Managing findings, conformance visibility, and analyzer evolution across repositories.*
+
+**S-CORE**
+
+- Static-analysis infrastructure should provide visibility into adoption, drift, and findings without forcing every repository to invent its own process.
+- Governance includes rule changes, false-positive handling, technical-debt baselines, and measurement of conformance to shared expectations.
+- **Biggest gap**: no cross-repository reporting and governance loop currently shows which repositories run which analyzers, with what deviations and outcomes.
+
+### 4.5.1 False Positives and Baselines
+
+*Handling existing findings and noisy rules in a controlled way.*
+
+**S-CORE**
+
+- Migration to stronger analyzers often needs temporary baselines or approved suppressions so repositories can improve incrementally.
+- These mechanisms should reduce noise without hiding ownership or turning exceptions into permanent blind spots.
+- **Biggest gap**: there is no shared approach for introducing analyzers into repositories with existing finding backlogs.
+
+### 4.5.2 Cross-Repository Visibility
+
+*Measuring adoption and conformance of static-analysis standards across S-CORE.*
+
+**S-CORE**
+
+- Cross-repository reporting should show baseline adoption, exceptions, and required-check coverage, not just individual CI job output.
+- This visibility is needed to prioritize migrations and understand where enforcement is still missing.
+- **Biggest gap**: no common dashboard or conformance report currently summarizes static-analysis coverage across S-CORE.
diff --git a/docs/chapters/05-artifact-distribution.md b/docs/chapters/05-artifact-distribution.md
new file mode 100644
index 0000000..19711e8
--- /dev/null
+++ b/docs/chapters/05-artifact-distribution.md
@@ -0,0 +1,97 @@
+# 6 Artifact & Distribution Infrastructure ⚪
+
+*Infrastructure managing build outputs, versioning, and distribution of S-CORE releases.*
+
+⚠️ This chapter is written by ChatGPT and was not yet reviewed
+
+**S-CORE**
+
+- GitHub Releases is the primary mechanism for publishing S-CORE artifacts.
+- Artifact versioning follows semantic versioning aligned with git tagging.
+- SBOM and provenance data should accompany released artifacts for compliance.
+- **Biggest gap**: artifact distribution infrastructure is largely unstructured; no unified artifact storage, retention, or mirroring strategy exists across S-CORE.
+
+## 6.1 Artifact Storage ⚪
+
+*Infrastructure storing build artifacts produced by S-CORE repositories.*
+
+**S-CORE**
+
+- Build artifacts are stored as GitHub Actions artifacts during CI runs; long-term storage relies on GitHub Releases.
+- **Biggest gap**: no shared artifact repository (e.g., OCI registry, package index) is operated for S-CORE.
+
+### 6.1.1 Artifact Repositories
+
+*Storage locations for generated build artifacts across S-CORE.*
+
+**S-CORE**
+
+- GitHub Releases hosts published artifacts; GitHub Actions artifact storage is ephemeral (CI-scope only).
+- **Biggest gap**: no persistent, queryable artifact repository with metadata and dependency resolution exists.
+
+### 6.1.2 Artifact Retention
+
+*Policies controlling how long artifacts are stored.*
+
+**S-CORE**
+
+- GitHub retains release artifacts indefinitely; Actions artifacts expire after a configurable period.
+- **Biggest gap**: no explicit retention policy or lifecycle management is defined for S-CORE artifacts.
+
+---
+
+## 6.2 Artifact Versioning ⚪
+
+*Defining and enforcing consistent version numbering for S-CORE releases.*
+
+**S-CORE**
+
+- Semantic versioning aligned with git tags is the expected standard across S-CORE repositories.
+- **Biggest gap**: versioning conventions are not uniformly enforced or validated across repositories.
+
+### 6.2.1 Versioning Strategy
+
+*Rules for artifact version numbering across S-CORE.*
+
+**S-CORE**
+
+- Semantic versioning (semver) is the expected convention; automation of version increments is not yet standardized.
+- **Biggest gap**: no shared tooling or policy enforces consistent versioning across S-CORE repositories.
+
+### 6.2.2 Release Tagging
+
+*Tagging of releases in version control to mark published artifacts.*
+
+**S-CORE**
+
+- Git tags trigger release pipelines; tag naming conventions exist but are not centrally enforced.
+- **Biggest gap**: no automated tag validation or cross-repository release coordination mechanism exists.
+
+---
+
+## 6.3 Artifact Distribution ⚪
+
+*Infrastructure publishing S-CORE artifacts to downstream consumers.*
+
+**S-CORE**
+
+- Artifacts are primarily distributed via GitHub Releases as downloadable binaries and archives.
+- **Biggest gap**: no mirroring, CDN distribution, or consumer-facing artifact registry is in place.
+
+### 6.3.1 Release Publishing
+
+*Publishing artifacts as GitHub Releases.*
+
+**S-CORE**
+
+- Release publishing pipelines create GitHub Releases and attach artifacts, SBOMs, and checksums.
+- **Biggest gap**: release pipeline standardization across S-CORE repositories is incomplete.
+
+### 6.3.2 Artifact Mirroring
+
+*Replicating artifacts into downstream or partner environments.*
+
+**S-CORE**
+
+- No artifact mirroring infrastructure currently exists for S-CORE.
+- **Biggest gap**: artifacts are only accessible via GitHub; no mirroring or secondary distribution channel is in place.
diff --git a/docs/chapters/06-compliance-infrastructure.md b/docs/chapters/06-compliance-infrastructure.md
new file mode 100644
index 0000000..1153b2c
--- /dev/null
+++ b/docs/chapters/06-compliance-infrastructure.md
@@ -0,0 +1,133 @@
+# 7 Compliance Infrastructure ⚪
+
+*Infrastructure supporting legal and regulatory compliance for S-CORE software.*
+
+⚠️ This chapter is written by ChatGPT and was not yet reviewed
+
+**S-CORE**
+
+- SBOM generation, license compliance, and vulnerability tracking are core compliance requirements for S-CORE releases.
+- License scanning and policy enforcement are partially operational; SBOM publication is a target capability.
+- **Biggest gap**: compliance coverage is uneven across the dependency graph; automation from build through to published release artifacts is incomplete.
+
+## 7.1 SBOM Infrastructure ⚪
+
+*Infrastructure generating and managing software bill of materials for S-CORE repositories.*
+
+**S-CORE**
+
+- SBOMs document the full dependency graph of released S-CORE artifacts for supply chain transparency.
+- **Biggest gap**: SBOM generation coverage across all repositories and publication alongside releases is incomplete.
+
+### 7.1.1 SBOM Generation for Product 🟠
+
+*Generating SBOMs during the build process for released product artifacts.*
+
+**S-CORE**
+
+- SBOM generation from Bazel build graphs is operational in some S-CORE repositories.
+- **Biggest gap**: SBOM generation is not yet uniformly integrated into release pipelines across all repositories.
+
+### 7.1.2 SBOM Generation for Development Environment
+
+*Generating SBOMs for the build toolchain and development environment dependencies.*
+
+**S-CORE**
+
+- Development environment SBOMs (toolchain, devcontainer) are not yet generated.
+- **Biggest gap**: toolchain and devcontainer dependency inventories are undocumented from a compliance perspective.
+
+### 7.1.3 SBOM Publication
+
+*Publishing SBOMs alongside released artifacts.*
+
+**S-CORE**
+
+- SBOM publication as a release artifact is a target capability.
+- **Biggest gap**: no automated SBOM publication step is integrated into current S-CORE release pipelines.
+
+---
+
+## 7.2 License Compliance 🟠
+
+*Infrastructure ensuring open source license obligations for S-CORE dependencies are fulfilled.*
+
+**S-CORE**
+
+- License scanning is in place in some S-CORE repositories and is integrated into CI pipelines.
+- Known license-incompatible dependencies are blocked from merging via policy enforcement tooling.
+- **Biggest gap**: license compliance coverage is not yet consistent across all S-CORE repositories and dependency types.
+
+### 7.2.1 License Scanning 🟠
+
+*Scanning dependencies to detect license information.*
+
+**S-CORE**
+
+- License scanners run as part of CI pipelines in active S-CORE repositories.
+- **Biggest gap**: scan coverage across transitive dependencies and all repository types is not yet complete.
+
+### 7.2.2 License Documentation
+
+*Maintaining documentation of dependency licenses.*
+
+**S-CORE**
+
+- License information is captured as part of SBOM artifacts; no independently maintained license registry exists.
+- **Biggest gap**: no centralized, continuously updated license registry spans all S-CORE dependencies.
+
+### 7.2.3 License Policy Enforcement 🟠
+
+*Enforcing project license policies for dependencies.*
+
+**S-CORE**
+
+- License policy checks block non-compliant dependencies in CI pipelines where configured.
+- **Biggest gap**: policy enforcement is not yet consistently deployed across all S-CORE repositories.
+
+---
+
+## 7.3 Dependency Vulnerability Management ⚪
+
+*Infrastructure tracking and mitigating security vulnerabilities in S-CORE dependencies.*
+
+**S-CORE**
+
+- Vulnerability monitoring for development dependencies relies on Dependabot and GitHub security advisories.
+- **Biggest gap**: systematic vulnerability tracking and remediation across the full S-CORE dependency graph is not operationalized.
+
+### 7.3.1 Development Vulnerability Monitoring
+
+*Detecting vulnerabilities in dependencies during active development.*
+
+**S-CORE**
+
+- GitHub Dependabot provides automated vulnerability alerts for S-CORE repositories with supported dependency files.
+- **Biggest gap**: Dependabot coverage is inconsistent; not all dependency types and lock files are supported.
+
+### 7.3.2 Release Vulnerability Monitoring
+
+*Tracking vulnerabilities that affect already published S-CORE artifacts.*
+
+**S-CORE**
+
+- Post-release vulnerability tracking against published SBOMs is a target capability.
+- **Biggest gap**: no automated process monitors and alerts on vulnerabilities affecting released S-CORE artifacts.
+
+### 7.3.3 Vulnerability Impact Analysis
+
+*Determining which S-CORE artifacts or modules are affected by a vulnerability.*
+
+**S-CORE**
+
+- Impact analysis relies on manual investigation; no cross-repository automated impact triage exists.
+- **Biggest gap**: no tooling supports automated vulnerability-to-artifact impact mapping across S-CORE.
+
+### 7.3.4 Vulnerability Remediation
+
+*Updating, replacing, or patching vulnerable dependencies.*
+
+**S-CORE**
+
+- Dependabot opens automated pull requests for version updates in configured repositories.
+- **Biggest gap**: remediation coverage is limited to Dependabot-supported dependency types; coordinated cross-repository remediation is manual.
diff --git a/docs/chapters/07-documentation-infrastructure.md b/docs/chapters/07-documentation-infrastructure.md
new file mode 100644
index 0000000..f0a7c74
--- /dev/null
+++ b/docs/chapters/07-documentation-infrastructure.md
@@ -0,0 +1,99 @@
+# 7 Documentation Infrastructure 🟡
+
+*Infrastructure supporting engineering documentation across S-CORE repositories.*
+
+⚠️ This chapter is under construction currently and should be treated as WIP ⚠️
+
+**S-CORE**
+
+- Documentation infrastructure in S-CORE currently spans repository documentation sites and engineering-focused docs-as-code capabilities.
+- Documentation is published through CI-driven static site generation and hosting.
+- Engineering traceability (requirements, architecture, design, implementation, tests) is a target capability for functional safety compliance.
+
+## 7.1 Authoring & Tooling 🟡
+
+*Capabilities for writing, structuring, and maintaining documentation in repositories.*
+
+**S-CORE**
+
+- Documentation is authored in version-controlled repositories alongside source code.
+- Markdown and rST are the primary input formats.
+- Rendering of documentation via Sphinx.
+- Allow for plantuml & meermaid diagrams to be used.
+
+### 7.1.1 IDE & Developer Experience 🟡
+
+*Providing fast feedback while authoring documentation locally.*
+
+**S-CORE**
+- Providing live-preview capabilities of documentation 🟢
+- Providing warnings/errors etc. during build time from sphinx extensions 🟢
+- Providing live warnings/errors etc. from sphinx language server 🟡
+
+---
+
+## 7.2 Build, Validation & Publishing 🟡
+
+*Infrastructure for builds, quality checks, and publication of documentation sites.*
+
+### 7.2.1 Deterministic Build and Configuration 🟠
+
+*Ensuring reproducible documentation output across local and CI environments.*
+
+**S-CORE**
+- Using bazel build system to ensure deterministic and reproducible builds
+
+### 7.2.2 Validation, Previews, and Publishing 🟡
+*Providing contributor feedback before merge through fast preview and validation workflows.*
+
+**S-CORE**
+
+- Compliance, where possible, enforced automatically through metamodel definitions 🟢
+- Providing rendered documentation of PR's 🟢
+- Availability to link against specific versions of requirements 🔴
+
+---
+
+## 7.3 Cross-Repository Documentation Integration 🟢
+
+*Connecting documentation across repositories with stable linking and navigation patterns.*
+
+### 7.3.1 Cross-Repository Linking 🟢
+
+*Establishing reliable links across repository boundaries and release versions.*
+
+**S-CORE**
+
+- Enabel integration of external projects documentation into own documentation
+
+### 7.3.2 Shared Navigation and Discovery 🟢
+
+*Making documentation content easier to discover across repository-specific sites.*
+
+- Enable referenze-integration build which allows bi-directional linking of needs etc.
+
+---
+
+## 7.4 Engineering Documentation ⚪
+*Infrastructure supporting requirements, architecture, design, and links to implementation and tests.*
+
+**S-CORE**
+
+- Engineering documentation (requirements, architecture, detailed design) is required for process compliance (e.g. ISO 26262, ASPICE).
+- Architecture visualization and code integration are target capabilities to connect documentation with implementation artifacts.
+
+
+## 7.5 Traceability 🟡
+
+### 7.5.1 Traceability, Code Integration, and Impact Analysis 🟡
+*Linking requirements, design, code, and verification artifacts to support impact analysis.*
+
+
+**S-CORE**
+
+- Possible to link source code to needs 🟢
+- Possible to link test cases to needs 🟢
+- Creation of 'external' needs for test cases via XML file parsing 🟢
+ => This allows for statistics to be done on those test cases
+- Availability to link against specific versions of requirements 🔴
+
diff --git a/docs/chapters/08-infrastructure-operations.md b/docs/chapters/08-infrastructure-operations.md
new file mode 100644
index 0000000..1916743
--- /dev/null
+++ b/docs/chapters/08-infrastructure-operations.md
@@ -0,0 +1,126 @@
+# 9 Infrastructure Operations ⚪
+
+*Infrastructure for operating and maintaining the S-CORE engineering infrastructure.*
+
+⚠️ This chapter is written by ChatGPT and was not yet reviewed
+
+**S-CORE**
+
+- Infrastructure operations covers runner operations, monitoring, dependency maintenance, and governance.
+- Dependabot automates dependency updates for infrastructure tooling across repositories.
+- **Biggest gap**: systematic monitoring, incident handling, and proactive maintenance processes are not yet consistently defined across S-CORE infrastructure.
+
+## 9.1 CI Runner Operations ⚪
+
+*Operating CI execution environments for S-CORE pipelines — out of scope for public S-CORE.*
+
+**S-CORE**
+
+- Self-hosted runner infrastructure is operated by ETAS and is not part of the public S-CORE project.
+- Public S-CORE CI relies on GitHub-hosted runners; no runner operations work is expected from S-CORE contributors.
+- **Biggest gap**: dependency on external runner operations creates a gap in public contributor autonomy.
+
+### 9.1.1 GitHub Public Runners
+
+*GitHub-hosted runners used by S-CORE CI pipelines.*
+
+**S-CORE**
+
+- GitHub-hosted runners are the default execution environment for public S-CORE CI.
+- **Biggest gap**: GitHub-hosted runner capacity and feature availability are outside S-CORE control.
+
+### 9.1.2 Runner Configuration
+
+*Managing runner environment configuration.*
+
+**S-CORE**
+
+- Runner configuration is managed through workflow YAML files and, for self-hosted runners, by the ETAS INFRA team.
+- **Biggest gap**: runner environment consistency and configuration documentation are not maintained in a central, public location.
+
+---
+
+## 9.2 Infrastructure Monitoring ⚪
+
+*Monitoring CI usage, failures, and infrastructure health across S-CORE.*
+
+**S-CORE**
+
+- CI pipeline failures are visible via GitHub Actions; no proactive monitoring or alerting spans S-CORE repositories.
+- **Biggest gap**: no cross-repository infrastructure health dashboard or alert channel exists for S-CORE.
+
+### 9.2.1 CI Usage Monitoring
+
+*Monitoring CI usage patterns and capacity across S-CORE pipelines.*
+
+**S-CORE**
+
+- GitHub Actions provides per-repository usage metrics; no aggregated cross-repository view exists.
+- **Biggest gap**: S-CORE-wide CI usage visibility and capacity planning are not operationalized.
+
+### 9.2.2 Failure Monitoring
+
+*Monitoring failures across S-CORE infrastructure systems.*
+
+**S-CORE**
+
+- Pipeline failures are surfaced per repository via GitHub; no S-CORE-wide failure tracking dashboard exists.
+- **Biggest gap**: recurring failure patterns across S-CORE pipelines are not systematically detected.
+
+---
+
+## 9.3 Infrastructure Maintenance ⚪
+
+*Keeping S-CORE infrastructure tooling and dependencies up to date.*
+
+**S-CORE**
+
+- Dependabot automates version and SHA updates for infrastructure dependencies across S-CORE repositories.
+- **Biggest gap**: proactive maintenance beyond Dependabot (e.g., major tool upgrades, deprecation handling) is not yet structured.
+
+### 9.3.1 Tool Updates
+
+*Updating shared infrastructure tools across S-CORE repositories.*
+
+**S-CORE**
+
+- Tool upgrades (e.g., MkDocs, Bazel, runner images) are performed reactively on a per-repository basis.
+- **Biggest gap**: no coordinated tool update process or shared upgrade playbook exists across S-CORE.
+
+### 9.3.2 Dependency Updates
+
+*Updating infrastructure dependencies across S-CORE repositories.*
+
+**S-CORE**
+
+- [Dependabot](https://github.com/dependabot) automatically opens pull requests to bump dependency versions and SHA hashes.
+- **Biggest gap**: Dependabot coverage is limited to supported dependency file types; non-standard lockfiles are not auto-updated.
+
+---
+
+## 9.4 Infrastructure Governance ⚪
+
+*Guiding and recording the evolution of S-CORE infrastructure.*
+
+**S-CORE**
+
+- Infrastructure decisions and policies are expected to be documented and version-controlled.
+- **Biggest gap**: a structured decision record process and central policy repository are not yet operational across S-CORE.
+
+### 9.4.1 Infrastructure Policies
+
+*Defining policies governing S-CORE infrastructure usage.*
+
+**S-CORE**
+
+- Infrastructure usage policies (runner selection, dependency constraints, tooling standards) are not yet formally documented.
+- **Biggest gap**: no central, versioned policy document set governs S-CORE infrastructure choices.
+
+### 9.4.2 Infrastructure Decision Records
+
+*Documenting major S-CORE infrastructure decisions.*
+
+**S-CORE**
+
+- Architecture Decision Records (ADRs) are a target practice for documenting significant infrastructure decisions.
+- **Biggest gap**: no ADR process or repository is established for S-CORE infrastructure decisions.
diff --git a/docs/chapters/09-developer-environment.md b/docs/chapters/09-developer-environment.md
new file mode 100644
index 0000000..cb5cc39
--- /dev/null
+++ b/docs/chapters/09-developer-environment.md
@@ -0,0 +1,53 @@
+# 10 Developer Environment 🟠
+
+*Environment infrastructure supporting developer productivity and consistency across S-CORE contributors.*
+
+⚠️ This chapter is written by ChatGPT and was not yet reviewed
+
+**S-CORE**
+
+- A shared devcontainer image at [eclipse-score/devcontainer](https://github.com/eclipse-score/devcontainer) standardizes development environments across contributors and CI.
+- Pre-commit hooks provide fast local validation before code submission.
+- **Biggest gap**: local tooling standardization beyond the devcontainer and pre-commit is not yet complete.
+
+## 10.1 Devcontainer 🟠
+
+*Standardized, containerized development environment for S-CORE contributors and CI.*
+
+**S-CORE**
+
+- Devcontainer images are provided at [eclipse-score/devcontainer](https://github.com/eclipse-score/devcontainer) for use by both CI pipelines and local developer environments.
+- The devcontainer standardizes tool versions and configurations across a wide range of compilers, build tools, and runtimes.
+- **Biggest gap**: devcontainer adoption across all S-CORE repositories and contributors is not yet complete.
+
+## 10.2 IDE Integration 🟠
+
+*Integration with development environments and IDEs for S-CORE contributors.*
+
+**S-CORE**
+
+- The [eclipse-score/devcontainer](https://github.com/eclipse-score/devcontainer) includes pre-configured VS Code extensions and workspace settings.
+- IDE configuration via the devcontainer ensures consistent editor tooling (formatting, linting, debugging) across contributors.
+- **Biggest gap**: IDE support beyond VS Code is not covered by the current devcontainer setup.
+
+## 10.3 Local Tooling 🟠
+
+*Local development tooling provided for S-CORE contributors outside of CI.*
+
+**S-CORE**
+
+- Local tooling (build, test, lint, format) is accessible via the devcontainer without manual host configuration.
+- Shared static-analysis tooling and rule-baseline concerns are covered centrally in [chapter 4](04-static-analysis-infrastructure.md); this chapter focuses only on how contributors access that tooling locally.
+- **Biggest gap**: local tooling outside the devcontainer is not standardized; contributors running natively face an inconsistent setup.
+
+## 10.4 Pre-commit Validation 🟠
+
+*Local validation hooks that check code quality before submission.*
+
+**S-CORE**
+
+- [pre-commit](https://pre-commit.com/) hooks validate code locally before push, catching issues such as missing copyright headers or wrong formatting without a CI round-trip.
+- Custom S-CORE pre-commit hooks are provided via [eclipse-score/tooling](https://github.com/eclipse-score/tooling/blob/main/.pre-commit-hooks.yaml).
+- Existing ecosystem pre-commit hooks are used where available; no proprietary mirrors of public hooks are maintained.
+- Pre-commit is one local entry point for shared checks; the policy for which static-analysis checks belong there is defined in [chapter 4](04-static-analysis-infrastructure.md).
+- **Biggest gap**: pre-commit adoption and hook coverage are not uniformly enforced across all S-CORE repositories.
diff --git a/docs/chapters/10-security-infrastructure.md b/docs/chapters/10-security-infrastructure.md
new file mode 100644
index 0000000..8aa4c18
--- /dev/null
+++ b/docs/chapters/10-security-infrastructure.md
@@ -0,0 +1,71 @@
+# 11 Security Infrastructure ⚪
+
+*Infrastructure for managing security aspects of the S-CORE development and release process.*
+
+⚠️ This chapter is written by ChatGPT and was not yet reviewed
+
+**S-CORE**
+
+- Security infrastructure covers secret management, security scanning (SAST, supply chain), and artifact verification.
+- GitHub's native security features (secret scanning, Dependabot, code scanning) provide a baseline.
+- **Biggest gap**: a coherent, cross-repository security infrastructure strategy is not yet defined for S-CORE.
+
+## 11.1 Secret Management ⚪
+
+*Infrastructure for managing credentials and secrets used in S-CORE pipelines.*
+
+**S-CORE**
+
+- Secrets are stored in GitHub repository and organization secrets; access is scoped to the workflows that require them.
+- **Biggest gap**: no secret rotation process, audit trail, or centralized secret lifecycle management exists across S-CORE.
+
+---
+
+## 11.2 Security Scanning ⚪
+
+*Infrastructure for detecting security vulnerabilities in S-CORE code and dependencies.*
+
+**S-CORE**
+
+- GitHub's built-in code scanning (CodeQL) and secret scanning are available to S-CORE repositories.
+- **Biggest gap**: security scanning adoption and configuration are inconsistent across S-CORE repositories.
+
+### 11.2.1 SAST
+
+*Static application security testing for S-CORE code.*
+
+**S-CORE**
+
+- CodeQL and similar SAST tools are available via GitHub Actions for S-CORE repositories.
+- Shared analyzer delivery, execution patterns, and rule-baseline governance overlap with the broader static-analysis capability described in [chapter 4](04-static-analysis-infrastructure.md).
+- Security-specific ownership remains here: SAST policy, risk handling, triage expectations, and required security gates.
+- **Biggest gap**: SAST-specific configuration and required security gate policies are not yet standardized across repositories.
+
+### 11.2.2 Secret Scanning
+
+*Detecting secrets inadvertently committed to S-CORE repositories.*
+
+**S-CORE**
+
+- GitHub's secret scanning detects common credential patterns in S-CORE repository code automatically.
+- **Biggest gap**: custom secret patterns and push protection configuration are not uniformly enabled.
+
+### 11.2.3 Supply Chain Security
+
+*Infrastructure addressing software supply chain threats in S-CORE.*
+
+**S-CORE**
+
+- Dependency pinning (hash-based) for CI actions and build dependencies reduces supply chain risk.
+- **Biggest gap**: SLSA build provenance and artifact signing are not yet operational for S-CORE releases.
+
+---
+
+## 11.3 Artifact Verification ⚪
+
+*Infrastructure for verifying the authenticity and integrity of S-CORE release artifacts.*
+
+**S-CORE**
+
+- Artifact verification (checksums, signatures) for published S-CORE releases is not yet systematically implemented.
+- **Biggest gap**: no artifact signing or verification mechanism is integrated into S-CORE release pipelines.
diff --git a/docs/css/score-theme.css b/docs/css/score-theme.css
new file mode 100644
index 0000000..912d82e
--- /dev/null
+++ b/docs/css/score-theme.css
@@ -0,0 +1,203 @@
+:root {
+ --score-header: #2d1942;
+ --score-accent: #7c4daa;
+ --score-accent-soft: #a382c5;
+ --score-nav-text: #efeaf6;
+}
+
+.wy-nav-side,
+.wy-side-nav-search {
+ background: var(--score-header);
+}
+
+.wy-side-nav-search {
+ border-bottom: 1px solid rgba(255, 255, 255, 0.14);
+ padding: 0.85rem 0 0.65rem;
+}
+
+.wy-side-nav-search > a,
+.wy-side-nav-search .wy-dropdown > a {
+ color: #ffffff;
+ display: flex;
+ flex-direction: column;
+ align-items: center;
+ justify-content: center;
+ gap: 0.15rem;
+}
+
+.wy-side-nav-search > a.icon:before,
+.wy-side-nav-search .wy-dropdown > a.icon:before {
+ display: none;
+}
+
+.wy-side-nav-search > a img.logo,
+.wy-side-nav-search .wy-dropdown > a img.logo {
+ width: min(100px, 62%);
+ height: auto;
+ margin: 0 auto 0.2rem;
+ padding: 0;
+ border-radius: 0;
+ background: transparent;
+}
+
+.wy-side-nav-search > a::after,
+.wy-side-nav-search .wy-dropdown > a::after {
+ content: "S-CORE Infrastructure";
+ margin-bottom: 0.15rem;
+ color: #ffffff;
+ font-size: 0.95rem;
+ font-weight: 700;
+ line-height: 1.1;
+ letter-spacing: 0;
+ text-align: center;
+ white-space: normal;
+}
+
+.wy-side-nav-search input[type="text"] {
+ border-color: var(--score-accent);
+}
+
+.wy-side-nav-search input[type="text"]:focus {
+ border-color: var(--score-accent-soft);
+}
+
+.wy-nav-top {
+ background: var(--score-header);
+}
+
+.wy-nav-top a {
+ color: #ffffff;
+ font-weight: 700;
+}
+
+.wy-nav-top a:before {
+ content: "";
+ display: inline-block;
+ width: 1.05rem;
+ height: 1.05rem;
+ margin-right: 0.45rem;
+ background: url("../img/score-logo.svg") center / contain no-repeat;
+ vertical-align: -0.1rem;
+}
+
+.wy-menu-vertical p.caption,
+.wy-menu-vertical header {
+ color: #c8b7dd;
+}
+
+.wy-menu-vertical a {
+ color: var(--score-nav-text);
+}
+
+.wy-menu-vertical a:hover {
+ background-color: var(--score-accent);
+ color: #ffffff;
+}
+
+.wy-menu-vertical li.current > a {
+ border-right: 3px solid var(--score-accent);
+}
+
+.wy-nav-content-wrap .wy-nav-content {
+ max-width: 940px;
+}
+
+a,
+.rst-content a {
+ color: var(--score-accent);
+}
+
+a:hover,
+.rst-content a:hover {
+ color: #643899;
+}
+
+.rst-versions a,
+.rst-versions .rst-current-version {
+ color: var(--score-accent-soft);
+}
+
+.landing-hero {
+ margin: 0 0 2rem;
+ padding: 1.5rem 1.6rem;
+ border: 1px solid rgba(124, 77, 170, 0.18);
+ border-radius: 18px;
+ background:
+ radial-gradient(circle at top right, rgba(163, 130, 197, 0.18), transparent 38%),
+ linear-gradient(135deg, rgba(45, 25, 66, 0.05), rgba(124, 77, 170, 0.08));
+}
+
+.landing-kicker {
+ margin: 0 0 0.45rem;
+ color: #643899;
+ font-size: 0.8rem;
+ font-weight: 700;
+ letter-spacing: 0.08em;
+ text-transform: uppercase;
+}
+
+.landing-hero h2 {
+ margin: 0 0 0.7rem;
+ font-size: 2rem;
+ line-height: 1.15;
+}
+
+.landing-lead {
+ margin: 0;
+ max-width: 48rem;
+ font-size: 1.05rem;
+ line-height: 1.65;
+}
+
+.landing-grid {
+ display: grid;
+ gap: 1rem;
+ margin: 1rem 0 2rem;
+}
+
+.landing-grid-2 {
+ grid-template-columns: repeat(2, minmax(0, 1fr));
+}
+
+.landing-grid-3 {
+ grid-template-columns: repeat(3, minmax(0, 1fr));
+}
+
+.landing-card {
+ padding: 1.1rem 1.1rem 1rem;
+ border: 1px solid rgba(45, 25, 66, 0.12);
+ border-radius: 14px;
+ background: #ffffff;
+ box-shadow: 0 10px 24px rgba(45, 25, 66, 0.04);
+}
+
+.landing-card h3 {
+ margin-top: 0;
+ margin-bottom: 0.55rem;
+ color: var(--score-header);
+ font-size: 1.05rem;
+}
+
+.landing-card p,
+.landing-card ul {
+ margin-bottom: 0;
+}
+
+.landing-card ul {
+ padding-left: 1.1rem;
+}
+
+.landing-card-compact p {
+ line-height: 1.5;
+}
+
+@media screen and (max-width: 900px) {
+ .landing-grid-2,
+ .landing-grid-3 {
+ grid-template-columns: 1fr;
+ }
+
+ .landing-hero h2 {
+ font-size: 1.6rem;
+ }
+}
diff --git a/docs/img/score-logo.svg b/docs/img/score-logo.svg
new file mode 100644
index 0000000..73b7089
--- /dev/null
+++ b/docs/img/score-logo.svg
@@ -0,0 +1,7 @@
+
+
\ No newline at end of file
diff --git a/docs/index.md b/docs/index.md
new file mode 100644
index 0000000..c5fa4a9
--- /dev/null
+++ b/docs/index.md
@@ -0,0 +1,152 @@
+# S-CORE Infrastructure Landscape
+
+
+
Overview, development map, contribution map, and reference
+
Get oriented in the S-CORE infrastructure landscape.
+
+ This site explains what S-CORE infrastructure is, which building blocks already exist, how mature they are,
+ what is still missing, and how a concrete issue or pull request fits into the bigger picture.
+
+
+
+
+
+
Who this is for
+
+ Technical and non-technical stakeholders who need an overview, plus infrastructure contributors
+ who need to understand the current state, gaps, and direction of the platform.
+
+
+
+
What this repository documents
+
+ The technical capabilities that make engineering work possible and scalable across S-CORE:
+ source code management, builds, testing, static analysis, automation, compliance,
+ documentation, operations, developer environments, and security.
+
+
+
+
What this site is for
+
+ An infrastructure overview, a development map for current state and remaining work,
+ a contribution map for infrastructure contributors, and a reference for architecture
+ and cross-cutting concerns.
+
+
+
+
+## Start Here
+
+
+
+
I need an overview
+
+
Start with the chapter map below.
+
Use the status icon to judge maturity.
+
Open the chapter that matches the area you want to understand.
+
+
+
+
I am working on infrastructure
+
+
Find the most relevant infrastructure chapter.
+
Read the chapter summary and the "Biggest gap".
+
Use that context to place your issue, PR, or initiative in the wider development picture.
+
+
+
+
+## Questions This Page Helps Answer
+
+
+
+
Overview questions
+
+
What do we mean by S-CORE infrastructure?
+
Which infrastructure building blocks already exist?
+
How far along is each area?
+
+
+
+
Contribution questions
+
+
How do we do a specific thing?
+
Where should I look for a topic or responsibility?
+
How does this issue or PR belong to the big picture?