4.6 KiB
| title | linkTitle | weight | description |
|---|---|---|---|
| Traceability | Traceability | 20 | 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 (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
- Part 2.1 (Local IdP creation): IPCEICIS-765
- Part 2.2 (OSC IdP creation): IPCEICIS-766
- Part 2.x.1 (Golden Path template): IPCEICIS-514
- Part 2.x.2 (Fibonacci example app): IPCEICIS-759
- Part 2.x.3 (Forgejo Actions CI/CD): IPCEICIS-760
- Part 2.x.4 (Telemetry): IPCEICIS-761
- Part 2.x.5 (OSC infrastructure): IPCEICIS-762
- Part 2.x.6 (Additional items): IPCEICIS-763
- Part 2.3 (Extended local orchestration): IPCEICIS-767
- Part 3 (User documentation): IPCEICIS-768
Related docs-old pages referenced by the history and matrix:
See also: the central References index.