Home · Getting Started · Model · Assessment Hub · Roadmap · References
License: CC BY-SA 4.0
https://creativecommons.org/licenses/by-sa/4.0/
This document provides worked examples showing how levels, pillars, and stage gates interact in practice.
👉 Back to Assessment Framework
👉 Back to Unified Scoring System
👉 Back to Stage Gates
👉 Back to Level Checklists
A maturity assessment can be misused if readers assume that:
These examples show how to interpret the framework correctly.
Each example includes:
Scores use the 0-4 scale defined in the unified scoring system.
A 700-person B2B SaaS company uses coding agents aggressively across product teams.
Agents routinely:
Most new work is still initiated through tickets, and product requirements are often incomplete.
Level 3 — Managed Agents
Reason:
| Pillar | Score |
|---|---|
| Pillar 1 - Intent & Specification Fidelity | 2.0 |
| Pillar 2 - Evaluation & Scenario Architecture | 1.5 |
| Pillar 3 - Agent Operating Model & Autonomy Control | 3.0 |
| Pillar 4 - Delivery System Guardrails & Auditability | 2.0 |
| Pillar 5 - Codebase Readiness & Brownfield Extractability | 2.5 |
| Pillar 6 - Infrastructure & Tooling Readiness | 3.0 |
| Pillar 7 - Organizational Design & Governance | 2.0 |
| Gate | Result |
|---|---|
| Gate 1 - Reliable Evaluation Capability | Fail |
| Gate 2 - Enforceable Guardrails and Controls | Partial |
| Gate 3 - Accountability and Governance | Partial |
| Gate 4 - Recoverability and Resilience | Pass |
| Gate 5 - Domain Suitability for Autonomy | Pass |
Effective maturity: Level 3 — Managed Agents
At first glance, this company may appear to be approaching Level 4 because agents are heavily used and throughput is high.
However, that conclusion would be incorrect.
The organization fails the evaluation gate because:
So the company is not ready for Spec-Driven Development, even though its agent operating model is relatively mature.
This is a classic case of:
high autonomy ambition + weak evaluation discipline = exposure, not maturity
A 12,000-person financial services organization has modernized some digital channels, but its core systems remain legacy-heavy and tightly governed.
AI is widely used for:
A few innovation teams are experimenting with spec-driven workflows, but most core delivery remains ticket-driven and highly review-intensive.
Level 2 — Augmented Coding
Reason:
| Pillar | Score |
|---|---|
| Pillar 1 - Intent & Specification Fidelity | 2.5 |
| Pillar 2 - Evaluation & Scenario Architecture | 2.5 |
| Pillar 3 - Agent Operating Model & Autonomy Control | 1.5 |
| Pillar 4 - Delivery System Guardrails & Auditability | 3.5 |
| Pillar 5 - Codebase Readiness & Brownfield Extractability | 1.5 |
| Pillar 6 - Infrastructure & Tooling Readiness | 2.5 |
| Pillar 7 - Organizational Design & Governance | 3.0 |
| Gate | Result |
|---|---|
| Gate 1 - Reliable Evaluation Capability | Partial |
| Gate 2 - Enforceable Guardrails and Controls | Pass |
| Gate 3 - Accountability and Governance | Pass |
| Gate 4 - Recoverability and Resilience | Pass |
| Gate 5 - Domain Suitability for Autonomy | Fail for core systems / Pass for selected peripheral domains |
Organization-wide effective maturity: Level 2 — Augmented Coding
Selected low-risk domains: Level 3 potential
This organization is often tempted to describe itself as “Level 3” because some teams are experimenting with agents and pilot programs are visible.
But the framework says the dominant operating mode matters more than isolated pockets.
The real blockers are:
This is a classic example of mixed maturity:
So the correct interpretation is not “we are behind.”
It is:
we are unevenly transformed, and the legacy core is the pacing factor
A 180-person platform engineering organization builds internal tooling, workflow systems, reporting pipelines, and developer enablement services.
Its delivery model is highly structured:
Humans still govern policy and handle edge-case exceptions, but routine implementation is mostly automated.
Level 5 — Autonomous Delivery (bounded domains only)
Reason:
| Pillar | Score |
|---|---|
| Pillar 1 - Intent & Specification Fidelity | 3.5 |
| Pillar 2 - Evaluation & Scenario Architecture | 3.8 |
| Pillar 3 - Agent Operating Model & Autonomy Control | 3.7 |
| Pillar 4 - Delivery System Guardrails & Auditability | 3.8 |
| Pillar 5 - Codebase Readiness & Brownfield Extractability | 3.2 |
| Pillar 6 - Infrastructure & Tooling Readiness | 3.7 |
| Pillar 7 - Organizational Design & Governance | 3.4 |
| Gate | Result |
|---|---|
| Gate 1 - Reliable Evaluation Capability | Pass |
| Gate 2 - Enforceable Guardrails and Controls | Pass |
| Gate 3 - Accountability and Governance | Pass |
| Gate 4 - Recoverability and Resilience | Pass |
| Gate 5 - Domain Suitability for Autonomy | Pass |
Effective maturity: Level 5 — Autonomous Delivery in bounded internal domains
Not automatically Level 5 for the entire enterprise
This is the kind of organization that can legitimately claim Level 5 for specific domains.
The key reason is not just strong agent usage. It is the combination of:
The framework intentionally prevents a misleading over-claim here:
this organization is Level 5 only where domain boundaries are explicit and risk is manageable.
That is exactly how the framework should work.
A 2,500-person telecom software organization has invested heavily in architecture definitions, specification templates, and AI-assisted implementation for network management and service orchestration systems.
On paper, the organization appears highly advanced:
However, in practice:
Level 4 — Spec-Driven Development
Reason:
| Pillar | Score |
|---|---|
| Pillar 1 - Intent & Specification Fidelity | 3.4 |
| Pillar 2 - Evaluation & Scenario Architecture | 2.6 |
| Pillar 3 - Agent Operating Model & Autonomy Control | 3.0 |
| Pillar 4 - Delivery System Guardrails & Auditability | 2.8 |
| Pillar 5 - Codebase Readiness & Brownfield Extractability | 2.7 |
| Pillar 6 - Infrastructure & Tooling Readiness | 3.0 |
| Pillar 7 - Organizational Design & Governance | 2.8 |
| Gate | Result |
|---|---|
| Gate 1 - Reliable Evaluation Capability | Partial |
| Gate 2 - Enforceable Guardrails and Controls | Partial |
| Gate 3 - Accountability and Governance | Pass |
| Gate 4 - Recoverability and Resilience | Partial |
| Gate 5 - Domain Suitability for Autonomy | Partial |
Effective maturity: Level 4 — Spec-Driven Development
Not Level 5 — Autonomous Delivery
This example is designed to illustrate a subtle but important lesson:
an organization can be genuinely advanced without being autonomous.
This telecom organization has many signs of Level 4 maturity, especially in intent definition and structured workflow. But it does not pass the full set of gates required for Level 5 because:
This is the exact pattern the framework is meant to detect:
Autonomous Delivery should not be claimed while invisible human safety labor remains indispensable.
Example 1 shows that strong agent workflows without evaluation rigor remain Level 3.
Example 2 shows that large enterprises often contain multiple levels at once.
Example 3 shows that Autonomous Delivery is realistic in bounded internal domains, not necessarily enterprise-wide.
Example 4 shows why “near-autonomous” and “autonomous” are not the same thing.
When using this framework, always ask:
If those answers point in different directions, the organization is not “confusing.”
It is unevenly transformed, and the framework is working as intended.