diff --git a/content/en/docs/governance/_index.md b/content/en/docs/governance/_index.md
index 2ea3276..f059879 100644
--- a/content/en/docs/governance/_index.md
+++ b/content/en/docs/governance/_index.md
@@ -19,242 +19,3 @@ Primary intended audience:
 - Project leads of other IPCEI-CIS sub-projects
 - IPCEI-CIS central architecture
 
-## Project History
-
-### Mandate and product vision
-
-Within the IPCEI-CIS work package for an Edge Developer Framework, the goal of the Developer Framework / EDP effort is to provide services that enable teams to develop, validate, roll out and operate applications efficiently across the edge cloud continuum.
-
-The initial product framing emphasized:
-
-- A coherent developer experience spanning development, testing, validation, rollout, monitoring and (eventually) billing.
-- Reuse through templates and "golden paths".
-- A portal-centric interaction model where developers consume platform capabilities via stable APIs and UI, not ad-hoc cluster access.
-
-Primary source (internal only): [Confluence: Sub Project Developer Framework](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/856788263/Sub+Project+Developer+Framework)
-
-### Phases and milestones
-
-The following phase model is based on the project artifacts currently present in Confluence and this repository. It is intentionally phrased as “what changed and why”, rather than as a release plan.
-
-Terminology note: In this chapter, “Repository” refers to concrete Git repositories used as evidence sources. Unless stated otherwise:
-
-- “Repository (this docs repo)” means this documentation repository (“website-and-documentation”), including `content/en/docs-old/`.
-- “Repository (edp-doc)” means the EDP technical documentation repository at (internal only) [edp.buildth.ing/DevFW/edp-doc](https://edp.buildth.ing/DevFW/edp-doc).
-- “Confluence” refers to the IPCEI-CIS Confluence space on `confluence.telekom-mms.com` (internal only).
-
-It does not refer to the wider set of platform/service code repositories unless explicitly stated.
-
-#### Phase 1 — Discovery & system design (2024)
-
-Focus:
-
-- Establish a reference architecture for an Internal Developer Platform (IDP) style solution.
-- Evaluate IDP foundations (explicitly referencing CNOE as a favored baseline), using a “planes” model as conceptual structure.
-- Early emphasis on becoming self-hosting quickly (“eat your own dogfood”) and validating end-to-end paths.
-
-Primary source (internal only): [Confluence: System Design](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/856788272/System+Design)
-
-#### Phase 2 — Proof of Concept (PoC) definition and scope (2024)
-
-Focus:
-
-- Align on a shared understanding of the product “Developer Platform” (technical and business framing) and what is feasible within 2024.
-- Define PoC goals and acceptance criteria, including an end-to-end story centered on:
-  - an IDP builder/orchestrator running in the target environment (OSC),
-  - a developer portal (Backstage) for the user experience,
-  - a “golden path” flow from source → CI/CD → deployment.
-
-Primary sources:
-
-- Confluence (internal only): [Confluence: Proof of Concept 2024](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/902010138/Proof+of+Concept+2024)
-- Repository (this repo): docs-old PoC structure summary: [PoC Structure](../../docs-old/v1/project/plan-in-2024/poc/)
-
-#### Phase 3 — PoC consolidation: deliverables, repository structure, traceability (late 2024)
-
-Focus:
-
-- Package outputs produced since mid-2024 into a demonstrable PoC product.
-- Make “traces” explicit from backlog items to concrete outputs (repos, docs, capabilities), to support governance and auditability.
-- Establish working agreements for branching, PR-based review, and Definition of Done.
-
-Primary source: repository document [Team and Work Structure](../../docs-old/v1/project/team-process/) (docs-old, in this repo).
-
-#### Phase 4 — “Forgejo as a Service” and Foundry-based provisioning (2025)
-
-Focus:
-
-- Expand from “PoC capabilities” toward a service milestone around Forgejo, including supporting services (persistence, backups, caching, indexing, SSO, runners, observability).
-- Provision Foundry/EDP resources via Infrastructure-as-Code, initially in OTC.
-- Address reliability and migration risks while moving from earlier instances to production endpoints.
-
-Evidence:
-
-- Confluence (internal only): [Confluence: Forgejo as a service](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/999903971/Forgejo+as+a+service) (service decomposition and operational concerns)
-- ADR: “Add Scaleway as Cloud resource Provider” explicitly places Foundry/EDP IaC provisioning in mid-April 2025 and captures platform issues and mitigation.
-- Postmortem (2025-07-14) documents downtime rooted in an incomplete Foundry migration and the need for explicit migration plans.
-
-#### Phase 5 — EdgeConnect integration: deployment target + SDK/tooling (ongoing)
-
-Focus:
-
-- Treat EdgeConnect as a sovereign deployment target operated outside EDP, and provide consumable tooling to integrate it into delivery workflows.
-- Provide reusable automation components (SDK, CLI client, Terraform provider, Forgejo Actions) so that EdgeConnect is used consistently through stable entry points.
-- Use EdgeConnect for deploying project artifacts (including this documentation website) to edge cloudlets.
-
-Evidence:
-
-- Repository (this repo): EdgeConnect documentation under `/docs/edgeconnect/` (SDK/client/actions).
-- Repository (this repo): docs-old “Publishing to Edge” describes the documentation deployment via `edgeconnectdeployment.yaml`.
-
-### Development and delivery process evolution
-
-Across the phases above, delivery methods and team process evolved in response to scaling and operational needs:
-
-- Scrum ceremonies and working agreements are documented in Confluence (internal only): [Confluence: How we SCRUM](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/977833214/How+we+SCRUM).
-- Collaborative delivery techniques (mob / ensemble programming) appear as an explicit practice, including in incident documentation (“Team: Mob”) and internal guidance on sustainable mobbing models.
-
-### Deliverables mapping
-
-This section captures the traceability model and evidence-backed anchors that connect capabilities/phases to concrete outputs (repositories, documentation pages, deployed services). It does not yet claim a complete IPCEI deliverable-ID → epic → artifact mapping.
-
-#### Traceability model (used for audit)
-
-The working model (used throughout the PoC) is:
-
-- Deliverable / capability definition (often in Confluence) →
-- Ticket(s) in Jira / Forgejo →
-- Implementation via commits + pull requests →
-- Concrete output (repo, docs page, automation component, deployed service) →
-- Evidence (ADR / postmortem / runbook / deployment config) showing real operation.
-
-Primary sources for the traceability intent:
-
-- Repository (edp-doc): PoC design README lists Jira parts and calls for a mapping table from “parts” to upstream references.
-- Repository (edp-doc): team-process documents emphasize “traces from tickets to outputs” and an outcome summary in the ticket as part of Definition of Done.
-
-#### Matrix (evidence-backed overview)
-
-This matrix is intended to be directly consumable: it summarizes what can already be evidenced from the current sources. It is an overview across phases/capabilities; it is not the full IPCEI deliverable-ID mapping.
-
-| Phase | What is delivered / proven | Concrete outputs (where) | Evidence / trace hooks |
-| --- | --- | --- | --- |
-| Phase 1 — Discovery & system design | Reference architecture framing and decision drivers | Confluence (internal only): [System Design](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/856788272/System+Design) (planes model, CNOE baseline preference, dogfooding) | Architecture notes are the earliest “why” evidence for later component choices |
-| Phase 2 — PoC definition | PoC scope, acceptance criteria, end-to-end “golden path” story | Repository (this docs repo): PoC structure page (docs-old) and Repository (edp-doc): PoC design README | Jira parts exist for user docs + hands-on building blocks (see “Ticket anchors” below) |
-| Phase 3 — PoC consolidation & traceability | A packaged PoC with explicit traceability from backlog to outputs | Repository (this repo): PoC team-process guidance (Definition of Done, PR review, “traces”) | “Outcome” is expected to be summarized in the ticket with links to PR/commit artifacts |
-| Phase 4 — Forgejo-as-a-Service + Foundry provisioning | A service milestone with operational concerns (persistence, backups, SSO, runners) and IaC provisioning | ADR (Scaleway as additional install channel) + postmortem (Foundry migration downtime) | Concrete operational evidence that architecture and migration risks were handled as governance work |
-| Phase 5 — EdgeConnect integration | EdgeConnect as delivery target and integration tooling | Repository (this repo): EdgeConnect docs section + docs-old “Publishing to Edge” (deployment yaml) | Deployment configuration and workflow description provide concrete “proof of use” |
-
-#### Ticket anchors (PoC)
-
-The PoC design README explicitly provides Jira anchors that can be used to build a full traceability matrix:
-
-- Part 1 (User documentation): [IPCEICIS-368](https://jira.telekom-mms.com/browse/IPCEICIS-368)
-- Part 2.1 (Local IdP creation): [IPCEICIS-765](https://jira.telekom-mms.com/browse/IPCEICIS-765)
-- Part 2.2 (OSC IdP creation): [IPCEICIS-766](https://jira.telekom-mms.com/browse/IPCEICIS-766)
-- Part 2.x.1 (Golden Path template): [IPCEICIS-514](https://jira.telekom-mms.com/browse/IPCEICIS-514)
-- Part 2.x.2 (Fibonacci example app): [IPCEICIS-759](https://jira.telekom-mms.com/browse/IPCEICIS-759)
-- Part 2.x.3 (Forgejo Actions CI/CD): [IPCEICIS-760](https://jira.telekom-mms.com/browse/IPCEICIS-760)
-- Part 2.x.4 (Telemetry): [IPCEICIS-761](https://jira.telekom-mms.com/browse/IPCEICIS-761)
-- Part 2.x.5 (OSC infrastructure): [IPCEICIS-762](https://jira.telekom-mms.com/browse/IPCEICIS-762)
-- Part 2.x.6 (Additional items): [IPCEICIS-763](https://jira.telekom-mms.com/browse/IPCEICIS-763)
-- Part 2.3 (Extended local orchestration): [IPCEICIS-767](https://jira.telekom-mms.com/browse/IPCEICIS-767)
-- Part 3 (User documentation): [IPCEICIS-768](https://jira.telekom-mms.com/browse/IPCEICIS-768)
-
-## Compliance & Audit
-
-### Technology Choices
-
-Documentation of technology evaluation and selection process for key components (e.g., VictoriaMetrics, GARM, Terraform, ArgoCD).
-
-#### Forgejo
-
-The internal service is officially designated as the [Edge Developer Platform (EDP)](../components/forgejo/_index.md). It is hosted at **[edp.buildth.ing](https://edp.buildth.ing)**. The domain selection followed a democratic team process to establish a unique identity distinct from standard corporate naming conventions.
-
-**Solution selection:**
-
-The decision to utilize **[Forgejo](https://forgejo.org/)** as the core self-hosted Git service was driven by specific strategic requirements:
-
-- **EU-Based Stewardship:** Forgejo is stewarded by **[Codeberg e.V.](https://docs.codeberg.org/getting-started/what-is-codeberg/)**, a non-profit organization based in Berlin, Germany. This alignment ensures compliance with GDPR and data sovereignty requirements, placing governance under EU jurisdiction rather than US tech entities.
-- **License Protection (GPL v3+):** Unlike "Open Core" models, Forgejo uses a copyleft license. This legally protects our custom extensions (such as GARM support) from being appropriated into proprietary software, ensuring the ecosystem remains open.
-- **Open Source Strategy:** The platform aligns with the "Public Money, Public Code" philosophy, mandating that funded developments are returned to the community.
-
-**Access Model:**
-
-The platform operates on a hybrid visibility model:
-
-- **Public Access:** The [`DEVFW-CICD`](https://edp.buildth.ing/DevFW-CICD) organization is publicly accessible, fostering transparency.
-- **Private Access:** Sensitive development occurs in restricted organizations (e.g., [`DEVFW`](https://edp.buildth.ing/DevFW)).
-- **User Base:** Primary users include the internal development team, with friendly user access granted to the IPCEI team and MMS BT.
-
-### Security Controls
-
-Overview of implemented security controls and compliance measures.
-
-### Ticket References
-
-Cross-references to Jira tickets, epics, and project tracking for audit trails.
-
-Current, evidence-backed anchors:
-
-- PoC “parts” and hands-on scope are anchored in Jira and listed explicitly in the PoC design README (see Ticket anchors above).
-- PoC consolidation and governance intent (“traces from tickets to outputs”) is described in the team-process documentation.
-- The Forgejo ProjectMgmt prototype documents how tickets, milestones, and boards were structured in Forgejo to run demo slices and work packages.
-
-## Community & External Relations
-
-### Open Source Contributions
-
-Contributions to the Forgejo community and other open-source projects.
-
-#### Forgejo
-
-We actively contributed our extensions back to the upstream Forgejo project on **[Codeberg.org](https://codeberg.org/)**.
-
-**Key Pull Requests:**
-
-- **API Compatibility:** Added GitHub-compatible endpoints for runner registration.
-  - [PR #9409: Feat: Add endpoints for GARM](https://codeberg.org/forgejo/forgejo/pulls/9409)
-- **Webhook Support:** Implemented webhook triggers for workflow events.
-  - [PR #9803: Feat: Add webhook support for workflow events](https://codeberg.org/forgejo/forgejo/pulls/9803)
-- **Ephemeral Runners:** Added support for runners that terminate after a single job.
-  - [PR #9962: Feat: Support for ephemeral runners](https://codeberg.org/forgejo/forgejo/pulls/9962)
-
-### External Stakeholders
-
-User experience research and feedback integration.
-
-## References
-
-This list is an index of all links referenced on this page, plus the intended meaning (“semantics”) of each link.
-
-- (internal only) Confluence: [Sub Project Developer Framework](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/856788263/Sub+Project+Developer+Framework) — mandate, quick links, and high-level framing.
-- (internal only) Confluence: [System Design](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/856788272/System+Design) — architecture framing (planes model, baseline preferences, early decision drivers).
-- (internal only) Confluence: [Proof of Concept 2024](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/902010138/Proof+of+Concept+2024) — PoC scope, goals, and evaluation/acceptance framing.
-- (internal only) Confluence: [Forgejo as a service](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/999903971/Forgejo+as+a+service) — service decomposition and operational concerns used as evidence for Phase 4.
-- (internal only) Confluence: [How we SCRUM](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/977833214/How+we+SCRUM) — delivery process reference.
-- (internal only) Jira: [IPCEICIS-368](https://jira.telekom-mms.com/browse/IPCEICIS-368) — PoC part 1 traceability anchor.
-- (internal only) Jira: [IPCEICIS-765](https://jira.telekom-mms.com/browse/IPCEICIS-765) — PoC part 2.1 traceability anchor.
-- (internal only) Jira: [IPCEICIS-766](https://jira.telekom-mms.com/browse/IPCEICIS-766) — PoC part 2.2 traceability anchor.
-- (internal only) Jira: [IPCEICIS-514](https://jira.telekom-mms.com/browse/IPCEICIS-514) — PoC golden path template traceability anchor.
-- (internal only) Jira: [IPCEICIS-759](https://jira.telekom-mms.com/browse/IPCEICIS-759) — PoC example app traceability anchor.
-- (internal only) Jira: [IPCEICIS-760](https://jira.telekom-mms.com/browse/IPCEICIS-760) — PoC CI/CD traceability anchor.
-- (internal only) Jira: [IPCEICIS-761](https://jira.telekom-mms.com/browse/IPCEICIS-761) — PoC telemetry traceability anchor.
-- (internal only) Jira: [IPCEICIS-762](https://jira.telekom-mms.com/browse/IPCEICIS-762) — PoC infrastructure traceability anchor.
-- (internal only) Jira: [IPCEICIS-763](https://jira.telekom-mms.com/browse/IPCEICIS-763) — PoC additional items traceability anchor.
-- (internal only) Jira: [IPCEICIS-767](https://jira.telekom-mms.com/browse/IPCEICIS-767) — PoC orchestration extension traceability anchor.
-- (internal only) Jira: [IPCEICIS-768](https://jira.telekom-mms.com/browse/IPCEICIS-768) — PoC part 3 (user documentation) traceability anchor.
-- Documentation site: [PoC Structure](../../docs-old/v1/project/plan-in-2024/poc/) — published docs-old summary of the PoC structure.
-- Documentation site: [Team and Work Structure](../../docs-old/v1/project/team-process/) — published docs-old description of process and traceability intent.
-- Documentation site: [Forgejo component page](../components/forgejo/_index.md) — internal documentation entry point for the Forgejo/EDP component.
-- Service entry point: [edp.buildth.ing](https://edp.buildth.ing) — EDP Forgejo instance.
-- Service org: [edp.buildth.ing/DevFW-CICD](https://edp.buildth.ing/DevFW-CICD) — public organization referenced for transparency.
-- Service org: [edp.buildth.ing/DevFW](https://edp.buildth.ing/DevFW) — private organization reference.
-- (internal only) Repository (edp-doc): [edp.buildth.ing/DevFW/edp-doc](https://edp.buildth.ing/DevFW/edp-doc) — EDP technical documentation repository (ADRs, postmortems, PoC process), used as evidence sources in this chapter.
-- Upstream project: [forgejo.org](https://forgejo.org/) — Forgejo project homepage.
-- Upstream governance: [Codeberg e.V.](https://docs.codeberg.org/getting-started/what-is-codeberg/) — referenced as steward/governance body.
-- Upstream contribution: [PR #9409](https://codeberg.org/forgejo/forgejo/pulls/9409) — GARM endpoints contribution.
-- Upstream contribution: [PR #9803](https://codeberg.org/forgejo/forgejo/pulls/9803) — webhook workflow events contribution.
-- Upstream contribution: [PR #9962](https://codeberg.org/forgejo/forgejo/pulls/9962) — ephemeral runners contribution.
-- Upstream hosting: [Codeberg.org](https://codeberg.org/) — hosting platform used for upstream Forgejo contributions.
-
diff --git a/content/en/docs/governance/compliance-audit/_index.md b/content/en/docs/governance/compliance-audit/_index.md
new file mode 100644
index 0000000..d12d07a
--- /dev/null
+++ b/content/en/docs/governance/compliance-audit/_index.md
@@ -0,0 +1,88 @@
+---
+title: "Compliance & audit"
+linkTitle: "Compliance"
+weight: 30
+description: >
+  Technology choices, auditability, and external relations.
+---
+
+## Technology Choices
+
+Documentation of technology evaluation and selection process for key components (e.g., VictoriaMetrics, GARM, Terraform, ArgoCD).
+
+### Forgejo
+
+The internal service is officially designated as the [Edge Developer Platform (EDP)](/docs/edp/forgejo/). It is hosted at **[edp.buildth.ing](https://edp.buildth.ing)**. The domain selection followed a democratic team process to establish a unique identity distinct from standard corporate naming conventions.
+
+**Solution selection:**
+
+The decision to utilize **[Forgejo](https://forgejo.org/)** as the core self-hosted Git service was driven by specific strategic requirements:
+
+- **EU-Based Stewardship:** Forgejo is stewarded by **[Codeberg e.V.](https://docs.codeberg.org/getting-started/what-is-codeberg/)**, a non-profit organization based in Berlin, Germany. This alignment ensures compliance with GDPR and data sovereignty requirements, placing governance under EU jurisdiction rather than US tech entities.
+- **License Protection (GPL v3+):** Unlike "Open Core" models, Forgejo uses a copyleft license. This legally protects our custom extensions (such as GARM support) from being appropriated into proprietary software, ensuring the ecosystem remains open.
+- **Open Source Strategy:** The platform aligns with the "Public Money, Public Code" philosophy, mandating that funded developments are returned to the community.
+
+**Access Model:**
+
+The platform operates on a hybrid visibility model:
+
+- **Public Access:** The [`DEVFW-CICD`](https://edp.buildth.ing/DevFW-CICD) organization is publicly accessible, fostering transparency.
+- **Private Access:** Sensitive development occurs in restricted organizations (e.g., [`DEVFW`](https://edp.buildth.ing/DevFW)).
+- **User Base:** Primary users include the internal development team, with friendly user access granted to the IPCEI team and MMS BT.
+
+## Ticket References
+
+Cross-references to Jira tickets, epics, and project tracking for audit trails.
+
+Current, evidence-backed anchors:
+
+- PoC “parts” and hands-on scope are anchored in Jira and listed explicitly in the PoC design README (see Traceability / Ticket anchors).
+- PoC consolidation and governance intent (“traces from tickets to outputs”) is described in the team-process documentation.
+- The Forgejo ProjectMgmt prototype documents how tickets, milestones, and boards were structured in Forgejo to run demo slices and work packages.
+
+## Open Source Contributions
+
+Contributions to the Forgejo community and other open-source projects.
+
+### Forgejo
+
+We actively contributed our extensions back to the upstream Forgejo project on **[Codeberg.org](https://codeberg.org/)**.
+
+**Key Pull Requests:**
+
+- **API Compatibility:** Added GitHub-compatible endpoints for runner registration.
+  - [PR #9409: Feat: Add endpoints for GARM](https://codeberg.org/forgejo/forgejo/pulls/9409)
+- **Webhook Support:** Implemented webhook triggers for workflow events.
+  - [PR #9803: Feat: Add webhook support for workflow events](https://codeberg.org/forgejo/forgejo/pulls/9803)
+- **Ephemeral Runners:** Added support for runners that terminate after a single job.
+  - [PR #9962: Feat: Support for ephemeral runners](https://codeberg.org/forgejo/forgejo/pulls/9962)
+
+## External Stakeholders
+
+From the beginning, the project used structured stakeholder formats to collect requirements, validate assumptions, and strengthen a product-development mindset beyond “pure delivery”.
+
+Evidence (internal only):
+
+- Stakeholder workshop planning and target groups are captured in Confluence: [eDF Stakeholder Workshops](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/902567168/eDF+Stakeholder+Workshops) (internal/external workshops, goals, and intended outcomes).
+- A concrete external workshop session is documented in Confluence: [external stakeholder workshop](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/936478033/external+stakeholder+workshop) (incl. agenda attachment). Note: the page explicitly contains AI-generated content and should be verified.
+- An internal workshop session with detailed agenda and feedback is documented in Confluence: [internal stakeholder workshop 7.11.](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/915155061/internal+stakeholder+workshop+7.11.) (also includes AI-generated summary blocks).
+
+### What we learned / decided (PII-free synthesis)
+
+The workshop and research artifacts consistently point to a few pragmatic decisions and product learnings (summarized here without personal data[^pii-free]):
+
+- **Onboarding is a primary adoption gate:** prioritize low cognitive load, clear guidance, and a “cold start” path that works without prior context (captured in the Customer Engagement plan and related onboarding-focused activities).
+- **Treat navigation and information architecture as product work:** “too many clicks”, missing global orientation cues, and inconsistent navigation were recurring friction points; prioritization leaned towards making “projects / work” more discoverable and first-class (see UX insights log for navigation/IA patterns).
+- **Forgejo PM & Docs need either redesign or deliberate scope boundaries:** modern PM/docs workflows and stakeholder reporting expectations were a known gap; this informed decisions about prototyping and scoping improvements vs. relying on integrations.
+- **Expect a tension between autonomy and guardrails:** research highlights that developer autonomy is valued while guardrails increase trust and repeatability; positioning matters because “platform” concepts can be perceived as top-down control if not framed carefully.
+- **Institutionalize UX feedback loops:** beyond ad-hoc workshops, the work moved towards a repeatable research cadence (panel/community, surveys, and insight logging) to reduce “one-off feedback” risk.
+- **Automated UX testing was formalized as a concrete use case:** a dedicated “use case identification” artifact structures automated UX testing around functional correctness, visual consistency/accessibility, and task-based end-to-end “happy path” flow checks (used as input for the later UX work package stream).
+
+[^pii-free]: PII = “personally identifiable information”. “PII-free synthesis” means we summarize patterns, decisions, and learnings without including names, participant lists, direct quotes, or other details that could identify individuals.
+
+Later, a dedicated “user experience” focus was strengthened and formalized via a dedicated work package / deliverable stream that explicitly frames UX validation as an activity with objectives, KPIs, and user validation:
+
+- Work package definition and objectives: [Workpackage e.3 - Sustainable-edge-management-optimized user interface for edge developers](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/1165704046/Workpackage+e.3+-+Sustainable-edge-management-optimized+user+interface+for+edge+developers)
+- Deliverable (incl. PoC results summary around autonomous UI/UX testing and “happy path” user flows): [Deliverable D66 - Sustainable-edge-management-optimized user interface for edge developers](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/1165704082/Deliverable+D66+-+Sustainable-edge-management-optimized+user+interface+for+edge+developers)
+
+See also: the central [References](/docs/governance/references/) index.
diff --git a/content/en/docs/governance/project-history/_index.md b/content/en/docs/governance/project-history/_index.md
new file mode 100644
index 0000000..484157f
--- /dev/null
+++ b/content/en/docs/governance/project-history/_index.md
@@ -0,0 +1,102 @@
+---
+title: "Project history"
+linkTitle: "History"
+weight: 10
+description: >
+  Mandate, phases, milestones, and process evolution.
+---
+
+## Mandate and product vision
+
+Within the IPCEI-CIS work package for an Edge Developer Framework, the goal of the Developer Framework / EDP effort is to provide services that enable teams to develop, validate, roll out and operate applications efficiently across the edge cloud continuum.
+
+The initial product framing emphasized:
+
+- A coherent developer experience spanning development, testing, validation, rollout, monitoring and (eventually) billing.
+- Reuse through templates and "golden paths".
+- A portal-centric interaction model where developers consume platform capabilities via stable APIs and UI, not ad-hoc cluster access.
+
+Primary source (internal only): [Confluence: Sub Project Developer Framework](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/856788263/Sub+Project+Developer+Framework)
+
+## Phases and milestones
+
+The following phase model is based on the project artifacts currently present in Confluence and this repository. It is intentionally phrased as “what changed and why”, rather than as a release plan.
+
+Terminology note: In this chapter, “Repository” refers to concrete Git repositories used as evidence sources. Unless stated otherwise:
+
+- “Repository (this docs repo)” means this documentation repository (“website-and-documentation”), including `/docs-old/`.
+- “Repository (edp-doc)” means the EDP technical documentation repository at (internal only) [edp.buildth.ing/DevFW/edp-doc](https://edp.buildth.ing/DevFW/edp-doc).
+- “Confluence” refers to the IPCEI-CIS Confluence space on `confluence.telekom-mms.com` (internal only).
+
+It does not refer to the wider set of platform/service code repositories unless explicitly stated.
+
+### Phase 1 — Discovery & system design (2024)
+
+Focus:
+
+- Establish a reference architecture for an Internal Developer Platform (IDP) style solution.
+- Evaluate IDP foundations (explicitly referencing CNOE as a favored baseline), using a “planes” model as conceptual structure.
+- Early emphasis on becoming self-hosting quickly (“eat your own dogfood”) and validating end-to-end paths.
+
+Primary source (internal only): [Confluence: System Design](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/856788272/System+Design)
+
+### Phase 2 — Proof of Concept (PoC) definition and scope (2024)
+
+Focus:
+
+- Align on a shared understanding of the product “Developer Platform” (technical and business framing) and what is feasible within 2024.
+- Define PoC goals and acceptance criteria, including an end-to-end story centered on:
+  - an IDP builder/orchestrator running in the target environment (OSC),
+  - a developer portal (Backstage) for the user experience,
+  - a “golden path” flow from source → CI/CD → deployment.
+
+Primary sources:
+
+- Confluence (internal only): [Confluence: Proof of Concept 2024](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/902010138/Proof+of+Concept+2024)
+- Repository (this repo): docs-old PoC structure summary: [PoC Structure](/docs-old/v1/project/plan-in-2024/poc/)
+
+### Phase 3 — PoC consolidation: deliverables, repository structure, traceability (late 2024)
+
+Focus:
+
+- Package outputs produced since mid-2024 into a demonstrable PoC product.
+- Make “traces” explicit from backlog items to concrete outputs (repos, docs, capabilities), to support governance and auditability.
+- Establish working agreements for branching, PR-based review, and Definition of Done.
+
+Primary source: repository document [Team and Work Structure](/docs-old/v1/project/team-process/) (docs-old, in this repo).
+
+### Phase 4 — “Forgejo as a Service” and Foundry-based provisioning (2025)
+
+Focus:
+
+- Expand from “PoC capabilities” toward a service milestone around Forgejo, including supporting services (persistence, backups, caching, indexing, SSO, runners, observability).
+- Provision Foundry/EDP resources via Infrastructure-as-Code, initially in OTC.
+- Address reliability and migration risks while moving from earlier instances to production endpoints.
+
+Evidence:
+
+- Confluence (internal only): [Confluence: Forgejo as a service](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/999903971/Forgejo+as+a+service) (service decomposition and operational concerns)
+- ADR: “Add Scaleway as Cloud resource Provider” explicitly places Foundry/EDP IaC provisioning in mid-April 2025 and captures platform issues and mitigation.
+- Postmortem (2025-07-14) documents downtime rooted in an incomplete Foundry migration and the need for explicit migration plans.
+
+### Phase 5 — EdgeConnect integration: deployment target + SDK/tooling (ongoing)
+
+Focus:
+
+- Treat EdgeConnect as a sovereign deployment target operated outside EDP, and provide consumable tooling to integrate it into delivery workflows.
+- Provide reusable automation components (SDK, CLI client, Terraform provider, Forgejo Actions) so that EdgeConnect is used consistently through stable entry points.
+- Use EdgeConnect for deploying project artifacts (including this documentation website) to edge cloudlets.
+
+Evidence:
+
+- Repository (this repo): EdgeConnect documentation under `/docs/edgeconnect/` (SDK/client/actions).
+- Repository (this repo): docs-old “Publishing to Edge” describes the documentation deployment via `edgeconnectdeployment.yaml`.
+
+## Development and delivery process evolution
+
+Across the phases above, delivery methods and team process evolved in response to scaling and operational needs:
+
+- Scrum ceremonies and working agreements are documented in Confluence (internal only): [Confluence: How we SCRUM](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/977833214/How+we+SCRUM).
+- Collaborative delivery techniques (mob / ensemble programming) appear as an explicit practice, including in incident documentation (“Team: Mob”) and internal guidance on sustainable mobbing models.
+
+See also: the central [References](/docs/governance/references/) index.
diff --git a/content/en/docs/governance/references/_index.md b/content/en/docs/governance/references/_index.md
new file mode 100644
index 0000000..70320d2
--- /dev/null
+++ b/content/en/docs/governance/references/_index.md
@@ -0,0 +1,47 @@
+---
+title: "References"
+linkTitle: "References"
+weight: 40
+description: >
+  Index of primary sources and evidence links used across the Governance chapter.
+---
+
+This list is an index of links referenced across the Governance chapter, plus the intended meaning (“semantics”) of each link.
+
+- (internal only) Confluence: [Sub Project Developer Framework](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/856788263/Sub+Project+Developer+Framework) — mandate, quick links, and high-level framing.
+- (internal only) Confluence: [System Design](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/856788272/System+Design) — architecture framing (planes model, baseline preferences, early decision drivers).
+- (internal only) Confluence: [Proof of Concept 2024](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/902010138/Proof+of+Concept+2024) — PoC scope, goals, and evaluation/acceptance framing.
+- (internal only) Confluence: [Forgejo as a service](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/999903971/Forgejo+as+a+service) — service decomposition and operational concerns used as evidence for Phase 4.
+- (internal only) Confluence: [How we SCRUM](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/977833214/How+we+SCRUM) — delivery process reference.
+- (internal only) Confluence: [eDF Stakeholder Workshops](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/902567168/eDF+Stakeholder+Workshops) — plan for internal/external stakeholder workshops, target groups, and intended outcomes.
+- (internal only) Confluence: [internal stakeholder workshop 7.11.](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/915155061/internal+stakeholder+workshop+7.11.) — internal stakeholder session agenda and captured feedback (contains AI-generated summary blocks).
+- (internal only) Confluence: [external stakeholder workshop](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/936478033/external+stakeholder+workshop) — external stakeholder session notes (contains agenda attachment and AI-generated summary blocks).
+- (internal only) Confluence: [Workpackage e.3 - Sustainable-edge-management-optimized user interface for edge developers](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/1165704046/Workpackage+e.3+-+Sustainable-edge-management-optimized+user+interface+for+edge+developers) — UX-focused workpackage with objectives, KPIs, and “validation with users” framing.
+- (internal only) Confluence: [Deliverable D66 - Sustainable-edge-management-optimized user interface for edge developers](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/1165704082/Deliverable+D66+-+Sustainable-edge-management-optimized+user+interface+for+edge+developers) — deliverable page including PoC results summary for autonomous UI/UX testing.
+- (internal only) Confluence: [Customer Engagement](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/1040844220/Customer+Engagement) — research planning cadence (who/why/when), plus synthesized insights/assumptions used to justify PII-free “what we learned” summaries.
+- (internal only) Confluence: [UX Insights and Learnings](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/1033832272/UX+Insights+and+Learnings) — running log of UX observations and recommended improvements (useful for evidence-backed, non-PII synthesis of recurring friction patterns).
+- (internal only) Confluence: [[IPCEICIS-3703] Use Case identification for automated UX testing](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/1055949846/IPCEICIS-3703+Use+Case+identification+for+automated+UX+testing) — structured prioritization of automated UX testing scenarios (happy-path smoke flows, functional correctness, visual/accessibility checks). Note: treat as internal working material; do not replicate embedded credentials/content.
+- (internal only) Jira: [IPCEICIS-368](https://jira.telekom-mms.com/browse/IPCEICIS-368) — PoC part 1 traceability anchor.
+- (internal only) Jira: [IPCEICIS-765](https://jira.telekom-mms.com/browse/IPCEICIS-765) — PoC part 2.1 traceability anchor.
+- (internal only) Jira: [IPCEICIS-766](https://jira.telekom-mms.com/browse/IPCEICIS-766) — PoC part 2.2 traceability anchor.
+- (internal only) Jira: [IPCEICIS-514](https://jira.telekom-mms.com/browse/IPCEICIS-514) — PoC golden path template traceability anchor.
+- (internal only) Jira: [IPCEICIS-759](https://jira.telekom-mms.com/browse/IPCEICIS-759) — PoC example app traceability anchor.
+- (internal only) Jira: [IPCEICIS-760](https://jira.telekom-mms.com/browse/IPCEICIS-760) — PoC CI/CD traceability anchor.
+- (internal only) Jira: [IPCEICIS-761](https://jira.telekom-mms.com/browse/IPCEICIS-761) — PoC telemetry traceability anchor.
+- (internal only) Jira: [IPCEICIS-762](https://jira.telekom-mms.com/browse/IPCEICIS-762) — PoC infrastructure traceability anchor.
+- (internal only) Jira: [IPCEICIS-763](https://jira.telekom-mms.com/browse/IPCEICIS-763) — PoC additional items traceability anchor.
+- (internal only) Jira: [IPCEICIS-767](https://jira.telekom-mms.com/browse/IPCEICIS-767) — PoC orchestration extension traceability anchor.
+- (internal only) Jira: [IPCEICIS-768](https://jira.telekom-mms.com/browse/IPCEICIS-768) — PoC part 3 (user documentation) traceability anchor.
+- Documentation site: [PoC Structure](/docs-old/v1/project/plan-in-2024/poc/) — published docs-old summary of the PoC structure.
+- Documentation site: [Team and Work Structure](/docs-old/v1/project/team-process/) — published docs-old description of process and traceability intent.
+- Documentation site: [Forgejo docs entry](/docs/edp/forgejo/) — documentation entry point for the Forgejo/EDP component.
+- Service entry point: [edp.buildth.ing](https://edp.buildth.ing) — EDP Forgejo instance.
+- Service org: [edp.buildth.ing/DevFW-CICD](https://edp.buildth.ing/DevFW-CICD) — public organization referenced for transparency.
+- Service org: [edp.buildth.ing/DevFW](https://edp.buildth.ing/DevFW) — private organization reference.
+- (internal only) Repository (edp-doc): [edp.buildth.ing/DevFW/edp-doc](https://edp.buildth.ing/DevFW/edp-doc) — EDP technical documentation repository (ADRs, postmortems, PoC process), used as evidence sources in this chapter.
+- Upstream project: [forgejo.org](https://forgejo.org/) — Forgejo project homepage.
+- Upstream governance: [Codeberg e.V.](https://docs.codeberg.org/getting-started/what-is-codeberg/) — referenced as steward/governance body.
+- Upstream contribution: [PR #9409](https://codeberg.org/forgejo/forgejo/pulls/9409) — GARM endpoints contribution.
+- Upstream contribution: [PR #9803](https://codeberg.org/forgejo/forgejo/pulls/9803) — webhook workflow events contribution.
+- Upstream contribution: [PR #9962](https://codeberg.org/forgejo/forgejo/pulls/9962) — ephemeral runners contribution.
+- Upstream hosting: [Codeberg.org](https://codeberg.org/) — hosting platform used for upstream Forgejo contributions.
diff --git a/content/en/docs/governance/traceability/_index.md b/content/en/docs/governance/traceability/_index.md
new file mode 100644
index 0000000..1107969
--- /dev/null
+++ b/content/en/docs/governance/traceability/_index.md
@@ -0,0 +1,61 @@
+---
+title: "Traceability"
+linkTitle: "Traceability"
+weight: 20
+description: >
+  Deliverables mapping, evidence model, matrix overview, and ticket anchors.
+---
+
+## Deliverables mapping
+
+This section captures the traceability model and evidence-backed anchors that connect capabilities/phases to concrete outputs (repositories, documentation pages, deployed services). It does not yet claim a complete IPCEI deliverable-ID → epic → artifact mapping.
+
+## Traceability model (used for audit)
+
+The working model (used throughout the PoC) is:
+
+- Deliverable / capability definition (often in Confluence) →
+- Ticket(s) in Jira / Forgejo →
+- Implementation via commits + pull requests →
+- Concrete output (repo, docs page, automation component, deployed service) →
+- Evidence (ADR / postmortem / runbook / deployment config) showing real operation.
+
+Primary sources for the traceability intent:
+
+- Repository (edp-doc): PoC design README lists Jira parts and calls for a mapping table from “parts” to upstream references.
+- Repository (edp-doc): team-process documents emphasize “traces from tickets to outputs” and an outcome summary in the ticket as part of Definition of Done.
+
+## Matrix (evidence-backed overview)
+
+This matrix is intended to be directly consumable: it summarizes what can already be evidenced from the current sources. It is an overview across phases/capabilities; it is not the full IPCEI deliverable-ID mapping.
+
+| Phase | What is delivered / proven | Concrete outputs (where) | Evidence / trace hooks |
+| --- | --- | --- | --- |
+| Phase 1 — Discovery & system design | Reference architecture framing and decision drivers | Confluence (internal only): [System Design](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/856788272/System+Design) (planes model, CNOE baseline preference, dogfooding) | Architecture notes are the earliest “why” evidence for later component choices |
+| Phase 2 — PoC definition | PoC scope, acceptance criteria, end-to-end “golden path” story | Repository (this docs repo): PoC structure page (docs-old) and Repository (edp-doc): PoC design README | Jira parts exist for user docs + hands-on building blocks (see “Ticket anchors” below) |
+| Phase 3 — PoC consolidation & traceability | A packaged PoC with explicit traceability from backlog to outputs | Repository (this docs repo): PoC team-process guidance (Definition of Done, PR review, “traces”) | “Outcome” is expected to be summarized in the ticket with links to PR/commit artifacts |
+| Phase 4 — Forgejo-as-a-Service + Foundry provisioning | A service milestone with operational concerns (persistence, backups, SSO, runners) and IaC provisioning | ADR (Scaleway as additional install channel) + postmortem (Foundry migration downtime) | Concrete operational evidence that architecture and migration risks were handled as governance work |
+| Phase 5 — EdgeConnect integration | EdgeConnect as delivery target and integration tooling | Repository (this docs repo): EdgeConnect docs section + docs-old “Publishing to Edge” (deployment yaml) | Deployment configuration and workflow description provide concrete “proof of use” |
+
+## Ticket anchors (PoC)
+
+The PoC design README explicitly provides Jira anchors that can be used to build a full traceability matrix:
+
+- Part 1 (User documentation): [IPCEICIS-368](https://jira.telekom-mms.com/browse/IPCEICIS-368)
+- Part 2.1 (Local IdP creation): [IPCEICIS-765](https://jira.telekom-mms.com/browse/IPCEICIS-765)
+- Part 2.2 (OSC IdP creation): [IPCEICIS-766](https://jira.telekom-mms.com/browse/IPCEICIS-766)
+- Part 2.x.1 (Golden Path template): [IPCEICIS-514](https://jira.telekom-mms.com/browse/IPCEICIS-514)
+- Part 2.x.2 (Fibonacci example app): [IPCEICIS-759](https://jira.telekom-mms.com/browse/IPCEICIS-759)
+- Part 2.x.3 (Forgejo Actions CI/CD): [IPCEICIS-760](https://jira.telekom-mms.com/browse/IPCEICIS-760)
+- Part 2.x.4 (Telemetry): [IPCEICIS-761](https://jira.telekom-mms.com/browse/IPCEICIS-761)
+- Part 2.x.5 (OSC infrastructure): [IPCEICIS-762](https://jira.telekom-mms.com/browse/IPCEICIS-762)
+- Part 2.x.6 (Additional items): [IPCEICIS-763](https://jira.telekom-mms.com/browse/IPCEICIS-763)
+- Part 2.3 (Extended local orchestration): [IPCEICIS-767](https://jira.telekom-mms.com/browse/IPCEICIS-767)
+- Part 3 (User documentation): [IPCEICIS-768](https://jira.telekom-mms.com/browse/IPCEICIS-768)
+
+Related docs-old pages referenced by the history and matrix:
+
+- [PoC Structure](/docs-old/v1/project/plan-in-2024/poc/)
+- [Team and Work Structure](/docs-old/v1/project/team-process/)
+
+See also: the central [References](/docs/governance/references/) index.