# Internal Developer Platform Charter: [Platform name]

> Charter for a platform team and the internal developer platform (IDP)
> it builds and runs: mission and outcomes, users and their jobs to be
> done, the platform-as-a-product operating model, scope mapped to the
> 13 platform capabilities and 7 platform attributes of the CNCF
> Platforms White Paper (v1.0, TAG App Delivery, April 2023), the
> interfaces users touch (portal, API, CLI, golden paths), team topology
> and funding, platform SLOs, adoption and developer experience metrics,
> roadmap, governance and review. Structure aligned with the CNCF
> Platforms White Paper, published under CC BY 4.0. Replace every
> `[bracketed]` value and every row marked *Example*. Worked examples use
> the fictional SaaS company "Corvid Commerce" and its platform "Nest".

<!--
Guidance: How to use this template
- Write one charter per platform team. If several teams share one
  platform, write one charter for the platform and one Team API
  (`architecture/team-api`) per team.
- Fill sections 1 to 3 (mission, users, operating model) first and test
  them with three or four product teams before you commit to scope. A
  platform built without named users and measured pain goes unused.
- Section 4 maps scope to the CNCF capability list. Mark each capability
  as provided, curated (third party offered through the platform),
  planned or out of scope. "Out of scope" is a useful answer.
- Each golden path gets its own Platform Golden Path document
  (`architecture/platform-golden-path`); the charter only lists them.
- Re-assess the platform yearly with the Platform Maturity Assessment
  (`architecture/platform-maturity-assessment`) and feed the gaps into
  section 9.
- Common pitfall: a charter that lists tools instead of outcomes. Tools
  belong in the golden path and module specifications.
-->

## Document control

<!-- Guidance: Identify the platform, its sponsor and the funding decision this charter supports. A change in scope or funding model is a new minor version with the reason in the revision history. -->

| Field | Value |
|---|---|
| Document ID | [IDP-CH-001] |
| Platform name | [Nest internal developer platform] |
| Platform team(s) | [@platform-runtime], [@platform-delivery], [@platform-data] |
| Executive sponsor | [@vp-engineering] |
| Platform product manager | [@platform-pm] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@head-of-platform] |
| Approvers/reviewers | [@vp-engineering], [@cto], [@ciso], [@finops-lead], [@product-team-representatives] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal] |
| Charter period | [YYYY-MM-DD to YYYY-MM-DD] |
| Next review | [YYYY-MM-DD] |
| Related documents | [Engineering strategy], [Maturity assessment], [Golden path specs], [Team APIs] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Executive sponsor | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Chief technology officer | [@name] | [Decision] | YYYY-MM-DD |
| Chief information security officer | [@name] | [Decision] | YYYY-MM-DD |
| FinOps lead (funding model) | [@name] | [Decision] | YYYY-MM-DD |
| Product engineering representative | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved at the engineering leadership review |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Data services moved from planned to provided after the maturity re-assessment |

## Contents

<!-- Guidance: Keep this list aligned with the headings. -->

