# Platform Maturity Assessment: [Platform or organisation name] [YYYY]

> Self-assessment of a platform engineering practice against the CNCF
> Platform Engineering Maturity Model (v1.0, TAG App Delivery, announced
> November 2023): five aspects (Investment, Adoption, Interfaces,
> Operations, Measurement) rated on four levels (Provisional,
> Operational, Scalable, Optimizing). For each aspect the assessment
> records evidence, the current level, the target level and the gap,
> then turns the gaps into an improvement backlog with owners and a
> re-assessment date. Structure aligned with the CNCF model, 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
- Run the assessment once a year and after a major change in platform
  funding or structure. The first run sets the baseline.
- The model is descriptive, not a certification. A higher level is not
  automatically better: choose the target level per aspect from the
  business need, and write down why.
- Rate each aspect on its own. Do not average the five ratings into one
  number; a profile shows where to invest, an average hides it.
- Every rating needs evidence (section 3). A rating without evidence is
  an opinion and is recorded as "not rated".
- Include product teams in the panel. A platform team rating its own
  adoption alone will overrate it.
- Feed the backlog (section 7) into the Internal Developer Platform
  Charter (`architecture/internal-developer-platform-charter`) roadmap.
-->

## Document control

<!-- Guidance: Identify the scope of the assessment, the period and the panel. Each assessment run is a new major version; corrections to one run are minor versions. -->

| Field | Value |
|---|---|
| Document ID | [PMA-2026-01] |
| Platform or practice assessed | [Nest internal developer platform] |
| Organisational scope | [Business units, regions or teams covered] |
| Model and version | CNCF Platform Engineering Maturity Model v1.0 |
| Assessment period | [YYYY-MM-DD to YYYY-MM-DD] |
| Assessment lead | [@assessment-lead] |
| Version | [1.0] |
| Status | [Draft / In review / Approved] |
| Owner | [@head-of-platform] |
| Approvers/reviewers | [@vp-engineering], [@platform-pm], [@product-team-representatives] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal] |
| Previous assessment | [PMA-YYYY-NN or "Baseline"] |
| Next assessment due | [YYYY-MM-DD] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Executive sponsor | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Head of platform | [@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] | Draft ratings after interviews |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Ratings calibrated and backlog agreed with the steering group |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Corrected Operations evidence after the incident review |

## Contents

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

