Files

tegwick 84924f8160 Seeded intent and maturity model

2026-06-15 00:04:09 +02:00

30 KiB

Executable File

Raw Permalink Blame History

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:

Planning reuse — using a capability to reason about product direction, roadmaps, architecture, MVP scope, enhancement planning, dependency graphs, and portfolio structure.
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.

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.

Discovery / Availability / Completeness / Reliability

Example:

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:

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:

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

5.2 D0 — Named

The capability is registered and named.

Minimum evidence:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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.

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:

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:

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:

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:

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:

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:

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.

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.

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.

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:

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

Example:

D5 / A4 / C3 / R3

A human-readable rendering may add names:

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.

30 KiB Executable File Raw Permalink Blame History Unescape Escape

Capability Maturity Standard

1. Intent

2. Core Principle

3. Capability Registry Boundary

4. Capability Maturity Vector

5. Discovery Maturity

5.1 Discovery Levels

5.2 D0 — Named

5.3 D1 — Described

5.4 D2 — Bounded

5.5 D3 — Explored

5.6 D4 — Researched

5.7 D5 — Grounded

5.8 D6 — Exhaustive

5.9 D7 — Generalized

6. Availability Maturity

6.1 Availability Levels

6.2 A0 — Informational Only

6.3 A1 — Experimental Prototype

6.4 A2 — Source Module / Library

6.5 A3 — Command-Line Package

6.6 A4 — Service API / SDK

6.7 A5 — Containerized Service

6.8 A6 — Managed Platform Capability

6.9 A7 — External Cloud Service Offering

6.10 Target Availability

7. Completeness

7.1 Completeness Levels

7.2 C0 — Unknown

7.3 C1 — Fragmentary

7.4 C2 — Partial

7.5 C3 — Functional Core

7.6 C4 — Broadly Covered

7.7 C5 — Expectation Complete

7.8 C6 — Saturated

7.9 Completeness Evidence

8. Reliability

8.1 Reliability Levels

8.2 R0 — Unknown

8.3 R1 — Fragile

8.4 R2 — Tolerable

8.5 R3 — Usable

8.6 R4 — Dependable

8.7 R5 — Trusted

8.8 R6 — Proven

8.9 Reliability Evidence

9. Relationship Between Dimensions

10. Registry Entry Shape

11. Assessment Guidance

11.1 Do Not Collapse Dimensions

11.2 Use Evidence, Not Optimism

11.3 Track Current and Target State

11.4 Explain Confidence

12. Summary Tables

12.1 Discovery

12.2 Availability

12.3 Completeness

12.4 Reliability

13. Canonical Short Form

14. Future Extensions

30 KiB

Executable File

Raw Permalink Blame History