1. [Mission, outcomes and boundaries](#1-mission-outcomes-and-boundaries)
2. [Users and jobs to be done](#2-users-and-jobs-to-be-done)
3. [Platform as a product](#3-platform-as-a-product)
4. [Scope: platform capabilities](#4-scope-platform-capabilities)
5. [Platform attributes as design principles](#5-platform-attributes-as-design-principles)
6. [Interfaces](#6-interfaces)
7. [Team topology, responsibilities and funding](#7-team-topology-responsibilities-and-funding)
8. [Platform SLOs and support](#8-platform-slos-and-support)
9. [Adoption and developer experience metrics](#9-adoption-and-developer-experience-metrics)
10. [Roadmap](#10-roadmap)
11. [Governance and decision making](#11-governance-and-decision-making)
12. [Risks and dependencies](#12-risks-and-dependencies)
13. [Glossary and references](#13-glossary-and-references)

## 1. Mission, outcomes and boundaries

<!-- Guidance: State why the platform exists in terms of the business and product teams, not in terms of technology. Questions: what does a product team gain? What will the platform never do? Pitfall: a mission that would fit any platform team anywhere. -->

**Mission:** [*Example:* Nest lets Corvid Commerce product teams take a
change from idea to production safely and quickly, without tickets, by
offering self-service capabilities that are secure and compliant by
default.]

**Problem statement:** [*Example:* In the last engineering survey, product
teams reported that 30% of their time goes to infrastructure, pipeline
and access work that is repeated in every team. Creating a new service
takes four weeks and nine tickets. Security findings recur across
services because each team configures its own baseline.]

The platform exists to reduce the cognitive load that product teams
carry, to make the secure and compliant way the easiest way, and to let
the organisation make consistent investments once instead of many times.
It is an internal product: product teams are its customers and choose to
use it because it serves them better than the alternatives.

### 1.1 Outcomes

| ID | Outcome | Measure | Baseline | Target (charter period) |
|---|---|---|---|---|
| OUT-001 *(Example)* | Faster path to production for new services | Days from service request to first production deploy | 28 days | 2 days |
| OUT-002 *(Example)* | Less time on undifferentiated infrastructure work | Share of product engineering time on infrastructure (survey) | 30% | 15% |
| OUT-003 *(Example)* | Secure by default | Repeat security findings per service per quarter | 5.2 | below 1 |
| OUT-004 *(Example)* | Consistent cost visibility | Share of cloud cost allocated to an owning team | 71% | 98% |
| [OUT-NNN] | [Outcome] | [Measure] | [Baseline] | [Target] |

### 1.2 Boundaries

| The platform does | The platform does not |
|---|---|
| *Example:* Provide self-service infrastructure, delivery and observability capabilities | Write or operate product teams' application code |
| *Example:* Curate approved third-party services behind one interface | Replace the cloud provider's console for platform engineers |
| *Example:* Own the guardrails that make the default path compliant | Approve product architecture (the architecture review board does) |
| *Example:* Run on call for the platform capabilities it provides | Run on call for product services |
| [Does] | [Does not] |

## 2. Users and jobs to be done

<!-- Guidance: Name the user groups and the jobs they hire the platform for. Base this on interviews and data, not on assumptions. Pitfall: treating "all engineers" as one persona. -->

Describe each user group, what it is trying to get done and the pain it
reports today. Platform features are justified by these jobs, and the
metrics in section 9 test whether the jobs got easier.

| Persona ID | User group | Size | Primary jobs to be done | Current pain | Evidence |
|---|---|---|---|---|---|
| PER-01 *(Example)* | Stream-aligned product engineer | 240 | Create a service, ship a change, debug production | Tickets for databases and access, slow pipelines | Survey Q2, 18 interviews |
| PER-02 *(Example)* | Data engineer | 35 | Provision pipelines and stores, schedule jobs | No standard data stack, manual credentials | 6 interviews |
| PER-03 *(Example)* | Machine learning engineer | 12 | Get GPU capacity, serve models | Capacity requests by email | 4 interviews |
| PER-04 *(Example)* | Engineering manager | 30 | See cost, reliability and delivery of the team | Data spread over five tools | Leadership workshop |
| PER-05 *(Example)* | Security and compliance engineer | 8 | Prove controls across all services | Evidence collected by hand | Audit retrospective |
| PER-06 *(Example)* | Other engineers (QA, mobile, site reliability) | 125 | Run test environments, build mobile releases, operate shared services | Environments requested by ticket, separate mobile pipeline | Survey Q2, 5 interviews |
| [PER-NN] | [Group] | [Number] | [Jobs] | [Pain] | [Source] |

### 2.1 Job stories

Write each job as a short job story: when [situation], I want to
[motivation], so I can [expected outcome]. Keep a register and link each
roadmap item in section 10 to at least one job.

| Job ID | Persona | Job story | Platform capability | Priority |
|---|---|---|---|---|
| JOB-001 *(Example)* | PER-01 | When I start a new service, I want a production-ready repository and pipeline in minutes, so I can ship the first feature the same day | Golden path templates, delivery automation | Must |
| JOB-002 *(Example)* | PER-01 | When an alert fires, I want traces, logs and recent deploys in one view, so I can find the cause without switching tools | Application observability | Must |
| JOB-003 *(Example)* | PER-04 | When I plan the quarter, I want my team's cost and reliability on one page, so I can trade features against debt | Web portal | Should |
| JOB-004 *(Example)* | PER-05 | When an auditor asks, I want control evidence per service exported automatically, so I can answer in hours, not weeks | Security services, portal | Should |
| [JOB-NNN] | [PER-NN] | [Job story] | [Capability] | [Must / Should / Could] |

## 3. Platform as a product

<!-- Guidance: Describe how the team runs the platform as a product: who decides what to build, how users are heard and how value is measured. Pitfall: a "product" team with no product manager and no user research. -->

The CNCF Platforms White Paper names platform as a product as the first
platform attribute, and lists developing the platform together with its
users as one of the main challenges of platform work. This charter commits the platform team to the following product
practices.

| Practice | Commitment | Owner |
|---|---|---|
| Product management | A named platform product manager owns the roadmap, prioritisation and user research | [@platform-pm] |
| User research | *Example:* At least six user interviews per quarter and a twice-yearly developer experience survey | [@platform-pm] |
| Early adopters | *Example:* Two partner product teams co-design every new capability before general availability | [@platform-lead] |
| Feedback channels | Portal feedback button, `#nest-help`, quarterly user forum | [@platform-pm] |
| Release stages | Alpha (partner teams only), beta (opt-in, no SLO), generally available (SLO and support), deprecated (end date published) | [@platform-lead] |
| Optional adoption | Golden paths are recommended, not mandatory, except where section 11 lists an enforced guardrail | [@head-of-platform] |
| Product metrics | Section 9 metrics reviewed monthly by the platform leadership | [@platform-pm] |
| Documentation | Every generally available capability has a getting started guide and reference documentation | Capability owner |

Treat adoption as a signal of value, not as an objective in itself.
When a team chooses not to use a capability, record why in the
feedback register: it is often the cheapest source of roadmap input.

## 4. Scope: platform capabilities

<!-- Guidance: Map scope to the 13 capabilities listed in the CNCF Platforms White Paper. For each, state whether the platform provides it, curates a third-party offer, plans it or leaves it out of scope. Pitfall: claiming all 13 in year one. -->

The CNCF Platforms White Paper lists 13 capability areas that a platform
may offer. The table maps each one to this platform. The capability
names follow the white paper as published; check the current version at
tag-app-delivery.cncf.io before relying on them.

| Cap. ID | CNCF capability | Status | What the platform offers | Owning team | Related specification |
|---|---|---|---|---|---|
| CAP-01 | Web portals for provisioning and observing capabilities | *Example:* Provided | Developer portal with service catalogue, scaffolding and scorecards | [@platform-delivery] | [Portal spec] |
| CAP-02 | APIs for automatically provisioning capabilities | *Example:* Provided | Declarative resource API (claims) for databases, queues and buckets | [@platform-runtime] | Infrastructure as Code Module Specification (`ops/iac-module-specification`) |
| CAP-03 | Golden path templates and docs | *Example:* Provided | Three golden paths: HTTP service, event consumer, batch job | [@platform-delivery] | Platform Golden Path (`architecture/platform-golden-path`) |
| CAP-04 | Automation for building and testing products | *Example:* Provided | Shared pipeline library with build, test, scan, SBOM and signing stages | [@platform-delivery] | [Pipeline spec] |
| CAP-05 | Automation for delivering and verifying services | *Example:* Provided | Progressive delivery with automated canary analysis | [@platform-delivery] | [Delivery spec] |
| CAP-06 | Development environments | *Example:* Planned (Q3) | Per-branch preview environments | [@platform-runtime] | [Spec] |
| CAP-07 | Application observability | *Example:* Provided | OpenTelemetry collection, dashboards and SLO alerting as code | [@platform-runtime] | Observability Specification (`ops/observability-spec`) |
| CAP-08 | Infrastructure services | *Example:* Provided | Shared Kubernetes clusters, managed compute, networking | [@platform-runtime] | Kubernetes Cluster Design (`ops/kubernetes-cluster-design`) |
| CAP-09 | Data services | *Example:* Curated | Managed PostgreSQL and Redis from the cloud provider, exposed through the resource API | [@platform-data] | [Spec] |
| CAP-10 | Messaging and event services | *Example:* Curated | Managed message broker with topic provisioning | [@platform-data] | [Spec] |
| CAP-11 | Identity and secret services | *Example:* Provided | Workload identity and a central secrets store | [@platform-runtime] | Secrets Management Standard (`security/secrets-management-standard`) |
| CAP-12 | Security services | *Example:* Curated | Image scanning, policy enforcement, runtime detection run with the security team | [@security-engineering] | [Spec] |
| CAP-13 | Artifact storage | *Example:* Provided | Container and package registry with retention and signing | [@platform-delivery] | [Spec] |

Status values: **Provided** (built and run by the platform team),
**Curated** (a third-party or provider service offered through platform
interfaces with platform defaults), **Planned** (on the roadmap with a
quarter), **Out of scope** (teams use another route, named in the
notes).

### 4.1 Foundations the platform builds on

List what the platform depends on but does not own, so that ownership
gaps are visible.

| Foundation | Owner | Document |
|---|---|---|
| *Example:* Cloud accounts, network and guardrails | Cloud foundation team | Landing Zone Design (`architecture/landing-zone-design`) |
| *Example:* Cost allocation tags and showback | FinOps team | Cost Allocation and Tagging Standard (`ops/cost-allocation-tagging-standard`) |
| *Example:* Identity provider and single sign-on | IT identity team | [Identity standard] |
| [Foundation] | [Owner] | [Document] |

## 5. Platform attributes as design principles

<!-- Guidance: Turn the 7 platform attributes of the white paper into testable principles for this platform. Each principle needs a test a reviewer can apply to a design. Pitfall: copying the attribute names without saying what they mean here. -->

The white paper describes 7 attributes of a successful platform. The
platform team adopts them as design principles and checks every new
capability against the test in the last column.

| Attribute (CNCF) | Principle for this platform | Design review test |
|---|---|---|
| Platform as a product | We build for named users and measure value | Is there a job story and a partner team for this capability? |
| User experience | Every capability is usable through the portal, API and CLI with the same concepts | Can a new engineer complete the getting started guide in under [30 minutes]? |
| Documentation and onboarding | No capability reaches general availability without documentation and an onboarding path | Do getting started, reference and troubleshooting pages exist? |
| Self-service | Users get capabilities without a ticket or a human approval on the default path | Does the default path need any manual step from the platform team? |
| Reduced cognitive load for users | Users declare intent; the platform handles the detail | How many settings must a user change from the default to reach production? Target: [3 or fewer] |
| Optional and composable | Teams can use one capability without adopting all of them | Can the capability be used outside the golden path through its API? |
| Secure by default | The default configuration meets the security baseline without extra work | Does the default pass policy checks with zero exceptions? |

## 6. Interfaces

<!-- Guidance: Describe every way users reach the platform and how the interfaces stay consistent. Questions: which interface is the source of truth? How are breaking changes handled? Pitfall: a portal that does things the API cannot, so automation breaks. -->

The API is the source of truth. The portal and CLI are clients of the
same API, so that anything a user can do by hand can also be automated.

| Interface | Purpose | Technology | Versioning and change policy | Owner |
|---|---|---|---|---|
| Developer portal | Discover, provision and observe capabilities; service catalogue; scorecards | *Example:* Portal framework with catalogue plug-ins | Continuous; UI changes announced in release notes | [@platform-delivery] |
| Platform API | Declarative provisioning of resources | *Example:* Kubernetes custom resources (claims) | Versioned; breaking change only in a new version with [6 months] overlap | [@platform-runtime] |
| CLI | Local workflows and scripting | *Example:* `nest` CLI | Semantic versioning; deprecations warned for two minor releases | [@platform-delivery] |
| Golden paths | Opinionated end-to-end routes | Templates per path | Each path versioned in its own specification | Path owner |
| Infrastructure as code modules | Reusable building blocks for teams who need more control | *Example:* Module registry | Versioned per module specification | [@platform-runtime] |
| Documentation | Getting started, reference, troubleshooting | Docs as code in the portal | Reviewed with each release | Capability owner |
| Support channels | Questions and incidents | `#nest-help`, platform on call | Section 8 | [@platform-lead] |

The sequence below shows the default self-service flow for a new
database, with no ticket and no manual approval.

```mermaid
sequenceDiagram
  participant Dev as Product engineer
  participant Portal as Developer portal
  participant API as Platform API
  participant Policy as Policy engine
  participant Cloud as Cloud provider
  Dev->>Portal: Request PostgreSQL for service "orders"
  Portal->>API: Create database claim with team and tier
  API->>Policy: Check tags, size limits, data class
  Policy-->>API: Allowed
  API->>Cloud: Provision database with platform defaults
  Cloud-->>API: Endpoint and identity binding
  API-->>Portal: Ready, secret reference stored
  Portal-->>Dev: Connection details and dashboard link
```

## 7. Team topology, responsibilities and funding

<!-- Guidance: Describe how the platform team is organised, how it interacts with other teams and how it is funded. Pitfall: a platform team funded per ticket, which turns it back into a service desk. -->

### 7.1 Team structure and interaction modes

Team types and interaction modes below use the vocabulary of the book
*Team Topologies* (Skelton and Pais). Each platform team also publishes a
Team API (`architecture/team-api`).

| Team | Type | Capabilities owned | Size | Main interaction with product teams |
|---|---|---|---|---|
| *Example:* platform-runtime | Platform | CAP-02, CAP-06, CAP-07, CAP-08, CAP-11 | 7 | X-as-a-Service; collaboration with partner teams during alpha |
| *Example:* platform-delivery | Platform | CAP-01, CAP-03, CAP-04, CAP-05, CAP-13 | 6 | X-as-a-Service |
| *Example:* platform-data | Platform | CAP-09, CAP-10 | 4 | Collaboration until general availability |
| *Example:* developer-enablement | Enabling | Onboarding, training, migration help | 3 | Facilitating |
| [Team] | [Type] | [Capabilities] | [Size] | [Mode] |

### 7.2 Responsibilities (RACI)

R = responsible, A = accountable, C = consulted, I = informed.

| Activity | Platform team | Product team | Security | FinOps | Engineering leadership |
|---|---|---|---|---|---|
| Platform roadmap and prioritisation | A, R | C | C | C | I |
| Capability operation and on call | A, R | I | I | I | I |
| Application code, data and service on call | I | A, R | I | I | I |
| Security baseline and guardrail policy | R | C | A | I | I |
| Cost allocation of platform spend | R | I | I | A | I |
| Exceptions to enforced guardrails | C | R | A | I | I |
| Adoption of golden paths | R | A | I | I | C |
| Funding decision | C | I | I | C | A |

### 7.3 Funding model

| Item | Decision |
|---|---|
| Funding model | *Example:* Central funding for the platform team and shared capabilities; consumption of dedicated resources shown back to product teams |
| Budget owner | [@vp-engineering] |
| Annual run cost | [Amount and currency] |
| Headcount | [Number] FTE (*Example:* 20, of which 17 in the three platform teams and 3 in developer-enablement, funded separately) |
| Shared cost allocation | Per the Cost Allocation and Tagging Standard (`ops/cost-allocation-tagging-standard`) |
| Investment case | [Link to business case or TCO Analysis (`architecture/tco-analysis`)] |
| Review | Funding reviewed yearly against section 9 outcomes |

Choose central funding while adoption is growing, so that teams are not
discouraged from using the platform by a charge. Move to showback once
allocation is reliable and to chargeback only when finance requires it
and teams can influence their consumption.

## 8. Platform SLOs and support

<!-- Guidance: Commit to service levels for each generally available capability, measured from the user's point of view. Pitfall: SLOs on component uptime that users never notice, and none on the journeys they depend on. -->

Each generally available capability has an SLO. Beta and alpha
capabilities have no SLO and say so in the portal. Full SLO documents
follow the SLO Document template (`dev/slo-doc`).

| SLO ID | Capability | User journey | SLI | Objective | Window |
|---|---|---|---|---|---|
| PSLO-01 *(Example)* | CAP-01 Portal | Open the catalogue and service pages | Share of successful page loads under 2 s | 99.5% | 28 days |
| PSLO-02 *(Example)* | CAP-02 Platform API | Provision a database claim | Share of claims ready within 15 min | 99.0% | 28 days |
| PSLO-03 *(Example)* | CAP-04 Build automation | Start a pipeline run | p95 queue time under 2 min | 95% of days | 28 days |
| PSLO-04 *(Example)* | CAP-08 Clusters | Serve workload traffic (control plane and nodes) | Share of minutes with healthy API server and schedulable capacity | 99.95% | 28 days |
| PSLO-05 *(Example)* | CAP-13 Artifact storage | Pull an image during deploy | Share of successful pulls | 99.9% | 28 days |
| [PSLO-NN] | [Capability] | [Journey] | [SLI] | [Objective] | [Window] |

### 8.1 Support model

| Topic | Commitment |
|---|---|
| Hours | *Example:* 24/7 on call for CAP-02, CAP-04, CAP-08, CAP-13; business hours for the rest |
| Incident severity | Per the Incident Severity Matrix (`ops/incident-severity-matrix`) |
| On-call rota | Per the On-call Handbook (`ops/on-call-handbook`) |
| Questions | `#nest-help`, first response within [4 business hours] |
| Feature requests | Portal intake, triaged weekly, decision published within [10 business days] |
| Deprecations | Announced at least [6 months] ahead with a migration guide |
| Maintenance windows | [Day and time], announced [5 business days] ahead |

## 9. Adoption and developer experience metrics

<!-- Guidance: Measure whether the platform makes users' jobs easier, not only whether it is used. Combine system data with survey data. Pitfall: reporting adoption counts alone, which rewards mandates instead of value. -->

The white paper groups platform measurement into three areas: user
satisfaction and productivity, organisational efficiency, and product
and feature delivery. Use at least one metric in each area. Survey
design follows the Developer Experience Survey (`dev/developer-experience-survey`);
delivery metrics come from the Delivery Performance Report
(`dev/delivery-performance-report`), which uses the five DORA software
delivery metrics.

| Metric ID | Area | Metric | Formula or source | Baseline | Target | Cadence |
|---|---|---|---|---|---|---|
| MET-01 *(Example)* | User satisfaction and productivity | Platform satisfaction | Mean of "Nest helps me deliver" on a 1 to 5 scale | 2.9 | 4.0 | Twice yearly |
| MET-02 *(Example)* | User satisfaction and productivity | Time to first production deploy for a new engineer | Median days from start date to first merged change in production | 14 | 3 | Monthly |
| MET-03 *(Example)* | Organisational efficiency | Golden path adoption | Services created from a golden path / all services created in period | 35% | 80% | Monthly |
| MET-04 *(Example)* | Organisational efficiency | Tickets to the platform team per 100 engineers | Ticket count / (engineers / 100) | 42 | 10 | Monthly |
| MET-05 *(Example)* | Organisational efficiency | Allocated cloud cost | Allocation coverage (KPI-02 of the tagging standard): allocated EffectiveCost / total EffectiveCost | 71% | 98% | Monthly |
| MET-06 *(Example)* | Product and feature delivery | Change lead time (DORA) | Median time from commit to production | 3 days | 1 day | Monthly |
| MET-07 *(Example)* | Product and feature delivery | Change fail rate (DORA) | Deployments needing immediate intervention (rollback, hotfix) / deployments | 14% | 8% | Monthly |
| MET-08 *(Example)* | Product and feature delivery | Failed deployment recovery time (DORA) | Median time to recover from a failed deployment | 6 h | 1 h | Monthly |
| [MET-NN] | [Area] | [Metric] | [Formula] | [Baseline] | [Target] | [Cadence] |

*Example* calculation for MET-04: 189 tickets in a month for 450
engineers (the user groups in section 2: 240 + 35 + 12 + 30 + 8 + 125,
platform teams excluded) gives 189 / (450 / 100) = 42 tickets per 100
engineers.

Report these metrics by platform capability and by product team, never
as individual developer performance. Treat a fall in satisfaction with a
rise in adoption as a warning that adoption is being forced.

## 10. Roadmap

<!-- Guidance: Show the next four quarters as outcomes linked to jobs and metrics. Keep the detailed backlog elsewhere. Pitfall: a feature list with no link to user jobs or outcomes. -->

| Quarter | Theme | Roadmap item | Jobs served | Outcome or metric moved | Status |
|---|---|---|---|---|---|
| [Q1 YYYY] | *Example:* Paved road for services | Event consumer golden path generally available | JOB-001 | OUT-001, MET-03 | In progress |
| [Q2 YYYY] | *Example:* Debug faster | Unified trace, log and deploy view in the portal | JOB-002 | MET-01, MET-08 | Planned |
| [Q3 YYYY] | *Example:* Environments on demand | Per-branch preview environments (CAP-06) | JOB-001 | MET-06 | Planned |
| [Q4 YYYY] | *Example:* Evidence as a product | Control evidence export per service | JOB-004 | OUT-003 | Discovery |
| [Quarter] | [Theme] | [Item] | [JOB-NNN] | [OUT or MET] | [Status] |

Publish the roadmap in the portal and review it each quarter with the
user forum. Strategic choices that affect the whole engineering
organisation are recorded in the Engineering Strategy
(`dev/engineering-strategy`) and in architecture decision records.

## 11. Governance and decision making

<!-- Guidance: Say who decides what, how users can propose changes and how enforced guardrails differ from recommended defaults. Pitfall: governance that only says no, which drives teams around the platform. -->

| Forum | Members | Decides | Cadence |
|---|---|---|---|
| Platform steering group | VP engineering, head of platform, CISO delegate, FinOps lead, two product directors | Funding, charter scope, enforced guardrails | Quarterly |
| Platform product review | Platform PM, platform leads, partner team representatives | Roadmap priorities, release stage changes | Monthly |
| Platform user forum | Open to all engineers | Feedback, demos, roadmap input | Quarterly |
| Request for comments | Anyone, using the RFC template (`dev/rfc`) | Proposals for new capabilities or breaking changes | As needed |

### 11.1 Guardrails versus defaults

| Category | Examples | Change authority | Exception route |
|---|---|---|---|
| Enforced guardrail | *Example:* Image signing, no public buckets, mandatory cost tags, secrets in the secrets store | Steering group with security | Time-limited exception with compensating control, approved by the CISO delegate |
| Recommended default | *Example:* Language runtime, database engine, deployment strategy | Platform product review | Team decision recorded in an ADR |
| Free choice | *Example:* Libraries and test tools inside a service | Product team | None needed |

### 11.2 Review of this charter

Review the charter at least yearly and after any change in funding,
team structure or enforced guardrails. Use the Platform Maturity
Assessment (`architecture/platform-maturity-assessment`) as input; it
rates investment, adoption, interfaces, operations and measurement on
the four levels of the CNCF maturity model.

## 12. Risks and dependencies

<!-- Guidance: Record the risks to the platform's success, not only technical risks. Pitfall: ignoring the risk that teams do not adopt. -->

| Risk ID | Risk | Likelihood | Impact | Response | Owner |
|---|---|---|---|---|---|
| RSK-001 *(Example)* | Product teams keep their own pipelines because migration costs them time | High | High | Developer enablement team migrates the first 20 services with them | [@platform-pm] |
| RSK-002 *(Example)* | The platform becomes a single point of failure for all deploys | Medium | High | PSLO-03 and PSLO-05, multi-zone runners, documented break-glass deploy | [@platform-delivery] |
| RSK-003 *(Example)* | Key engineers leave and capability knowledge is lost | Medium | Medium | Pairing, runbooks, two owners per capability | [@head-of-platform] |
| RSK-004 *(Example)* | Funding is cut before outcomes are visible | Medium | High | Quarterly outcome report to the sponsor | [@vp-engineering] |
| [RSK-NNN] | [Risk] | [L] | [I] | [Response] | [@name] |

| Dependency | Provider | Needed for | Status |
|---|---|---|---|
| *Example:* Landing zone with account vending | Cloud foundation team | CAP-02, CAP-08 | Available |
| *Example:* Tagging policy enforcement | FinOps and cloud foundation | MET-05 | In progress |
| [Dependency] | [Provider] | [Capability] | [Status] |

## 13. Glossary and references

<!-- Guidance: Define the platform terms used in this charter and list the sources and companion documents. -->

### 13.1 Glossary

| Term | Meaning |
|---|---|
| Internal developer platform (IDP) | Integrated set of capabilities, interfaces and documentation that internal teams use to build and run software |
| Platform capability | A function the platform offers, such as provisioning a database or running a pipeline |
| Golden path | Supported, opinionated route for a common type of work, also called a paved road |
| Platform as a product | Running the platform with product management, user research and value metrics |
| Self-service | Users obtain a capability without a ticket or manual approval on the default path |
| Cognitive load | Mental effort a team spends on things outside its core domain |
| Guardrail | Enforced control that keeps the default path secure and compliant |
| X-as-a-Service | Interaction mode in which one team consumes another team's offer with minimal collaboration |
| SLO | Service level objective: target for a service level indicator over a window |

### 13.2 References

| Reference | Version or date checked | Use |
|---|---|---|
| CNCF TAG App Delivery, Platforms White Paper, tag-app-delivery.cncf.io/whitepapers/platforms | v1.0 (April 2023), checked 2026-10-24 | 13 capability areas, 7 attributes, measurement areas |
| CNCF TAG App Delivery, Platform Engineering Maturity Model, tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model | v1.0 (announced 2023-11-20), checked 2026-10-24 | Re-assessment input |
| DORA, software delivery performance metrics guide, dora.dev/guides/dora-metrics | Page dated 2026-01-05 | Delivery metric names in section 9 |
| Skelton, M. and Pais, M., *Team Topologies* (book) | Cite only | Team types and interaction modes |
| Platform Golden Path (`architecture/platform-golden-path`) | Companion | One document per golden path |
| Team API (`architecture/team-api`) | Companion | One per platform team |
| Platform Maturity Assessment (`architecture/platform-maturity-assessment`) | Companion | Yearly re-assessment |
| Cost Allocation and Tagging Standard (`ops/cost-allocation-tagging-standard`) | Companion | Funding and showback of platform spend |
| Kubernetes Cluster Design (`ops/kubernetes-cluster-design`) | Companion | Infrastructure services |
| Infrastructure as Code Module Specification (`ops/iac-module-specification`) | Companion | Provisioning building blocks |
| Developer Experience Survey (`dev/developer-experience-survey`) | Companion | Satisfaction metrics |
| Delivery Performance Report (`dev/delivery-performance-report`) | Companion | DORA metrics |

## Standard and licence note

Structure aligned with the Platforms White Paper (v1.0) of the CNCF
Technical Advisory Group for App Delivery, Platforms Working Group,
https://tag-app-delivery.cncf.io/whitepapers/platforms/, © The CNCF
Authors, licensed under Creative Commons Attribution 4.0 International
(CC BY 4.0, https://creativecommons.org/licenses/by/4.0/). The 13
capability names and 7 attribute names are used with attribution; all
descriptions, principles, tests and examples are original to this
collection and are not the white paper's text. DORA metric names follow
dora.dev. Team types and interaction modes are concepts from the book
*Team Topologies*, cited only. Corvid Commerce and Nest are fictional.
Check the current official version of each source before use. Template
licence: MIT.