IM-06 · Capability Graph Format — Innorve Method Open Specification

1.Abstract

This specification defines the structure of a Capability Graph — a versioned, machine-readable representation of an organization’s AI capabilities mapped across seven defined phases of the software delivery lifecycle, with maturity scoring per phase and capability-level ownership. Conforming graphs enable consistent organizational comparison, gap identification, and investment prioritization for AI work.

2.Problem statement

2.1The problem

Most organizations have AI distributed across teams without a shared map. Without a structured representation, gaps stay invisible, duplication accumulates, accountability is ambiguous, and investment decisions are anecdotal.

2.2What this spec solves

A structured graph format with seven canonical SDLC phases, capability-level metadata, maturity scoring, and rendering reference. The format is machine-readable, versioned, and tool-agnostic, so the same graph can be authored in an editor, validated in CI, rendered in a governance binder, and compared across business units without translation.

2.3What this spec does NOT solve

This specification does not define a specific assessment methodology — the diagnostic at innorve.academy/capability-graph is one method that produces conforming graphs but is not the only conforming method. It does not define per-capability evaluation criteria; that is the domain of IM-04 (Skill Contract) and IM-05 (Maturity Gate). It does not define governance enforcement mechanisms; the graph is a description, not a control.

3.Conformance language

The capitalized key words in this document carry the normative meanings defined below. They are the only words in this specification that impose requirements on a conforming Capability Graph or a conforming renderer.

Key word	Meaning
MUST	An absolute requirement of the specification.
MUST NOT	An absolute prohibition of the specification.
SHOULD	A recommendation. Valid reasons to depart exist; the full implications must be understood and weighed before doing so.
SHOULD NOT	A recommendation against. Valid reasons to depart exist; the full implications must be understood and weighed before doing so.
MAY	An optional behavior. Implementations that do and do not provide it both remain conforming.
RECOMMENDED	Synonymous with SHOULD.
REQUIRED	Synonymous with MUST.

4.Definitions

The following terms have the meanings given here when used in this specification.

Capability. A discrete, named organizational practice that delivers part of the AI software delivery lifecycle. A capability has an owner, a status, and a defined division of labor between AI and human actors.
Phase. One of the seven canonical stages of the AI software delivery lifecycle defined in Section 5. Phases are ordered and exhaustive.
Capability Graph. A document that organizes an organization’s capabilities across the seven phases, scores the maturity of each phase, and names the accountable owner for each capability.
Conforming graph. A Capability Graph that satisfies every MUST clause in this specification, validates against the schema in Section 10, and contains all seven phases (Section 5) — explicit absence of capabilities within a phase is permitted and meaningful.
Maturity score. An integer in the closed interval [1, 5] describing the consistency and discipline with which a phase is practiced across the organization, per the rubric in Section 7.
Capability status. A categorical value drawn from the vocabulary in Section 8, describing the formalization level of a single capability.
AI role. The function performed by AI within a capability. One of none, assist, propose, or decide.
Human role. The function performed by a human within a capability. Common values include author, review, approve, decide, and monitor.
Accountable owner. The named individual or role-based identity (a routable email address or directory role) responsible for the capability. Anonymous ownership is not permitted (Section 14.2).
Gap. A phase containing zero capabilities, or a capability with status absent. Gaps are first-class signals — explicit representation of a gap is required of a conforming graph.
Conforming renderer. A tool that produces a visual or tabular representation of a conforming graph without altering its semantic content.

5.The seven SDLC phases

The Capability Graph organizes capabilities across seven canonical phases of the AI software delivery lifecycle. Each phase MUST be present in a conforming graph, in the order given. A phase with zero declared capabilities is permitted; the phase key itself MUST NOT be omitted.

5.1Discover

Identifying problems worth solving with AI.

Examples: stakeholder mapping, opportunity backlog, AI use-case shortlisting.

5.2Define

Specifying what AI skills should do — and not do.

Examples: skill contract authoring, acceptance criteria, risk classification.

5.3Build

Composing the AI skill — frameworks, models, guardrails.

Examples: skill implementation, model selection, tool integration.

5.4Verify

Knowing the AI skill works — under load, edge cases, adversarial input.

Examples: eval suites, regression tests, red-teaming, golden datasets.

5.5Release

Moving a verified skill into production with proper approvals.

Examples: deployment, approval workflows, canary rollouts.

5.6Operate

Monitoring, auditing, and responding to incidents in production.

Examples: observability, audit trails, incident response, SLO management.

5.7Learn

Patterns from production making it back into methodology and team.

Examples: retrospectives, pattern extraction, maturity gating, knowledge sharing.

6.Capability node format

A conforming Capability Graph MUST be a YAML or JSON document with the structure defined here. The YAML and JSON forms are isomorphic; both MUST validate against the schema in Section 10. The example below shows the canonical YAML surface form.