1. [Executive summary](#1-executive-summary)
2. [Scope and method](#2-scope-and-method)
3. [Rating scale and evidence rules](#3-rating-scale-and-evidence-rules)
4. [Maturity model overview](#4-maturity-model-overview)
5. [Assessment by aspect](#5-assessment-by-aspect)
6. [Results profile and gaps](#6-results-profile-and-gaps)
7. [Improvement backlog](#7-improvement-backlog)
8. [Re-assessment cadence and triggers](#8-re-assessment-cadence-and-triggers)
9. [Glossary and references](#9-glossary-and-references)

## 1. Executive summary

<!-- Guidance: Write this last. Give the profile, the two or three gaps that matter most and the decisions needed. Pitfall: a single "maturity score" headline that invites the wrong comparison between teams or companies. -->

**Overall picture:** [*Example:* Nest is an operational platform with a
funded team and standard tooling, moving towards a scalable, product-led
platform. Interfaces and Investment are closest to level 3; Measurement
is the weakest and limits every investment decision.]

| Aspect | Current level | Target level (12 months) | Gap | Confidence |
|---|---|---|---|---|
| Investment | *Example:* 2 Operational (3 partly met) | 3 Scalable | 1 | High |
| Adoption | *Example:* 2 Operational | 3 Scalable | 1 | Medium |
| Interfaces | *Example:* 2 Operational (3 partly met) | 3 Scalable | 1 | High |
| Operations | *Example:* 2 Operational | 2 Operational | 0 | Medium |
| Measurement | *Example:* 1 Provisional | 2 Operational | 1 | High |

**Top findings:**

1. [*Example:* No regular measurement of user satisfaction or platform
   value: decisions rely on anecdotes (Measurement, level 1).]
2. [*Example:* Adoption relies on mandates for new services; teams with
   existing pipelines stay off the platform (Adoption, level 2).]
3. [*Example:* Self-service exists for databases and pipelines but not for
   environments or messaging (Interfaces, level 3 partly met).]

**Decisions requested:** [*Example:* Fund one product manager and one
analyst for platform measurement; approve the target levels above;
accept Operations staying at level 2 for twelve months.]

## 2. Scope and method

<!-- Guidance: Describe who and what was assessed and how, so the next run can repeat it. Questions: which teams were sampled? Which artefacts were reviewed? Pitfall: interviewing only the platform team. -->

### 2.1 Scope

| Item | In scope | Notes |
|---|---|---|
| Platforms | [*Example:* Nest (runtime, delivery and data capabilities)] | [Other shared platforms excluded] |
| Teams assessed as providers | [*Example:* platform-runtime, platform-delivery, platform-data, developer-enablement] | |
| Teams sampled as users | [*Example:* 8 of 34 product teams, chosen across 4 business units and both adopters and non-adopters] | Sampling rule in 2.3 |
| Period of evidence | [Last 12 months] | |
| Out of scope | [*Example:* Corporate IT end-user platforms] | |

### 2.2 Assessment panel

| Role | Name | Perspective |
|---|---|---|
| Assessment lead (facilitator, not a platform team member) | [@name] | Neutral facilitation and calibration |
| Platform product manager | [@name] | Provider |
| Platform engineering lead | [@name] | Provider |
| Product engineering manager (adopter team) | [@name] | User |
| Product engineering manager (non-adopter team) | [@name] | User |
| Security representative | [@name] | Guardrails |
| FinOps representative | [@name] | Investment and cost |

### 2.3 Method

The assessment follows five steps.

```mermaid
flowchart LR
  A["Prepare: scope, panel, evidence request"] --> B["Collect: interviews, survey, artefacts, data"]
  B --> C["Rate: each panellist rates each aspect alone"]
  C --> D["Calibrate: discuss differences, agree rating and confidence"]
  D --> E["Plan: target levels, gaps, backlog, next date"]
```

1. **Prepare.** Agree scope, panel and the evidence request list two
   weeks before the first interview.
2. **Collect.** Interview each sampled team for 45 minutes with the same
   questions; run a short user survey; collect artefacts (roadmap,
   budgets, SLO reports, documentation, adoption data).
3. **Rate.** Each panellist rates each aspect independently against
   section 4, citing evidence IDs.
4. **Calibrate.** Discuss every aspect where ratings differ by one level
   or more. Agree a rating and a confidence. Record dissent in the
   aspect notes.
5. **Plan.** Set the target level per aspect, describe the gap and
   create backlog items.

**Sampling rule:** [*Example:* At least 20% of product teams, at least
one team per business unit, and at least two teams that do not use the
platform today.]

## 3. Rating scale and evidence rules

<!-- Guidance: Make the rating rules explicit so two assessors reach the same result. Pitfall: rating the best team's experience as the organisation's level. -->

**Rating rule:** an aspect is at a level when the organisation shows the
characteristics of that level across most of the scope, with evidence of
at least grade E2. When the characteristics of the next level are met
only in part, record the lower level with "(next level partly met)".
Never round up.

| Grade | Evidence strength | Example |
|---|---|---|
| E0 | None | No artefact and no consistent account |
| E1 | Anecdotal | One or two interviewees describe it |
| E2 | Documented | A written process, plan, budget line or configuration exists and is in use |
| E3 | Measured | Data shows the practice over time (adoption trend, survey results, SLO reports) |

**Confidence:** High (E3 evidence and panel agreement), Medium (E2
evidence or one dissent), Low (E1 evidence only). Low confidence ratings
must be re-checked before the next steering review.

Record each piece of evidence once and reference it by ID.

| Evidence ID | Aspect | Description | Grade | Source or link | Collected by |
|---|---|---|---|---|---|
| EV-001 *(Example)* | Investment | Budget line for 17 FTE across the three platform teams in the engineering budget (developer-enablement team of 3 funded separately) | E2 | [Budget link] | [@name] |
| EV-002 *(Example)* | Investment | Platform product manager hired; roadmap published in portal | E2 | [Roadmap link] | [@name] |
| EV-003 *(Example)* | Adoption | 35% of services created in the last 12 months used a golden path; architecture review requires it for new services | E3 | [Portal data] | [@name] |
| EV-004 *(Example)* | Adoption | 5 of 8 sampled teams use the platform only because review requires it | E1 | Interview notes | [@name] |
| EV-005 *(Example)* | Interfaces | Portal, platform API and CLI cover databases, pipelines and registries without tickets | E3 | [Ticket data] | [@name] |
| EV-006 *(Example)* | Interfaces | Environments and messaging still requested by ticket | E2 | [Ticket queue] | [@name] |
| EV-007 *(Example)* | Operations | Capability catalogue with owners; on call for four capabilities; upgrades done centrally by the platform team on request | E2 | [Catalogue] | [@name] |
| EV-008 *(Example)* | Measurement | One survey 14 months ago; no adoption or satisfaction trend | E1 | [Survey file] | [@name] |
| [EV-NNN] | [Aspect] | [Description] | [E0 to E3] | [Source] | [@name] |

## 4. Maturity model overview

<!-- Guidance: Summarise the model so readers do not need the source open. Use the short level labels from the model and describe them in your own words. Pitfall: treating the levels as a staircase every organisation must climb to the top. -->

The CNCF Platform Engineering Maturity Model rates five aspects on four
levels. The model's summary table labels the levels Provisional,
Operational, Scalable and Optimizing; its detailed text calls level 2
"Operationalized". The cell labels below follow the model as published;
the descriptions in section 5 are original. Check the current version at
tag-app-delivery.cncf.io before use.

| Aspect | 1 Provisional | 2 Operational | 3 Scalable | 4 Optimizing |
|---|---|---|---|---|
| Investment | Voluntary or temporary | Dedicated team | As product | Enabled ecosystem |
| Adoption | Erratic | Extrinsic push | Intrinsic pull | Participatory |
| Interfaces | Custom processes | Standard tooling | Self-service solutions | Integrated services |
| Operations | By request | Centrally tracked | Centrally enabled | Managed services |
| Measurement | Ad hoc | Consistent collection | Insights | Quantitative and qualitative |

The levels in short, in this template's words:

- **Level 1 Provisional:** shared capabilities exist because someone
  needed them; they are built and kept alive by spare or temporary
  effort.
- **Level 2 Operational:** a funded team provides common capabilities,
  usually in response to requests.
- **Level 3 Scalable:** the platform is run as a product with a roadmap,
  attention to user experience and investment guided by data.
- **Level 4 Optimizing:** product teams and specialists extend the
  platform themselves; capabilities are composable building blocks and
  the platform team enables an ecosystem.

## 5. Assessment by aspect

<!-- Guidance: For each aspect, answer the guiding question, list observable indicators per level, rate with evidence and state the target. The indicators below are suggestions; adapt them, but keep them observable. Pitfall: indicators that cannot be checked ("teams like the platform"). -->

### 5.1 Investment

**Guiding question:** how are people and money allocated to platform
capabilities, and who decides?

| Level | Observable indicators (adapt) | Met? |
|---|---|---|
| 1 | Platform work is done in spare time or by a temporary project team; no budget line | [Yes / Partly / No] |
| 2 | A named team with a budget line provides shared capabilities; work comes mainly from requests | [Yes / Partly / No] |
| 3 | A product manager owns a roadmap; funding is tied to user outcomes and reviewed with data | [Yes / Partly / No] |
| 4 | Product teams and specialists fund or contribute capabilities through an agreed model | [Yes / Partly / No] |

| Field | Entry |
|---|---|
| Evidence | *Example:* EV-001, EV-002 |
| Current level | *Example:* 2 Operational (3 partly met: product manager in post, funding not yet tied to outcomes) |
| Target level and reason | *Example:* 3 Scalable, so that funding follows measured user value |
| Confidence | *Example:* High |
| Notes and dissent | [Notes] |

### 5.2 Adoption

**Guiding question:** why and how do users start and keep using the
platform?

| Level | Observable indicators (adapt) | Met? |
|---|---|---|
| 1 | Use is sporadic and depends on personal contacts; no organisation-wide view of use | [Yes / Partly / No] |
| 2 | Use is driven by mandates, review gates or incentives from outside the user teams | [Yes / Partly / No] |
| 3 | Teams choose the platform because it is the easiest route; adoption grows without new mandates | [Yes / Partly / No] |
| 4 | Users contribute features, templates or fixes back to the platform | [Yes / Partly / No] |

| Field | Entry |
|---|---|
| Evidence | *Example:* EV-003, EV-004 |
| Current level | *Example:* 2 Operational |
| Target level and reason | *Example:* 3 Scalable, measured as golden path adoption above 60% without new mandates |
| Confidence | *Example:* Medium (interview evidence only for motivation) |
| Notes and dissent | *Example:* One panellist rated 1 because older services remain off the platform; agreed 2 because new services are consistently onboarded |

### 5.3 Interfaces

**Guiding question:** how do users discover and consume platform
capabilities?

| Level | Observable indicators (adapt) | Met? |
|---|---|---|
| 1 | Each capability has its own request process, often a ticket or a message to a person | [Yes / Partly / No] |
| 2 | Standard tools and templates exist, but provisioning still needs platform team steps | [Yes / Partly / No] |
| 3 | Users provision and observe capabilities on their own through a portal, API or CLI, with documentation | [Yes / Partly / No] |
| 4 | Capabilities are built into the tools teams already use and offered as composable building blocks that users can combine, customise or decompose | [Yes / Partly / No] |

| Field | Entry |
|---|---|
| Evidence | *Example:* EV-005, EV-006 |
| Current level | *Example:* 2 Operational (3 partly met: self-service for 3 of 5 high-demand capabilities) |
| Target level and reason | *Example:* 3 Scalable for environments and messaging, removing the two largest ticket queues |
| Confidence | *Example:* High |
| Notes and dissent | [Notes] |

### 5.4 Operations

**Guiding question:** how are platform capabilities planned, run, updated
and retired over their lifecycle?

| Level | Observable indicators (adapt) | Met? |
|---|---|---|
| 1 | Capabilities are built and changed when someone asks; no shared inventory | [Yes / Partly / No] |
| 2 | Capabilities are listed centrally with owners; changes and upgrades are tracked, but upgrades are still manual and bespoke | [Yes / Partly / No] |
| 3 | Platform work is prioritised centrally across the organisation; capability providers maintain their capabilities, standardise the user experience and supply upgrade tooling | [Yes / Partly / No] |
| 4 | Upgrades are automated and continuous with little user impact, under a documented shared-responsibility model; provisioning and deprecation follow the same standard lifecycle | [Yes / Partly / No] |

| Field | Entry |
|---|---|
| Evidence | *Example:* EV-007 |
| Current level | *Example:* 2 Operational |
| Target level and reason | *Example:* 2 Operational for 12 months: reliability of existing capabilities first; revisit after cluster upgrade automation |
| Confidence | *Example:* Medium |
| Notes and dissent | [Notes] |

### 5.5 Measurement

**Guiding question:** how does the organisation collect and use feedback
and data about the platform?

| Level | Observable indicators (adapt) | Met? |
|---|---|---|
| 1 | Usage and satisfaction data are collected in custom ways, if at all | [Yes / Partly / No] |
| 2 | A consistent set of adoption and satisfaction data is collected on a schedule | [Yes / Partly / No] |
| 3 | Data is analysed to find causes and to guide roadmap and investment decisions | [Yes / Partly / No] |
| 4 | Quantitative and qualitative feedback is built into everyday platform and product decisions | [Yes / Partly / No] |

| Field | Entry |
|---|---|
| Evidence | *Example:* EV-008 |
| Current level | *Example:* 1 Provisional |
| Target level and reason | *Example:* 2 Operational: survey twice a year and monthly adoption data, as committed in the platform charter |
| Confidence | *Example:* High |
| Notes and dissent | [Notes] |

Useful sources for Measurement evidence are the Developer Experience
Survey (`dev/developer-experience-survey`) and the Delivery Performance
Report (`dev/delivery-performance-report`).

## 6. Results profile and gaps

<!-- Guidance: Show the profile against the previous run and the target. Explain each gap in one or two sentences: what is missing and why it matters for the business. Pitfall: listing gaps without the business reason, which makes them easy to defer. -->

| Aspect | Previous run | Current | Target | Gap | Trend |
|---|---|---|---|---|---|
| Investment | *Example:* 1 | 2 | 3 | 1 | Up, 3 partly met |
| Adoption | *Example:* 1 | 2 | 3 | 1 | Up |
| Interfaces | *Example:* 2 | 2 | 3 | 1 | Same, 3 partly met |
| Operations | *Example:* 2 | 2 | 2 | 0 | Same |
| Measurement | *Example:* 1 | 1 | 2 | 1 | Same |
| [Aspect] | [Level] | [Level] | [Level] | [Number] | [Trend] |

*Example* summary: four of five aspects have a gap of one level; the sum
of gaps is 1 + 1 + 1 + 0 + 1 = 4 levels. Use the count only to size the
backlog, never as a score to compare with other organisations.

### 6.1 Gap statements

| Gap ID | Aspect | What is missing | Why it matters | Dependencies |
|---|---|---|---|---|
| GAP-01 *(Example)* | Measurement | Scheduled satisfaction survey and adoption dashboard | Investment cannot be tied to outcomes without it (blocks GAP-02) | Survey tool, analyst time |
| GAP-02 *(Example)* | Investment | Funding reviewed against user outcomes | Budget pressure falls on the platform first when value is invisible | GAP-01 |
| GAP-03 *(Example)* | Adoption | Reasons for non-adoption unknown and unaddressed | Older services keep duplicate pipelines and security findings | GAP-01 |
| GAP-04 *(Example)* | Interfaces | Self-service for environments and messaging | Two largest ticket queues; slowest jobs in the user research | Landing zone account vending |
| [GAP-NN] | [Aspect] | [Missing] | [Business reason] | [Dependencies] |

## 7. Improvement backlog

<!-- Guidance: Turn every gap into one or more backlog items with an owner, a date and a measurable done condition. Keep the list short enough to finish before the next run. Pitfall: a backlog of twenty items that nobody owns. -->

| Item ID | Gap | Action | Done when | Owner | Due | Status |
|---|---|---|---|---|---|---|
| PMA-BL-001 *(Example)* | GAP-01 | Run the developer experience survey twice a year with a stable core question set | Two survey waves completed with results published | [@platform-pm] | [YYYY-MM-DD] | Planned |
| PMA-BL-002 *(Example)* | GAP-01 | Publish a monthly adoption dashboard per capability and per team | Dashboard live for three consecutive months | [@platform-analyst] | [YYYY-MM-DD] | Planned |
| PMA-BL-003 *(Example)* | GAP-02 | Add platform outcomes to the yearly funding review | Funding paper cites OUT and MET values from the charter | [@head-of-platform] | [YYYY-MM-DD] | Planned |
| PMA-BL-004 *(Example)* | GAP-03 | Interview every non-adopting team and publish the top five blockers | Blockers on the roadmap with dates | [@platform-pm] | [YYYY-MM-DD] | In progress |
| PMA-BL-005 *(Example)* | GAP-04 | Deliver self-service preview environments | Ticket volume for environments down 80% | [@platform-runtime] | [YYYY-MM-DD] | Planned |
| [PMA-BL-NNN] | [GAP-NN] | [Action] | [Measurable condition] | [@name] | YYYY-MM-DD | [Status] |

Track the items in the platform backlog and report their status at each
platform product review. Items that change platform scope or funding go
to the platform steering group through the charter.

## 8. Re-assessment cadence and triggers

<!-- Guidance: Fix when the next assessment happens and what would bring it forward. Pitfall: re-assessing so often that teams have no time to change anything. -->

| Type | Cadence | Scope | Output |
|---|---|---|---|
| Full assessment | *Example:* Yearly, in the quarter before budget planning | All aspects, full panel, new sample | New version of this document |
| Light check | *Example:* Half-yearly | Backlog status and aspects with Low confidence | Revision history row and backlog update |
| Triggered assessment | When a trigger below occurs | Affected aspects | Minor version |

Triggers for an early assessment:

- a change in platform funding model or a reorganisation of platform
  teams;
- a merger, acquisition or new business unit joining the platform;
- a major platform incident that exposed operating gaps;
- a target level reached early, so that a new target can be set.

Keep the questions, sampling rule and evidence grades unchanged between
runs unless the revision history explains the change; otherwise trends
in section 6 are not comparable.

## 9. Glossary and references

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

### 9.1 Glossary

| Term | Meaning |
|---|---|
| Aspect | One of the five dimensions the model rates: Investment, Adoption, Interfaces, Operations, Measurement |
| Maturity level | One of four stages from Provisional to Optimizing |
| Evidence grade | Strength of evidence behind a rating, from E0 (none) to E3 (measured) |
| Calibration | Panel discussion that resolves differences between independent ratings |
| Golden path | Supported, opinionated route for a common type of work |
| Self-service | Users obtain a capability without a ticket or manual approval |
| Extrinsic push | Adoption driven by mandates or incentives from outside the user team |
| Intrinsic pull | Adoption driven by the value users see in the platform |

### 9.2 References

| Reference | Version or date checked | Use |
|---|---|---|
| CNCF TAG App Delivery, Platform Engineering Maturity Model, tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model | v1.0 (completed October 2023, announced 2023-11-20), checked 2026-10-24 | Aspects, levels and cell labels |
| CNCF TAG App Delivery, Platforms White Paper, tag-app-delivery.cncf.io/whitepapers/platforms | v1.0 (April 2023) | Definitions of platform and capabilities |
| Internal Developer Platform Charter (`architecture/internal-developer-platform-charter`) | Companion | Outcomes, metrics and roadmap fed by this assessment |
| Platform Golden Path (`architecture/platform-golden-path`) | Companion | Interfaces and adoption evidence |
| Team API (`architecture/team-api`) | Companion | Platform team interaction evidence |
| Developer Experience Survey (`dev/developer-experience-survey`) | Companion | Measurement evidence |
| Delivery Performance Report (`dev/delivery-performance-report`) | Companion | Delivery outcome evidence |
| Engineering Strategy (`dev/engineering-strategy`) | Companion | Where target levels are justified |

## Standard and licence note

Structure aligned with the Platform Engineering Maturity Model (v1.0) of
the CNCF Technical Advisory Group for App Delivery, Platforms Working
Group, https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/,
© The CNCF Authors, licensed under Creative Commons Attribution 4.0
International (CC BY 4.0, https://creativecommons.org/licenses/by/4.0/).
The aspect names, level names and short cell labels in section 4 are
taken from the model with attribution; the guiding questions in section 5
are adapted from the model's own questions; the level summaries,
indicators, rating rules, evidence grades and examples are original to
this collection and are not the model's text. Corvid
Commerce and Nest are fictional. Check the current official version of
the model before use. Template licence: MIT.