# Capability Maturity Standard

Status: Draft 0.1  
Purpose: Define a registry-centric maturity model for reusable capabilities.  
Scope: Capabilities that are present in a capability registry. Capabilities outside the registry are considered invisible for reuse analysis within this standard.

---

## 1. Intent

This standard defines how a capability registry assesses and communicates the maturity of registered capabilities.

The standard is optimized for reuse. It distinguishes between:

1. **Planning reuse** — using a capability to reason about product direction, roadmaps, architecture, MVP scope, enhancement planning, dependency graphs, and portfolio structure.
2. **Implementation reuse** — using a capability as something that can be consumed, called, installed, deployed, operated, integrated, or offered.

The registry should not merely describe what exists. It should describe what can be reused, at which confidence level, and for which kind of work.

---

## 2. Core Principle

A registered capability has two internal maturity dimensions and two external evidence dimensions.

```text
Capability Registry Assessment
├── Internal capability maturity
│   ├── Discovery maturity
│   └── Availability maturity
│
└── External consumer evidence
    ├── Completeness
    └── Reliability
```

The four dimensions answer different questions:

| Dimension | Type | Question |
|---|---|---|
| **Discovery** | Internal | How reusable is the capability for planning, orientation, comparison, roadmap design, and architectural reasoning? |
| **Availability** | Internal | How can implementation or operational consumers access and consume the capability? |
| **Completeness** | External | How well does current SCOPE satisfy declared INTENT and consumer expectations? |
| **Reliability** | External | How consistently does the capability satisfy consumer-relevant quality expectations? |

This separation is important. A capability may be well understood but not implemented. It may be available as a service but poorly researched. It may cover only part of its intent but do that part very reliably. It may be broad in scope but frustrating to consume.

---

## 3. Capability Registry Boundary

This standard assumes that the capability registry is the boundary of relevance.

Capabilities not present in the registry are out of scope for reuse assessment. They may exist in code, documentation, tacit practice, products, or agent behavior, but they are invisible for the purposes of registry-driven planning and implementation reuse.

A capability may be registered at any maturity level. The registry should foster reuse of capabilities of all maturity levels, provided their maturity and evidence state are clearly represented.

---

## 4. Capability Maturity Vector

A capability maturity assessment should be represented as a vector.

```text
Discovery / Availability / Completeness / Reliability
```

Example:

```text
D5 / A4 / C3 / R2
```

Meaning:

- **D5 Grounded**: concrete use cases and scenarios are documented.
- **A4 Service API / SDK**: the capability is available for application-level integration.
- **C3 Functional Core**: the core expected scope is present, but variants and edge cases remain incomplete.
- **R2 Tolerable**: the capability works in selected situations, but consumers must expect friction.

The vector is descriptive, not moral. Higher values do not always mean “better” for every capability. Some capabilities naturally target A0 or A3 rather than A7. Some capabilities are meant to remain informational standards or CLI tools.

---

## 5. Discovery Maturity

Discovery maturity measures how reusable a capability is for planning.

It asks:

```text
How well can this capability be reused for orientation, comparison, roadmap design, architecture, prioritization, and product planning?
```

Discovery maturity does not require implementation.

### 5.1 Discovery Levels

| Level | Name | Core meaning | Reuse value |
|---|---|---|---|
| **D0** | Named | Capability is visible in the registry. | Awareness and placeholder planning. |
| **D1** | Described | Capability has meaning, intent, and context. | Early clustering and orientation. |
| **D2** | Bounded | Scope, inclusions, exclusions, assumptions, and neighboring capabilities are defined. | Backlog, roadmap, and architecture planning. |
| **D3** | Explored | Obvious relevant aspects have been investigated. | Early planning with reduced naive uncertainty. |
| **D4** | Researched | Prior art, alternatives, products, standards, patterns, and tradeoffs have been deeply examined. | Informed option selection and investment decisions. |
| **D5** | Grounded | Concrete use cases, actors, scenarios, variants, and prioritization criteria are documented. | MVP, roadmap, enhancement, and implementation sequencing. |
| **D6** | Exhaustive | Scope and use-case exploration have likely reached saturation. | High-confidence standardization and major investment planning. |
| **D7** | Generalized | Capability has become a reusable planning primitive beyond one repo, product, or domain. | Canonical planning and cross-context reuse. |