# innorve-capability-graph v0.1
schema: innorve.capability-graph.v0.1
organization: Northstar Lending · Lending Engineering
date: 2026-04-25
prepared_by: lead-architect@northstar-lending.example

phases:
  discover:
    maturity: 3   # see Section 7
    capabilities:
      - id: lending.opportunity-shortlist
        name: AI use-case shortlisting for lending
        owner: product@northstar-lending.example
        ai_role: assist     # one of: none, assist, propose, decide
        human_role: decide
        status: documented   # see Section 8
        notes: "Quarterly AI opportunity review with the lending team."
  define:
    maturity: 4
    capabilities:
      - id: lending.skill-contracts
        name: Skill contract authoring
        owner: lending-eng@northstar-lending.example
        ai_role: assist
        human_role: author
        status: optimizing
  build:
    maturity: 2
    capabilities: []   # explicit empty = gap
  # ... and so on for verify, release, operate, learn

An empty capabilities list is a valid and meaningful signal: it declares that the organization has examined this phase and found no formalized capability. That is a gap, not an oversight, and it appears on the graph as such.

7.Maturity scoring (per phase)

Each phase carries a maturity field. The maturity score for each phase MUST be an integer in the range [1, 5] inclusive. The score describes the phase as a whole, not any single capability within it. Non-integer values, values outside the range, and missing values are conformance violations.

Score	Label	Definition
1	Absent	No process exists for this phase.
2	Ad-hoc	Done occasionally, no consistency.
3	Inconsistent	Process exists, applied inconsistently across teams.
4	Documented	Process is documented and consistently followed.
5	Optimizing	Documented, measured, continuously improved.

8.Capability status values

Each individual capability also carries a status field, drawn from the same five-level vocabulary as the per-phase maturity scoring. The values are string constants and MUST be one of:

absent — capability does not exist.
ad_hoc — exists but not formalized.
inconsistent — formalized but inconsistently applied.
documented — formalized and consistently applied.
optimizing — measured and continuously improved.

The capability-level status and the phase-level maturity need not match. A phase scored 3 · Inconsistent may still contain one individual capability at optimizing — that is meaningful information and the format preserves it.

9.Mermaid rendering reference (normative)

A Capability Graph MAY be rendered as a Mermaid diagram for inclusion in a governance binder, executive review, or capability assessment report. Conforming renderers MAY use other rendering targets (SVG, D3, Plotly, tabular HTML), but the Mermaid representation given here is the canonical one, and any other rendering MUST preserve the same nodes, edges, and per-phase maturity labels.

graph LR
  Discover[Discover<br/>L3 · Inconsistent]:::ok
  Define[Define<br/>L4 · Documented]:::good
  Build[Build<br/>L2 · Ad-hoc]:::weak
  Verify[Verify<br/>L1 · Absent]:::missing
  Release[Release<br/>L3 · Inconsistent]:::ok
  Operate[Operate<br/>L2 · Ad-hoc]:::weak
  Learn[Learn<br/>L1 · Absent]:::missing

  Discover --> Define --> Build --> Verify --> Release --> Operate --> Learn -.-> Discover

  classDef good fill:#10B98122,stroke:#10B981,color:#fff
  classDef ok fill:#FF6B3522,stroke:#FF6B35,color:#fff
  classDef weak fill:#F59E0B22,stroke:#F59E0B,color:#fff
  classDef missing fill:#EF444422,stroke:#EF4444,color:#fff

The dashed back-edge from Learn to Discover is the feedback loop — patterns observed in production making it back into the opportunity backlog. A graph without this loop is a one-way pipeline, and that is itself a finding.

10.JSON Schema (normative)

The following JSON Schema is the normative reference for v0.1 validation. A document MUST validate against this schema to be considered a conforming Capability Graph. Implementations MAY extend the schema with additional properties, but MUST NOT remove or relax any constraint defined here.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://innorve.academy/spec/capability-graph/v0.1.json",
  "title": "Innorve Capability Graph",
  "type": "object",
  "required": ["schema", "organization", "date", "phases"],
  "properties": {
    "schema": {
      "type": "string",
      "const": "innorve.capability-graph.v0.1"
    },
    "organization": { "type": "string" },
    "date":         { "type": "string", "format": "date" },
    "prepared_by":  { "type": "string", "format": "email" },
    "phases": {
      "type": "object",
      "required": [
        "discover", "define", "build", "verify",
        "release", "operate", "learn"
      ],
      "additionalProperties": false,
      "patternProperties": {
        "^(discover|define|build|verify|release|operate|learn)$": {
          "type": "object",
          "required": ["maturity", "capabilities"],
          "properties": {
            "maturity": {
              "type": "integer",
              "minimum": 1,
              "maximum": 5
            },
            "capabilities": {
              "type": "array",
              "items": { "$ref": "#/$defs/capability" }
            }
          }
        }
      }
    }
  },
  "$defs": {
    "capability": {
      "type": "object",
      "required": ["id", "name", "owner", "ai_role", "human_role", "status"],
      "properties": {
        "id":         { "type": "string", "pattern": "^[a-z0-9.-]+$" },
        "name":       { "type": "string" },
        "owner":      { "type": "string", "minLength": 1 },
        "ai_role":    { "enum": ["none", "assist", "propose", "decide"] },
        "human_role": { "type": "string" },
        "status":     {
          "enum": ["absent", "ad_hoc", "inconsistent", "documented", "optimizing"]
        },
        "notes":      { "type": "string" }
      }
    }
  }
}