Short ladder:

```text
Named → Described → Bounded → Explored → Researched → Grounded → Exhaustive → Generalized
```

### 5.2 D0 — Named

The capability is registered and named.

Minimum evidence:

```yaml
id: capability.example
name: Example Capability
summary: One sentence or rough phrase
```

Reuse guidance:

- Useful as a visible placeholder.
- Not yet suitable for serious planning.
- Interpretations may differ strongly between consumers.

### 5.3 D1 — Described

The capability has a meaningful description, rough intent, and basic context.

Expected evidence:

```yaml
discovery:
  level: D1
  has:
    - summary
    - intent
    - basic actors
    - basic context
```

Reuse guidance:

- Useful for early planning conversations.
- Useful for clustering related work.
- Boundaries may still be fuzzy.

### 5.4 D2 — Bounded

The capability has defined scope.

Expected evidence:

```yaml
includes:
  - behavior that belongs inside the capability
excludes:
  - behavior that is explicitly outside the capability
assumptions:
  - assumptions shaping the capability boundary
related_capabilities:
  - capability.neighboring.example
```

Reuse guidance:

- Suitable for backlog and roadmap structure.
- Suitable for dependency mapping.
- May still lack research and use-case depth.

### 5.5 D3 — Explored

Obvious relevant aspects have been investigated.

This level does not claim systematic breadth or depth. It only claims that directly visible questions, risks, assumptions, and comparable examples have been examined enough to reduce naive uncertainty.

Expected evidence:

```yaml
exploration:
  questions_checked:
    - What is the most obvious implementation direction?
    - Which adjacent capabilities are clearly involved?
    - What are the most visible risks?
    - Which known tools, products, or examples immediately come to mind?
    - What assumptions look dangerous?
  notes:
    - exploration/initial-notes.md
    - exploration/obvious-risks.md
    - exploration/first-tool-scan.md
```

Reuse guidance:

- Suitable for early shaping and planning discussion.
- Not yet strong enough for major architectural investment decisions.
- Helps avoid obvious blind spots.

### 5.6 D4 — Researched

The capability space has been systematically researched.

Expected evidence:

```yaml
research:
  memos:
    - research/prior-art.md
    - research/standards.md
    - research/product-comparison.md
    - research/architecture-options.md
  alternatives:
    - build
    - buy
    - adapt open source
    - integrate managed service
  tradeoffs:
    - option A vs option B
    - local vs remote
    - embedded vs service-based
```

Reuse guidance:

- Suitable for architectural decisions.
- Suitable for MVP and investment choices.
- Reduces rediscovery by documenting prior art and alternatives.

### 5.7 D5 — Grounded

The capability is grounded in concrete use cases, actors, scenarios, variants, and prioritization criteria.

Expected evidence:

```yaml
use_cases:
  - id: ucc.example.primary
    actor: primary consumer
    summary: Main scenario supported by the capability.
    frequency: high
    criticality: medium
    mvp_relevance: high
selection_dimensions:
  user_value: high
  implementation_risk: medium
  reuse_potential: high
  dependency_pressure: medium
```

Reuse guidance:

- Suitable for roadmap design.
- Suitable for MVP selection.
- Suitable for enhancement planning.
- Suitable for implementation sequencing.

### 5.8 D6 — Exhaustive

Scope and use-case exploration have likely reached saturation.

This does not mean perfect knowledge. It means that further research is unlikely to reveal materially new use-case categories. New findings are expected to become refinements, edge cases, or domain-specific variants rather than fundamentally new categories.

Expected evidence:

```yaml
exhaustiveness:
  use_case_inventory:
    status: saturated
    coverage_notes: Known use cases cover the major actor groups, contexts, lifecycle stages, and integration modes.
  explored_dimensions:
    - actor types
    - consumer types
    - lifecycle stages
    - operational contexts
    - tenant/vendor/customer variants
    - failure modes
    - integration modes
    - governance scenarios
  saturation_indicators:
    - repeated research produces already-known categories
    - new findings map to existing use-case families
    - stakeholder reviews do not reveal major missing categories
    - competitor/product analysis no longer adds new use-case classes
  remaining_uncertainty:
    - niche domain-specific variants may still exist
    - future technology shifts may create new cases
```

Reuse guidance:

- Suitable for standardization.
- Suitable for major investment decisions.
- Suitable as input to canonization.

### 5.9 D7 — Generalized

The capability has been abstracted into a reusable planning primitive beyond one repo, product, domain, or implementation.

Expected evidence:

```yaml
generalization:
  applies_to:
    - repo-level planning
    - product-level planning
    - platform-level planning
    - ecosystem-level planning
  variants:
    - variant A
    - variant B
  anti_patterns:
    - common misuse or confused boundary
  canonical_dependencies:
    - capability.dependency.example
```

Reuse guidance:

- Suitable as a canonical planning primitive.
- Suitable for cross-repo and cross-product architecture.
- Suitable for capability canon inclusion.

---

## 6. Availability Maturity

Availability maturity measures how the capability is available to implementation or operational consumers.

It asks:

```text
How directly can this capability be consumed for implementation or operation?
```

Availability is not primarily a measure of internal implementation quality. It describes consumption mode.

### 6.1 Availability Levels

| Level | Name | Consumer reuse mode |
|---|---|---|
| **A0** | Informational Only | Read, plan, and reason. |
| **A1** | Experimental Prototype | Learn, experiment, and inspect feasibility. |
| **A2** | Source Module / Library | Import, vendor, call, or build with code. |
| **A3** | Command-Line Package | Install and automate through CLI or process invocation. |
| **A4** | Service API / SDK | Integrate through API or language SDK. |
| **A5** | Containerized Service | Deploy and operate as a service. |
| **A6** | Managed Platform Capability | Consume as an internally managed platform service. |
| **A7** | External Cloud Service Offering | Consume as a public, commercial, or ecosystem-facing cloud service. |

Short ladder:

```text
Documented → Tried → Coded → Packaged → Integrated → Deployed → Managed → Offered
```

### 6.2 A0 — Informational Only

The capability is registered and may be documented, but there is no consumable implementation.

Consumer can:

- Read documentation.
- Reuse concepts.
- Plan implementation.

Consumer cannot:

- Call it.
- Install it.
- Deploy it.
- Depend on runtime behavior.

### 6.3 A1 — Experimental Prototype

There is a prototype, spike, notebook, script, demo, or proof of concept.

Consumer can:

- Inspect approach.
- Run with effort.
- Copy ideas.
- Use for feasibility checks.

Consumer should not:

- Assume stable behavior.
- Depend on it as an implementation dependency.

### 6.4 A2 — Source Module / Library

The capability exists as production-oriented source code or a library module inside a repo.

Consumer can:

- Import it.
- Call functions, classes, or modules.
- Write tests against it.
- Reuse it at code level.

Typical artifacts:

- Source module.
- Internal library.
- Package dependency.

### 6.5 A3 — Command-Line Package

The capability is available as an installable CLI command or binary.

Consumer can:

- Install it.
- Call it from shell scripts.
- Use it in CI/CD.
- Compose it with other command-line tools.
- Expose it to agentic workflows.

Typical artifacts:

- CLI package.
- Binary release.
- Package-manager installation.

### 6.6 A4 — Service API / SDK

The capability is available through a stable service API and/or SDK.

Consumer can:

- Integrate it into applications.
- Call it remotely or locally.
- Use language-level SDK abstractions.
- Embed it into service workflows.

Typical artifacts:

- REST API.
- GraphQL API.
- gRPC API.
- Language SDK.
- OpenAPI specification.

### 6.7 A5 — Containerized Service

The capability is available as a deployable service container.

Consumer can:

- Deploy it.
- Run it as infrastructure.
- Integrate it into platform environments.
- Operate it in controlled infrastructure.

Typical artifacts:

- Container image.
- Docker Compose service.
- Helm chart.
- Kubernetes manifests.

### 6.8 A6 — Managed Platform Capability

The capability is available as a managed service inside a platform environment.

Consumer can:

- Request access.
- Configure usage.
- Consume platform APIs.
- Rely on platform operation and support.

Typical artifacts:

- Internal platform service.
- Shared tenant-aware service.
- Platform API.
- Platform documentation.
- Operational ownership model.

### 6.9 A7 — External Cloud Service Offering

The capability is available as an externally consumable cloud, SaaS, API, or marketplace offering.

Consumer can:

- Sign up.
- Subscribe.
- Integrate externally.
- Consume under explicit service terms.

Typical artifacts:

- SaaS product.
- Public API.
- Managed cloud service.
- Marketplace offering.
- External documentation.
- Support and billing model.

### 6.10 Target Availability

Availability levels are not strictly better in all cases. They represent increasing external availability, not universal desirability.

Each capability should declare both current and target availability where useful.

```yaml
availability:
  current: A2
  target: A5
  reason: Needed as a deployable service for multi-tenant platform integration.
```

Examples of natural targets:

| Capability type | Natural target |
|---|---|
| Architectural pattern | A0 |
| Research method | A0 or A1 |
| Markdown validation | A3 |
| Agent helper tool | A3 or A4 |
| Identity lookup | A4 |
| Feature control | A4, A5, or A6 |
| Tenant management | A6 |
| Public document conversion API | A7 |

---

## 7. Completeness

Completeness is an external consumer evidence dimension.

It measures:

```text
How well does current SCOPE satisfy declared INTENT and consumer expectations?
```

Completeness is not about availability or reliability. It is about whether consumers get the breadth and depth of behavior they reasonably expect from the capability’s stated intent.

### 7.1 Completeness Levels

| Level | Name | Meaning |
|---|---|---|
| **C0** | Unknown | No meaningful evidence about scope versus intent. |
| **C1** | Fragmentary | Only isolated parts of the expected capability are present. |
| **C2** | Partial | Some important expectations are satisfied, but major gaps remain. |
| **C3** | Functional Core | The central expected use case works, but variants and edge cases are incomplete. |
| **C4** | Broadly Covered | Most common consumer expectations are satisfied; gaps are known and bounded. |
| **C5** | Expectation Complete | Declared intent is substantially fulfilled for known consumer expectations. |
| **C6** | Saturated | Further consumer discovery rarely reveals missing scope; new requests are mostly extensions, optimizations, or domain-specific variants. |

### 7.2 C0 — Unknown

There is not enough evidence to assess completeness.

Evidence state:

```yaml
completeness:
  level: C0
  evidence:
    - no consumer feedback
    - no explicit intent/scope comparison
    - no expectation tracking
```

### 7.3 C1 — Fragmentary

The capability satisfies a few isolated expectations, but does not yet cover the recognizable core of its declared intent.

Reuse implication:

- Useful fragments exist.
- Consumers will quickly hit missing scope.

### 7.4 C2 — Partial

Some important expectations are satisfied, but major expected areas are missing.

Reuse implication:

- Useful in selected situations.
- Not safe to present as generally complete.

### 7.5 C3 — Functional Core

The main expected use case works end-to-end.

Variants, advanced cases, edge cases, administrative convenience, and uncommon consumer scenarios may still be incomplete.

Reuse implication:

- Often the minimum level for serious early adoption.
- Consumers can use the core, but must expect missing surrounding scope.

### 7.6 C4 — Broadly Covered

Most common consumer expectations are satisfied.

Remaining gaps are known, documented, and do not break the central promise for ordinary use.

Reuse implication:

- Most consumers can use this without feeling misled by the declared intent.