11.Valid example

The following is a complete conforming Capability Graph for an anonymized mid-size regional bank with three lending engineering teams. All seven phases are populated; one phase is an explicit declared gap. The owner identifiers are role-based mailboxes within a single fictitious organization.

# innorve-capability-graph v0.1
schema: innorve.capability-graph.v0.1
organization: Meridian Regional Bank · Lending Platform Group
date: 2026-04-26
prepared_by: platform-architect@meridian-bank.example

phases:
  discover:
    maturity: 4
    capabilities:
      - id: lending.opportunity-intake
        name: Quarterly AI opportunity intake
        owner: head-of-lending@meridian-bank.example
        ai_role: assist
        human_role: decide
        status: documented
        notes: "Three lending teams submit candidate use cases each quarter."

  define:
    maturity: 3
    capabilities:
      - id: lending.skill-contracts
        name: Skill contract authoring per IM-04
        owner: lending-eng-leads@meridian-bank.example
        ai_role: assist
        human_role: author
        status: inconsistent
        notes: "Two of three teams author contracts; the third does not yet."
      - id: lending.risk-classification
        name: Pre-build risk classification
        owner: model-risk@meridian-bank.example
        ai_role: none
        human_role: decide
        status: documented

  build:
    maturity: 3
    capabilities:
      - id: lending.skill-implementation
        name: Skill implementation in shared framework
        owner: platform-eng@meridian-bank.example
        ai_role: assist
        human_role: author
        status: documented
      - id: lending.model-selection
        name: Model selection with documented fallback
        owner: platform-eng@meridian-bank.example
        ai_role: none
        human_role: decide
        status: ad_hoc
        notes: "Fallback model named only for the highest-risk skill."

  verify:
    maturity: 2
    capabilities:
      - id: lending.eval-suites
        name: Eval suites for production skills
        owner: platform-eng@meridian-bank.example
        ai_role: assist
        human_role: author
        status: ad_hoc
        notes: "Eval suites exist for two skills out of nine."

  release:
    maturity: 4
    capabilities:
      - id: lending.approval-workflow
        name: Risk-class-driven approval workflow
        owner: model-risk@meridian-bank.example
        ai_role: none
        human_role: approve
        status: documented
      - id: lending.canary-rollout
        name: Canary rollout for medium and higher risk
        owner: platform-eng@meridian-bank.example
        ai_role: none
        human_role: monitor
        status: documented

  operate:
    maturity: 3
    capabilities:
      - id: lending.observability
        name: Per-skill observability dashboards
        owner: platform-eng@meridian-bank.example
        ai_role: none
        human_role: monitor
        status: inconsistent
      - id: lending.audit-trail
        name: Tamper-evident audit trail per invocation
        owner: model-risk@meridian-bank.example
        ai_role: none
        human_role: review
        status: documented

  learn:
    maturity: 1
    capabilities: []   # gap: no formal pattern extraction or retro practice yet

Every required field is present. Each capability has a named role-based owner. The learn phase has zero capabilities — declared explicitly as a gap, not omitted. This is a graph an investment committee can read and act on.

12.Invalid examples

The following three documents are not conforming Capability Graphs. Each illustrates a distinct class of conformance violation, with the violation named and the corrected form shown.

12.1Missing required phase

The graph below omits the learn phase entirely. A conforming graph MUST include all seven phases (Section 5); explicit absence of capabilities within a phase is permitted, but omission of the phase key itself is not.

# INVALID — 'learn' phase is missing
schema: innorve.capability-graph.v0.1
organization: Acme · Platform
date: 2026-04-26
phases:
  discover: { maturity: 3, capabilities: [] }
  define:   { maturity: 3, capabilities: [] }
  build:    { maturity: 3, capabilities: [] }
  verify:   { maturity: 3, capabilities: [] }
  release:  { maturity: 3, capabilities: [] }
  operate:  { maturity: 3, capabilities: [] }
  # learn: missing — conformance violation

Fix. Add the learn phase. If the organization has no learn capability, declare it explicitly as a gap:

  learn:
    maturity: 1
    capabilities: []   # explicit gap