### 7.7 C5 — Expectation Complete

The capability substantially fulfills its declared intent for known consumer expectations.

Broken expectations are rare, minor, or clearly outside the declared scope.

Reuse implication:

- Promise and delivered scope are well aligned.

### 7.8 C6 — Saturated

The capability has reached expectation saturation.

Further consumer feedback rarely reveals missing scope. New requests mostly represent:

- Domain-specific variants.
- Performance improvements.
- UX refinements.
- Integration adapters.
- Commercial packaging.
- Future strategic extensions.

Reuse implication:

- The capability is complete not only against current expectations, but also stable enough that its scope model is unlikely to be surprised.

### 7.9 Completeness Evidence

Completeness should be assessed from evidence such as:

```yaml
completeness_evidence:
  declared_intent:
    - what the capability claims to enable
  current_scope:
    - what the capability actually covers
  satisfied_expectations:
    - expectations confirmed as met by consumers
  broken_expectations:
    - expectations consumers had that were not met
  out_of_scope_expectations:
    - expectations rejected as not belonging to this capability
  requested_extensions:
    - useful but non-core additions
  repeated_surprises:
    - expectations that keep appearing unexpectedly
```

---

## 8. Reliability

Reliability is an external consumer evidence dimension.

It measures:

```text
How consistently does the capability satisfy consumer-relevant quality expectations in real or realistic use?
```

Reliability is independent of completeness. A capability may be incomplete but reliable within its current scope.

### 8.1 Reliability Levels

| Level | Name | Meaning |
|---|---|---|
| **R0** | Unknown | No meaningful evidence about consumer-relevant quality. |
| **R1** | Fragile | Frequently breaks, surprises, or disappoints consumers. |
| **R2** | Tolerable | Works in some situations, but consumers must expect friction. |
| **R3** | Usable | Works reliably for normal use, with known limitations. |
| **R4** | Dependable | Consumers can rely on it for important workflows. |
| **R5** | Trusted | Strong consumer confidence; failures are rare and well-handled. |
| **R6** | Proven | Reliability is demonstrated across broad, repeated, and demanding use. |

### 8.2 R0 — Unknown

There is not enough evidence to assess reliability.

Evidence state:

```yaml
reliability:
  level: R0
  evidence:
    - no bug reports
    - no consumer feedback
    - no operational history
    - no realistic test usage
```

### 8.3 R1 — Fragile

The capability frequently fails, behaves unpredictably, or produces consumer disappointment.

Failures may include:

- Crashes.
- Confusing errors.
- Broken examples.
- Inconsistent behavior.
- Repeated support issues.
- Poor documentation.

Reuse implication:

- Suitable only for tolerant early adopters or controlled experiments.

### 8.4 R2 — Tolerable

The capability works in selected situations, but consumers need caution.

There may be known defects, missing diagnostics, unstable edge cases, or poor performance under some expected conditions.

Reuse implication:

- Consumers can use it, but should expect friction and workarounds.

### 8.5 R3 — Usable

The capability works reliably for normal use within its declared scope.

Known limitations are documented. Failures are understandable enough that consumers can usually recover.

Reuse implication:

- Acceptable for normal internal usage.
- Not yet a deeply trusted dependency for critical workflows.

### 8.6 R4 — Dependable

The capability is reliable enough for important workflows.

Consumer-relevant quality dimensions are monitored or regularly reviewed. Bugs occur, but they are not systemic, and fixes are handled predictably.

Reuse implication:

- Consumers can build serious workflows on top of it.

### 8.7 R5 — Trusted

The capability has earned strong consumer confidence.

Failures are rare, visible, explainable, and handled through mature support, documentation, observability, and change management.

Reuse implication:

- Consumers trust this as a stable building block.

### 8.8 R6 — Proven

The capability is proven across broad, repeated, and demanding use.

Evidence may include production history, diverse consumers, incident records, bug trends, adoption retention, compatibility history, and sustained consumer satisfaction.

Reuse implication:

- Suitable as a proven platform or canonical dependency.

### 8.9 Reliability Evidence

Reliability should be assessed from consumer-relevant evidence such as:

```yaml
reliability_evidence:
  bug_reports:
    - volume
    - severity
    - recurrence
    - time_to_resolution
  support_feedback:
    - support tickets
    - documentation complaints
    - repeated confusion
  operational_evidence:
    - incidents
    - error rates
    - latency
    - uptime
    - retry/failure patterns
  consumer_feedback:
    - ratings
    - star ratings
    - reviews
    - adoption retention
    - churn
  compatibility_evidence:
    - breaking changes
    - migration pain
    - version adoption
  integration_evidence:
    - failed integrations
    - successful integrations
    - consumer workarounds
```

---

## 9. Relationship Between Dimensions

The four dimensions are independent.

Examples:

| Vector | Interpretation |
|---|---|
| **D6 / A0 / C0 / R0** | Scope is deeply understood, but there is no implementation and no consumer evidence. |
| **D2 / A3 / C3 / R3** | Bounded capability, available as CLI, with functional core and normal usability. |
| **D1 / A5 / C2 / R2** | Deployable service exists, but conceptual framing is weak and consumer experience is limited. |
| **D5 / A4 / C4 / R4** | Use-case grounded capability, available through API/SDK, broadly covered and dependable. |
| **D7 / A6 / C5 / R5** | Generalized planning asset, managed internally, expectation-complete and trusted. |
| **D7 / A7 / C6 / R6** | Generalized capability, externally offered, saturated in scope and proven in demanding use. |

Important distinctions:

| Pair | Distinction |
|---|---|
| **Discovery vs Availability** | Understanding a capability is different from consuming it. |
| **Discovery D6 vs Completeness C6** | D6 means the use-case space is probably saturated; C6 means the delivered/current scope satisfies consumer expectations so fully that new feedback rarely reveals missing scope. |
| **Completeness vs Reliability** | Completeness asks whether enough scope is covered; reliability asks whether the covered scope behaves well. |
| **Availability vs Reliability** | A capability can be widely available but unreliable, or minimally available but highly reliable within its context. |

---

## 10. Registry Entry Shape

A capability registry entry should include maturity and evidence fields in a structure similar to the following.

```yaml
id: capability.feature-control.evaluate
name: Feature Availability Evaluation
summary: Evaluate whether a feature is active, hidden, disabled, or unavailable for a subject in context.

maturity:
  discovery:
    current: D5
    target: D7
  availability:
    current: A4
    target: A6

external_evidence:
  completeness:
    level: C3
    name: Functional Core
    score: 0.58
    confidence: medium
    basis: scope_vs_intent_and_consumer_expectations
    satisfied_expectations:
      - tenant-level feature evaluation
      - user-level feature evaluation
      - machine-readable decision result
    broken_expectations:
      - no agent-specific rule simulation
      - no bulk import/export of rules
    out_of_scope_expectations:
      - billing entitlement ownership
      - authorization policy enforcement

  reliability:
    level: R3
    name: Usable
    score: 0.64
    confidence: medium
    basis: consumer_quality_signals
    evidence:
      bug_reports:
        severity_trend: stable
        recurring_bugs: moderate
        time_to_resolution: acceptable
      support_feedback:
        repeated_confusion: moderate
        documentation_complaints: moderate
      operational_evidence:
        incidents: rare
        error_rate: within_expected_bounds
      consumer_feedback:
        average_rating: 3.8
        adoption_retention: moderate
    known_reliability_risks:
      - unclear timeout behavior under heavy load
      - limited diagnostics for complex tenant rule conflicts

discovery:
  intent: Support controlled feature availability across installations, tenants, domains, groups, users, and agents.
  includes:
    - feature decision evaluation
    - context-aware targeting
    - explainable decision result
  excludes:
    - user authorization
    - billing entitlement ownership
    - UI rendering
  research_memos:
    - research/openfeature.md
    - research/unleash.md
    - research/flipt.md
    - research/launchdarkly.md
  use_cases:
    - ucc.feature-control.tenant-toggle
    - ucc.feature-control.agent-disable
    - ucc.feature-control.domain-rollout

availability:
  current_level: A4
  target_level: A6
  current_artifacts:
    - packages/feature-control-sdk
    - services/feature-control-api
  target_artifacts:
    - charts/feature-control
    - platform/feature-control-service
  consumption_modes:
    - SDK
    - service API
    - managed platform service

relations:
  depends_on:
    - capability.identity.subject-resolution
    - capability.tenant.context-resolution
    - capability.policy.rule-evaluation
  supports:
    - capability.feature-control.rollout
    - capability.feature-control.visibility
```