12.2Out-of-range maturity score

The graph below scores the verify phase at maturity: 7. The maturity score for each phase MUST be an integer in the range [1, 5] inclusive (Section 7). Values outside that range are conformance violations regardless of intent.

# INVALID — maturity is out of range
verify:
  maturity: 7         # must be in [1, 5] inclusive
  capabilities: []

Fix. Map the intended meaning to the defined rubric. If the phase is documented and consistently followed, that is 4; if measured and continuously improved, that is 5:

verify:
  maturity: 5
  capabilities: [...]

12.3Capability without an owner

The capability below has no owner field. Every capability MUST declare an accountable owner (Section 14.2). Anonymous capabilities are a conformance violation even when every other field is well formed.

# INVALID — capability has no owner
- id: platform.eval-suites
  name: Eval suites for production skills
  ai_role: assist
  human_role: author
  status: documented
  # owner: missing — conformance violation

Fix. Name an accountable owner — a routable email address or a directory role identifier:

- id: platform.eval-suites
  name: Eval suites for production skills
  owner: platform-eng@acme.example
  ai_role: assist
  human_role: author
  status: documented

13.Versioning

13.1Spec versioning

This specification uses semantic versioning. Versions in the v0.x.y series are pre-stable. Version v1.0.0 will be the first stable release. Pre-stable versions MAY introduce breaking changes between minor revisions; stable versions MUST NOT. A breaking change to the schema MUST increment the major version. Backward-compatible additions MUST increment the minor version. Editorial changes that do not affect validation increment the patch version.

13.2Schema field declaration

Conforming graphs MUST declare the spec version they conform to via the top-level schema field (e.g., innorve.capability-graph.v0.1). Tooling that consumes a graph without a schema field MAY treat it as v0.1 for backward compatibility, but SHOULD warn.

13.3Deprecation notice

When a future version supersedes a field or constraint, the prior form MUST remain valid for a deprecation window of no fewer than twelve calendar months from the publication date of the superseding version. During the window, conforming tools SHOULD emit a deprecation warning but MUST NOT reject the deprecated form.

14.Security and governance considerations

14.1Public exposure

Capability Graphs may reveal organizational gaps, named owners of unstaffed functions, and uneven maturity across teams. They SHOULD be treated as confidential by default and shared publicly only with the explicit consent of every named owner. Aggregated or anonymized cross-org reporting is a separate concern from publishing a specific organization’s graph.

14.2Owner accountability

Every capability MUST have a named accountable owner — a routable email address or a role-based directory identity that resolves to a specific person at any given time. Anonymous capabilities, placeholder owners (e.g., tbd@, unknown@), or distribution lists with no named accountable individual are conformance violations.

14.3Score integrity

Maturity scores SHOULD be evidence-backed. Scores claimed without supporting documentation — written process artifacts, eval reports, audit logs, or entries in a publicly verifiable Innorve Filter — are not Mode-aligned even if they pass schema validation. A graph that validates but inflates is a marketing artifact, not a governance artifact.

14.4Comparison ethics

Cross-organizational comparison of Capability Graphs is RECOMMENDED for benchmarking, peer review, and industry patterning. It MUST NOT be used to identify or shame named individuals or teams. When publishing comparative findings, names of individuals and small-team identifiers SHOULD be removed; only organizational-unit-level resolution is appropriate for public benchmarking.

14.5Innorve Native Mode alignment

This specification operationalizes two tenets of Innorve Native Mode directly: tenet 1, Architect before automating, and tenet 3, Govern before scaling. The graph makes the work visible enough to be architected properly — every phase named, every capability owned, every gap declared — and governable enough to be scaled safely, because no AI capability can be defended in production that is not first locatable on the graph and traceable to a named owner. A team that cannot draw its Capability Graph cannot, by Mode-aligned standards, claim to be architecting before automating or governing before scaling.

15.Reference implementations

The /innorve-capability-graph skill in the Innorve Method open repository (Innorve-Inc/innorve-method) implements this specification interactively. It interviews a team across the seven phases and emits a conforming graph.
The /capability-graph diagnostic hosted at https://innorve.academy/capability-graph is a reference implementation that produces conforming graphs, downloadable as YAML.

16.Implementations

This space is intentionally empty. If you implement this specification in a tool, runtime, registry, editor, dashboard, or CI integration, open a Spec Implementation issue at github.com/Innorve-Inc/innorve-method/issues/new and we will list you here. Listings are unranked, unfiltered, and not endorsements; the list exists so downstream users can find each other.

17.Citation

To cite this specification:

Suggested citation

Innorve Capability Graph Format, v0.1 (2026). Innorve Method, IM-06. Innorve Academy. https://innorve.academy/spec/capability-graph