---

## 11. Assessment Guidance

### 11.1 Do Not Collapse Dimensions

Assessors must not treat one dimension as a proxy for another.

Examples:

- A service being containerized does not imply it is reliable.
- A capability being researched does not imply it is complete.
- A capability being expectation-complete does not imply it is generalized.
- A capability being generalized does not imply it is available as code.

### 11.2 Use Evidence, Not Optimism

All levels above the lowest levels should reference evidence.

Evidence can include:

- Registry metadata.
- INTENT and SCOPE documents.
- Research memos.
- Use case catalogs.
- Prior art comparisons.
- Architecture decision records.
- Tests and examples.
- API or SDK documentation.
- Package releases.
- Deployment manifests.
- Consumer feedback.
- Support tickets.
- Bug reports.
- Incident records.
- Ratings and reviews.
- Adoption and retention data.

### 11.3 Track Current and Target State

Capabilities should generally track current and target state.

```yaml
maturity:
  discovery:
    current: D3
    target: D5
  availability:
    current: A1
    target: A4
external_evidence:
  completeness:
    current: C1
    target: C3
  reliability:
    current: R0
    target: R3
```

Target state should reflect the natural purpose of the capability, not an automatic desire to reach the maximum level in every dimension.

### 11.4 Explain Confidence

Each assessment should optionally include confidence.

```yaml
confidence: low | medium | high
```

Low confidence is acceptable if the registry makes it visible.

---

## 12. Summary Tables

### 12.1 Discovery

| Level | Name |
|---|---|
| D0 | Named |
| D1 | Described |
| D2 | Bounded |
| D3 | Explored |
| D4 | Researched |
| D5 | Grounded |
| D6 | Exhaustive |
| D7 | Generalized |

### 12.2 Availability

| Level | Name |
|---|---|
| A0 | Informational Only |
| A1 | Experimental Prototype |
| A2 | Source Module / Library |
| A3 | Command-Line Package |
| A4 | Service API / SDK |
| A5 | Containerized Service |
| A6 | Managed Platform Capability |
| A7 | External Cloud Service Offering |

### 12.3 Completeness

| Level | Name |
|---|---|
| C0 | Unknown |
| C1 | Fragmentary |
| C2 | Partial |
| C3 | Functional Core |
| C4 | Broadly Covered |
| C5 | Expectation Complete |
| C6 | Saturated |

### 12.4 Reliability

| Level | Name |
|---|---|
| R0 | Unknown |
| R1 | Fragile |
| R2 | Tolerable |
| R3 | Usable |
| R4 | Dependable |
| R5 | Trusted |
| R6 | Proven |

---

## 13. Canonical Short Form

The canonical short form for communicating capability maturity is:

```text
D<level> / A<level> / C<level> / R<level>
```

Example:

```text
D5 / A4 / C3 / R3
```

A human-readable rendering may add names:

```text
D5 Grounded / A4 Service API / C3 Functional Core / R3 Usable
```

---

## 14. Future Extensions

This standard deliberately excludes internal implementation quality, because internal structure may belong to feature maturity, code maturity, service maturity, or operational maturity.

Possible future companion standards:

- Feature Maturity Standard.
- Service Operations Maturity Standard.
- Capability Registry Schema Standard.
- Use Case Scoring Standard.
- Capability Evidence Standard.
- Capability Graph Standard.