> Markdown copy of [https://aimaturitymodels.com/models/sdlc/whole-model-view/](https://aimaturitymodels.com/models/sdlc/whole-model-view/), generated at build time: a rendering, not a source of truth. Map: [/models/llms.txt](/models/llms.txt). Site map: [/llms.txt](/llms.txt).

# AI-Native Shared Intelligence Layer — D1–D3

**STD-SHARED-INTELLIGENCE · v1.1 · 2026-10-06**

> The canonical definition of D1–D3, inherited by reference by the AI-Native SDLC Maturity Model (this repo) and the AI-Native PDLC Maturity Model. This document is the sole source of truth for these three dimensions — `ai_native_sdlc_maturity_model.md` no longer maintains its own copy of D1–D3; see that file's own D1–D3 section for the reference pointer and the canonical-source rule.

---

## How to read this layer

Each dimension has a definition followed by five maturity levels and realistically adjacent transitions. Each transition ends with a verification statement: the observable that proves the destination level is reached rather than claimed. Maturity does not mean "more AI." AI contributes only where it improves continuity, shared intelligence, evidence quality, cross-functional consumption, or context-specific rendering, without creating separate departmental truths.

The three dimensions remain independently scoreable through Levels A–D. At Level E, they converge into one continuously maintained intelligence layer:

- **D1** contributes the market and opportunity lens.
- **D2** contributes the buyer and user lens.
- **D3** contributes the positioning, competitive, and strategic differentiation lens.

Function-specific outputs may differ, but they are renderings of the same underlying intelligence — not independently commissioned analyses.

---

## D1. Market discovery & definition

*The capability to identify, size, and validate market opportunities — including TAM/SAM/SOM, market trends, and opportunity framing — through a continuous, AI-assisted discovery loop that supplies a shared intelligence foundation for requirements, prioritization, and portfolio investment decisions.*

**Level A**

Discovery happens periodically, such as during planning cycles, and is manually synthesized. AI use is inconsistent and left to individual researcher preference, with no shared method.

**Transition from A to B**

Establish a consistent AI-assisted method for market-opportunity analysis. Define the minimum outputs required — including TAM/SAM/SOM, trend analysis, and opportunity framing — and use the same method for every discovery cycle, not only when someone requests it.

**Verification:** Two consecutive discovery cycles produce the same minimum output set — TAM/SAM/SOM, trend analysis, opportunity framing — by the same AI-assisted method, and the next cycle's date is known before the current one closes.

**Level B**

Discovery runs on a defined cadence, such as quarterly, using a consistent AI-assisted method. It remains primarily a Product-owned exercise: outputs are produced for Product's own use and are not routinely shared with Marketing, Sales, or Strategy.

**Transition from B to C**

Move from cadence-based to continuous discovery. Replace the periodic cycle with a standing feed of market signals and opportunity-model updates. The test is whether a material market shift between planning cycles is detected and surfaced without waiting for the next scheduled review.

**Verification:** A material market shift that occurs between planning cycles appears in the opportunity model before the next scheduled review, without anyone having requested a refresh.

**Level C**

Discovery becomes continuous rather than cadence-based. Market signals, trend analysis, and opportunity models refresh on an ongoing basis. The intelligence remains primarily Product-owned, although other functions can request access to current findings.

**Transition from C to D**

Open the discovery model as a shared asset. Marketing, Sales Enablement, and Strategy should draw directly from the same underlying market and opportunity intelligence rather than request a summary from Product. Define which outputs each function consumes and establish the access path.

**Verification:** A Marketing, Sales Enablement, or Strategy participant retrieves current market and opportunity intelligence from the shared model directly, without a request to Product and without Product producing a summary.

**Level D**

The continuous discovery model is a shared asset. Marketing, Sales Enablement, and Strategy draw directly from the same underlying market and opportunity model rather than commissioning separate research. Each function still produces its own context-specific rendering manually.

**Transition from D to E**

Converge D1, D2, and D3 as one shared intelligence layer and automate function-specific rendering. A material market update should propagate into the relevant Product, Marketing, Sales, and Strategy outputs without a separate commissioning or human reformulation step.

**Verification:** A material market update propagates into the Product, Marketing, Sales, and Strategy renderings from the one layer, each in its audience's form, without a separate commissioning or human reformulation step — and the renderings agree with one another.

**Level E**

D1, D2, and D3 operate as one converged intelligence layer that automatically generates function-specific renderings — including Product roadmap and requirements input, Marketing messaging, Sales battlecards, and Strategy narratives — from the same continuously updated model, each adapted to its audience without separate commissioning.

From D1's vantage, market signals, trend data, and opportunity models are the input lens this layer continuously refreshes.

**Sustainment**

Verify that automatic renderings accurately reflect the shared intelligence and that no consuming function is silently receiving stale or miscontextualized output. Audit D1–D3 convergence periodically to confirm that the layer is coherent, not merely synchronized.

---

## D2. Buyer & user persona development

*The capability to research, model, and maintain live representations of target users and buyers as a shared intelligence asset across Product, Marketing, Sales Enablement, and Engineering.*

**Level A**

User personas exist as static documents created at a point in time, such as a launch or major redesign, and are rarely revisited. Buyer personas are often maintained separately by Marketing or Sales. AI use, where present, is inconsistent and left to individual preference.

**Transition from A to B**

Establish a shared persona structure, clear ownership, and a minimum update cadence for both buyer and user personas. Adopt a consistent AI-assisted research and synthesis method rather than relying on departmental or individual practice.

**Verification:** Buyer and user personas share one structure, name an owner, carry the date of their last refresh and the date of the next, and that refresh has happened at least once on schedule.

**Level B**

Buyer and user personas are refreshed on a defined cadence using a consistent AI-assisted research and synthesis method and selected research, usage, or feedback data. They remain primarily Product-owned or departmentally maintained. Other functions receive periodic document renderings rather than consuming a shared, live persona-intelligence system directly.

**Transition from B to C**

Move from periodic persona maintenance and document distribution to a live shared intelligence system. Connect persona attributes to ongoing research, usage, and feedback signals; establish common underlying data and AI intelligence; and extend direct access across Product, Marketing, Sales, and Engineering.

**Verification:** A new research, usage, or feedback signal changes a persona attribute in the shared system without a document being reissued, and a Marketing, Sales, or Engineering participant sees the change at the source.

**Level C**

Buyer and user personas are maintained in a shared system with common update data and AI intelligence. Usage, research, and feedback signals refresh the representations on an ongoing basis. Access extends across Product, Marketing, Sales, and Engineering, although the intelligence remains primarily maintained by Product and consuming functions still interpret it for their own uses.

**Transition from C to D**

Make personas a directly consumed shared asset rather than a document distributed by Product. Marketing and Sales Enablement should draw from the same persona intelligence for their work, while Engineering receives relevant user context through the requirements management system.

**Verification:** Marketing and Sales Enablement work from the shared persona intelligence with no separately maintained persona of their own, and Engineering reaches relevant user context from inside the requirements management system rather than from a distributed document.

**Level D**

Personas are dynamic, continuously maintained shared assets fed by usage, research, and feedback data. Marketing and Sales Enablement consume them directly rather than commissioning or maintaining separate personas. Engineering has connected access to relevant user context through the requirements management system. Each function still produces its own context-specific rendering manually.

**Transition from D to E**

Converge D1, D2, and D3 as one shared intelligence layer and automate function-specific persona rendering. A meaningful update to buyer or user intelligence should propagate into the relevant Product, Marketing, Sales, Engineering, and Strategy outputs without manual reformulation.

**Verification:** A meaningful change to buyer or user intelligence propagates into the Product, Marketing, Sales, Engineering, and Strategy renderings without manual reformulation, and each rendering remains faithful to the underlying persona.

**Level E**

D1, D2, and D3 operate as one converged intelligence layer that automatically generates function-specific renderings — including Product roadmap and requirements input, Marketing messaging, Sales battlecards, and Strategy narratives — from the same continuously updated model, each adapted to its audience without separate commissioning.

From D2's vantage, live representations of target users and buyers are the input lens this layer continuously refreshes, extending to Engineering through the requirements management system.

**Sustainment**

Verify that automatically generated persona renderings remain faithful to the underlying intelligence and have not drifted because of stale data, automation bias, or function-specific reinterpretation. Audit D1–D3 convergence periodically.

---

## D3. Positioning & competitive intelligence

*The capability to define product differentiation and maintain that positioning against a continuously monitored competitive landscape, actively informing roadmap, prioritization, pricing, go-to-market, and portfolio decisions while preserving a current strategic thesis about what the organization intends to do better than competitors.*

**Level A**

Positioning was defined at a point in time, such as product launch, and competitive awareness is ad hoc or anecdotal. AI use, where present, is inconsistent and left to individual preference, with no shared method.

**Transition from A to B**

Establish a consistent AI-assisted competitive-monitoring method on a defined cadence. Require a minimum output set — including the competitor landscape, messaging differentiation, and positioning thesis — rather than initiating analysis only when a visible competitive threat appears.

**Verification:** Competitive monitoring has run on its cadence at least twice, each run producing the minimum output set — competitor landscape, messaging differentiation, positioning thesis — and the latest run was not triggered by a competitive event.

**Level B**

Competitive monitoring runs on a defined cadence using a consistent AI-assisted method. It remains primarily a Product- or Strategy-owned exercise: findings inform internal roadmap and positioning discussions but are not routinely packaged for Marketing, Sales, or other consuming functions.

**Transition from B to C**

Move from cadence-based to continuous competitive monitoring. Replace scheduled scans with a standing feed of competitor, market, pricing, and messaging signals. Maintain the positioning and strategic differentiation thesis as living intelligence rather than a launch artifact.

**Verification:** A competitor's pricing, product, or messaging change appears in the competitive feed before anyone circulates it by hand, and the positioning thesis carries a revision dated after launch.

**Level C**

Competitive monitoring becomes continuous. A live feed of market, pricing, product, and messaging shifts updates on an ongoing basis. Positioning and the strategic differentiation thesis remain primarily owned by Product or Strategy, although other functions can request access to current intelligence.

**Transition from C to D**

Open the competitive model as a shared asset. Marketing and Sales Enablement should draw directly from the same underlying intelligence for messaging and battlecards. Maintain the strategic differentiation thesis — what the organization intends to do better than competitors — as an explicit, versioned, and auditable artifact.

**Verification:** Marketing and Sales Enablement build messaging and battlecards from the shared competitive model rather than from commissioned research, and the strategic differentiation thesis can be read at a named version with its change history.

**Level D**

The continuous competitive intelligence feed is a shared asset. Marketing and Sales Enablement draw directly from the same underlying competitive model rather than commissioning separate research. The organization's positioning and strategic differentiation thesis are explicitly maintained and versioned as living artifacts. Each function still produces its own context-specific rendering manually.

**Transition from D to E**

Converge D1, D2, and D3 as one shared intelligence layer and automate function-specific rendering. Competitive, positioning, and differentiation changes should propagate into Product, Marketing, Sales, Pricing, and Strategy outputs without a separate commissioning or human reformulation step.

**Verification:** A competitive, positioning, or differentiation change propagates into Product, Marketing, Sales, Pricing, and Strategy renderings without a separate commissioning or reformulation step, and the thesis the renderings express is the one at the current version.

**Level E**

D1, D2, and D3 operate as one converged intelligence layer that automatically generates function-specific renderings — including Product roadmap and requirements input, Marketing messaging, Sales battlecards, and Strategy narratives — from the same continuously updated model, each adapted to its audience without separate commissioning.

From D3's vantage, positioning, the live competitive landscape, and the organization's strategic differentiation thesis are the input lens this layer continuously refreshes.

**Sustainment**

Verify that automatic competitive and positioning renderings accurately reflect the underlying intelligence and that the strategic differentiation thesis has not silently drifted through automation or local reinterpretation. Audit D1–D3 convergence periodically.

---

## Shared Level E convergence rule

Level E is not three synchronized repositories or three departmental systems exchanging updates. It is one governed intelligence layer with three distinct analytical lenses.

A source change should update the shared model once and produce the appropriate downstream renderings automatically. The system may adapt vocabulary, emphasis, and format for each audience, but it must preserve the same underlying market, persona, competitive, and strategic meaning.

The convergence test is:

> **Can one meaningful change in the underlying intelligence propagate into every affected downstream use without separate research, manual reconciliation, or silent semantic divergence?**

---

## Lifecycle interfaces

The following interfaces describe how each lifecycle consumes the shared layer. They do not alter the inherited D1–D3 maturity definitions.

**AI-Native SDLC** consumes the intelligence layer primarily through:

- **D4 Requirements management:** market, persona, positioning, and competitive intelligence become specification context and traceable requirements input.
- **D5 Prototyping:** prototypes validate interpretations of market opportunity, persona needs, and positioning claims.
- **D12 Instrumentation & observability:** production and organizational evidence returns to refresh the shared intelligence layer.
- **D13 Feedback loop velocity:** measures how quickly a market, user, competitive, or operational signal becomes a shipped response.

**AI-Native PDLC** consumes the intelligence layer primarily through:

- **D4 Requirements management:** intelligence becomes precise product definition and traceable specification.
- **D5 Prioritization & tradeoffs:** opportunities, personas, positioning, and differentiation become explicit value-model inputs.
- **D8 Portfolio & investment management:** shared intelligence informs investment thresholds, allocation, sequencing, and portfolio balance.
- **D9 GTM cadence & market activation:** Marketing and Sales consume function-specific renderings from the same intelligence layer.
- **D11 Analytics & outcome measurement:** realized outcomes test the market, persona, positioning, and differentiation assumptions that informed the decision.
- **D12 Feedback loop velocity:** measures how quickly evidence completes the loop back into product and portfolio decisions.

---

## Canonical-source rule — in force

As ratified and issued (2026-07-23):

1. This artifact is the sole source of truth for D1–D3.
2. The SDLC and PDLC inherit this artifact by reference.
3. Lifecycle-specific interface notes remain outside the inherited maturity definitions.
4. Human-readable and portable distributions may embed rendered copies, but those copies are derived and are not independently editable.
5. Excel workbooks, assessments, and public-site content are regenerated from this source.
6. Changes to D1–D3 are made here first and propagated atomically.
7. Prior locally maintained D1–D3 text remains available as superseded history, not current authority — see `d1-d3-superseded-v1.1.0.md`.

## Reconciliation record

This document is the ratified output of the D1–D3 reconciliation (2026-07-23) between the predecessor D1–D3 text (`d1-d3-superseded-v1.1.0.md`, locked in this repo's own `v1.1.0` release) and the Shared Intelligence Layer candidate first drafted 2026-07-22. Fourteen of fifteen maturity cells were adopted unchanged or adopted with clarification only — no maturity-state shift. **One real maturity-state revision:** D2-B moves from "AI assistance is ad hoc" (predecessor) to "a consistent AI-assisted research and synthesis method" (candidate, adopted here), reasoned from coherence with D1-B and D3-B, which already use identical cadence/method language at that letter. Full reconciliation methodology, the five-axis test, and the complete fifteen-cell disposition table are recorded in the governing corpus at `briefs/2026-07-23-d1-d3-reconciliation/01b-d1-d3-reconciliation-record.md` (`OKF TOGAF` repo).

**Provenance, stated precisely:** the reconciliation methodology and framing came from a conversation between David Facer and Craig (an ontologist). The fifteen-cell analysis and disposition record itself is David Facer's own direct work, not delegated.

## Changelog

- **v1.1 — 2026-10-06.** Twelve verification statements added, one after each D1–D3 transition, in the form the D4+ dimensions already use. Ratified by David Facer ("I ratify #143's twelve clauses. Ship D11. David Facer 10/6/2026"), drafted by DTOG (OKF TOGAF `briefs/dtog/`, 2026-10-02, section 3). No level, transition or sustainment text changed. Several transitions already carried a test sentence in their prose; the statement makes it explicit without removing it.
- **v1.0.0 — 2026-07-23.** Initial canonical registration. Ratified by David Facer ("I ratify the D1–D3 reconciliation — David, 7/23/26"). Ends this repo's own D1–D3 maintenance; see `ai_native_sdlc_maturity_model.md`'s D1–D3 section for the inheritance pointer, and `d1-d3-superseded-v1.1.0.md` for the preserved predecessor text.


---

# AI-Native SDLC Maturity Model — Matrix

**Version 1.3.1 — 2026-10-08** (one citation corrected: D1–D3 are inherited from `shared_intelligence_layer.md` at v1.1, which this matrix cited as v1.0.0. No level, transition or verification changed; scores against v1.3.0 are unaffected) Previously: **Version 1.3.0 — 2026-10-06** (D11 rewritten — every agent action attributable, least-privileged against a declared minimum, and observed — and its deferred marker removed; D1–D3 gain verification statements in `shared_intelligence_layer.md` v1.1. **D11 scores against v1.2.0 are not comparable with scores against v1.3.0** — see `CHANGELOG.md`.) Previously: **Version 1.2.0 — 2026-07-23** (D1–D3 extracted to `shared_intelligence_layer.md`, the new canonical, shared-with-PDLC source for those three dimensions; this matrix inherits them by reference. D4–D13 and the Pre-AI/Exempt mechanics are unchanged from v1.1.0 — see `CHANGELOG.md`). **No version bump 2026-07-27:** D4–D13's transition and verification notes (previously a separate companion, `sdlc_transition_states_d4_d13.md`) and the family-wide maturity-level names (Nascent/Modeled/Continuous/Integral/Telemetric) are now folded directly into this document — consolidation and presentation only, no change to any dimension's maturity content. See `CHANGELOG.md`.

This is the full A–E maturity matrix for all 13 dimensions (D1–D3 by reference, D4–D13 in full below), readable in-browser and directly usable as input to AI tools. **This markdown document is the source of truth for D4–D13** -- `ai_native_sdlc_maturity_model.xlsx` is a derived distribution rendering of it; if the two ever diverge, this document is authoritative and the spreadsheet should be regenerated. D1–D3 are sourced from `shared_intelligence_layer.md`, not this file.

For the design principles, handoff structure, research finding, and open items behind this matrix, see `README.md`. For the diagram of how these 13 dimensions hand off to each other, see `sdlc_handoff_diagram.png` / `sdlc_handoff_diagram.html`.

---

## How to read this matrix

Each dimension below has a definition followed by a five-level maturity ladder (A through E). Levels describe **realistically adjacent states** -- each step up implies a roughly costable set of changes, not "more AI, more thoroughly." A given level is not inherently good or bad; it is appropriate or inappropriate for an organization's size, regulatory context, and risk tolerance (see Design Principle 3 in the working framework document).

Dimensions are independently scored -- an organization can be advanced in one dimension and nascent in another. See the working framework document for how dimensions hand off to, constrain, and converge with each other.

For D4–D13, each level is followed by the transition required to reach the next level and a verification statement -- a practical test of whether the destination state has actually been reached, not just claimed. Level E is followed by a sustainment note instead of a further transition, since there is no Level F: at the top of the ladder, the work shifts from climbing to keeping the capability from quietly regressing. D1–D3 carry their transitions, verification statements and sustainment in `shared_intelligence_layer.md`.

Every control this model describes is read by the family's guardrail rule, stated once in `guardrail_rule.md`.

### Maturity-level names

The five letters A–E carry a family-wide name, identical across every dimension and every model in this family (SDLC, PDLC, Prioritization, and Enterprise Architecture), used as column headers wherever the matrix is rendered:

| Letter | Name | In one line |
|---|---|---|
| A | **Nascent** | Ad hoc and inconsistent -- nobody has yet defined what "good" looks like here. |
| B | **Modeled** | A real, deliberate method exists, but it's manual and owned by one person or function. |
| C | **Continuous** | The method runs constantly on its own cadence, still narrowly owned but always on. |
| D | **Integral** | The capability is load-bearing and shared beyond its original owner -- removing it would break something real. |
| E | **Telemetric** | A continuous two-way loop: signal flows in, action flows back out, close to real time. |

These names describe a general shape of maturity, not this dimension's own specific content -- read each level's own text below for what that shape means concretely at D4, D5, and so on. Locked 2026-07-24; full generic definitions at `briefs/2026-07-25-model-data-architecture/01a-maturity-column-definitions.md` in the governing corpus.

---

### Pre-AI — The Threshold State

**Pre-AI** designates a dimension in which an organization has not
yet adopted AI-assisted practices of any kind. It is a threshold
position, not a maturity level: it sits outside the A–E scale and
carries no letter.

An organization scores Pre-AI on a dimension when the activities of
that dimension are performed — possibly with great discipline — using
entirely pre-AI methods and tooling.

**Pre-AI is not an assessment of general SDLC maturity.** A shop with
rigorous CMMI-style discipline, comprehensive CI/CD automation, and
mature release engineering — but no AI tooling — scores Pre-AI on the
relevant dimensions exactly as a shop with none of that discipline
does. This is deliberate: the model measures AI-native maturity, and
general SDLC excellence is already well measured by existing
frameworks. What existing discipline determines is not the starting
*level* but the transition *velocity* — see below.

**Using Pre-AI as an on-ramp.** Organizations at the beginning of an
AI transformation can adopt this model directly from the threshold:
Pre-AI names the starting position honestly, and Level A becomes the
first milestone of adoption for any dimension, not a judgment of
failure. Dimensional focus applies from the first step — an
organization moves one or two dimensions from Pre-AI to A deliberately,
rather than attempting broad simultaneous adoption.

**Transition velocity.** Existing engineering discipline is
transferable substrate. An organization with mature automation,
strong requirements traceability, or rigorous release gates will
typically cross levels faster than an organization without them —
the discipline transfers; the tooling changes. Assessments of Pre-AI
dimensions may optionally carry a **readiness note** recording the
non-AI maturity that predicts transition speed. The readiness note
is narrative, not a score.

---

### Exempt — The Governed Stance

**Exempt** designates a dimension that an organization has
deliberately excluded from AI adoption as a matter of governed
policy. It is a stance, not a state: where Pre-AI describes a
position an organization intends to move from, Exempt records a
decision an organization has made and stands behind.

**An Exempt designation is valid only when it cites a governing
constraint.** Acceptable constraint sources:

- **Regulatory** — a law, regulation, or supervisory requirement
  that prohibits or materially restricts AI use in the dimension's
  activities
- **Contractual** — a client, partner, or certification obligation
  with the same effect
- **Corporate policy** — a documented, owned internal policy decision
  (with named authority and review date), where the organization has
  weighed AI adoption and formally declined it for this dimension

An exemption without a citable constraint is not Exempt — it is
Pre-AI. The citation requirement is what distinguishes a governed
architectural decision from an unexamined default. Organizations
practicing formal enterprise architecture will recognize this as
constraint governance: the exemption is an architecture decision,
recorded with its rationale, owner, and review trigger.

**Exempt dimensions and overall maturity.** An Exempt dimension is
excluded from aggregate maturity calculations rather than scored as
a floor value. An organization with eleven dimensions at C and two
legitimately Exempt is a mature AI-native organization with a
governed boundary — not a shop dragged down by two failing scores.
Assessment renderings must, however, always show Exempt dimensions
visibly: an exemption is part of the organization's architecture,
not an omission from it.

**Exemptions are reviewable.** Every Exempt designation carries a
review trigger — at minimum, re-validation when the cited constraint
changes (regulation amended, contract renewed, policy revisited).
A lapsed constraint converts the dimension to Pre-AI at the next
assessment.

---

### Assessment values

**Legal score values per dimension:** `Pre-AI` · `A` · `B` · `C` ·
`D` · `E` · `Exempt(constraint-ref)`

- `Exempt` is invalid without a constraint reference. The reference
  points to the organization's own constraint record (in an EA OKF
  practice: a `constraint_or_principle` corpus ID; elsewhere: a named
  policy/regulation citation).
- Pre-AI dimensions may carry an optional `readiness_note` (narrative).
- Exempt dimensions carry a `review_trigger` (date or event).

---

## D1–D3. Shared Intelligence Layer

D1 (Market discovery & definition), D2 (Buyer & user persona development), and D3 (Positioning & competitive intelligence) are inherited by reference from `shared_intelligence_layer.md` (`STD-SHARED-INTELLIGENCE` v1.1), this repo's own canonical source for these three dimensions, shared with the AI-Native PDLC Maturity Model. This matrix no longer maintains its own copy of D1–D3 — see that document for full definitions, transitions, and the Level E convergence rule.

Ratified 2026-07-23 following a reconciliation between this matrix's own predecessor D1–D3 text (preserved verbatim, not current authority, at `d1-d3-superseded-v1.1.0.md`) and the Shared Intelligence Layer candidate. Fourteen of fifteen maturity cells carried forward unchanged or with clarification only; one real maturity-state revision landed at D2-B (see `shared_intelligence_layer.md`'s own reconciliation record for the full disposition).

---

## D4. Requirements management (specification quality & traceability)

*The capability to author precise, testable, machine-actionable specifications with full traceability from source through delivery, such that specification quality directly gates generation quality.*

**Level A — Nascent**

Specifications are written informally (tickets, docs) with no consistent structure, and traceability from source to delivery is manual or absent.

**Transition A → B — Establish a shared system of record**

Move specifications out of disconnected tickets and documents into one shared system of record. Define a minimum structure for every material requirement: source, intended user or buyer context, expected behavior, acceptance conditions, supporting design material, and delivery state. Preserve the path from originating need through implementation.

**Verification:** A Product, Engineering, QA, or Release participant can locate the current requirement, its supporting evidence, and its delivery status without asking the original author.

**Level B — Modeled**

Specifications are captured in a shared system of record with traceability from source to delivery. Relevant teams have shared access. Drawings, UX designs, wireframes, and functionality matrices are found in or linked to the system of record.

**Transition B → C — Make the requirement context cross-functional**

Extend the shared record across Product, Engineering, QA, and Release Management. Connect relevant buyer and user personas from D2, establish ownership for changes, and preserve visible history when meaning changes. The destination is shared interpretation, not yet generation-grade precision.

**Verification:** All participating functions use the same current requirement and persona context, and a material change becomes visible to each without manual redistribution.

**Level C — Continuous**

The shared system of record (per Level B) extends to cross-functional access -- Product, Engineering, QA, and Release Management all have shared access, and relevant user personas (per D2) are accessible to these teams within the same system.

**Transition C → D — Raise specifications to generation quality**

Introduce the precision required for routine specifications to generate code, prototypes, or tests with minimal additional interpretation. Add explicit schemas, edge cases, constraints, testable outcomes, and unambiguous acceptance conditions. Generated artifacts inherit traceability from the specification automatically. The specification remains the required starting point at this level -- generating or updating a specification from a prototype or test is not yet supported; that reversal is Level E's own step, not this one's.

**Verification:** A well-formed routine specification repeatedly generates at least one downstream artifact, and that artifact remains automatically traceable to its source.

**Level D — Integral**

Specifications are precise and testable enough to directly drive generation -- code, prototypes, and/or tests can be generated from the specification with minimal additional interpretation. Traceability and shared access (per Level C) are maintained automatically as generated artifacts are produced. The reverse direction -- generating or updating a specification from a prototype or test -- is not yet supported; the specification remains the required starting point.

**Transition D → E — Make generation sequence-agnostic**

Support the reverse direction as well as forward generation: a prototype or test may create or update the governing specification. Define conflict resolution when specification, prototype, test, and implementation imply different meanings, and preserve provenance through every update.

**Verification:** Work can begin from a specification, prototype, or test and produce a coherent, traceable artifact set without a manual translation project.

**Level E — Telemetric**

Specifications are precise, testable, and machine-actionable with full traceability, and generation is sequence-agnostic -- code, prototypes, and tests can be generated from the specification, or the specification can be generated or updated from a prototype or test. The system doesn't care which artifact type initiates the work, though the team may choose a preferred sequence.

**Sustainment**

Continuously test artifact equivalence and conflict resolution. Sequence-agnostic generation must not permit the specification, prototype, test, and implementation to drift into parallel meanings.

---

## D5. Prototyping & the prototype-to-code boundary

*The capability to produce functional prototypes for validation, and to govern -- explicitly and consistently -- whether and how those prototypes transition into production code.*

**Level A — Nascent**

Prototyping is ad hoc and the boundary between prototype and production code is undefined or unenforced -- prototypes may become production code by default.

**Transition A → B — Make the boundary explicit**

Label prototypes as non-production by default and define where they may run. Establish a shared expectation that exploratory or generated code does not become production code merely because it appears to work. Name the categories of carry-forward concern that will eventually matter -- architecture, security, verification, maintainability, and data handling -- without yet evaluating any given prototype against them; that formal evaluation is Level C's own gate, not this one's.

**Verification:** A prototype cannot enter the production path accidentally or through ambiguity about its status, though no defined checklist or gate yet exists to evaluate it against.

**Level B — Modeled**

Prototyping is common and AI-assisted, but the prototype-to-code boundary is governed only informally -- teams generally understand that prototypes need rework before production, but there is no defined process, checklist, or gate. Whether and how much rework happens depends on individual judgment and time pressure.

**Transition B → C — Create a formal disposition decision**

Establish an explicit prototype-to-production gate. Define the evidence required to choose among rewrite, partial reuse, carry-forward, and discard-and-rebuild, including architectural fit from D6, verification coverage from D7, and security implications from D11. Record the decision and rationale.

**Verification:** Every prototype contributing code to production has a visible disposition decision against defined criteria.

**Level C — Continuous**

A defined decision point exists between prototype and production -- prototypes are explicitly evaluated against criteria (e.g., architectural fit per D6, test coverage per D7) before any code carries forward, and the decision (rewrite, partial reuse, or discard-and-rebuild) is documented. The evaluation is manual and happens after the prototype exists.

**Transition C → D — Apply production criteria during prototyping**

Use the Level C decision criteria while the prototype is being built rather than only afterward. Identify the prototype class in advance -- disposable learning artifact, partial-reuse candidate, or production-viable experiment -- and apply relevant architectural and verification constraints from the beginning. The carry-forward decision itself should become faster and less all-or-nothing than Level C's binary rewrite-or-discard call, since most of the evidence needed to decide is now available before the decision point rather than only after it.

**Verification:** Teams can state before construction what would make the prototype reusable, and post-prototype review rarely discovers basic production requirements for the first time. The carry-forward decision is measurably quicker to reach than at Level C, and fewer decisions land as pure discard-or-full-rewrite.

**Level D — Integral**

The decision criteria from Level C are applied during prototyping, not only after -- prototypes are built with carry-forward viability in mind from the start (e.g., generated against the same architectural constraints per D6-D), reducing the frequency of discard-and-rebuild outcomes driven by avoidable misalignment. The prototype-to-production decision remains an explicit, governed step, but is faster and less binary than at Level C.

**Transition D → E — Fuse specification, prototype, and test**

Produce specification, prototype, and test as one governed motion with D4-E and D7-E. Permit any of the three to initiate the work while preserving common intent, traceability, architecture, and verification. Make both carry-forward and discard low-cost outcomes.

**Verification:** A prototype can be discarded without discarding the validated understanding around it, or carried forward without reconstructing its specification and tests.

**Level E — Telemetric**

Specification, prototype, and test are produced as a single governed motion (per D4-E / D7-E), sequence-agnostic about which artifact initiates the others. From D5's vantage: because the prototype is produced as part of this fused motion rather than as separate upfront investment, the carry-forward-vs-discard decision (per Levels C/D) is immediate and low-cost in either direction -- a prototype built purely to validate understanding can be discarded without having consumed the specification or test work, and a prototype that is viable carries forward with its specification and test already in hand. Discard-and-rebuild remains a normal, context-appropriate outcome at this level -- what changes is that the decision is no longer expensive.

**Sustainment**

Preserve the explicit disposition decision even when it becomes nearly instantaneous. Low-cost carry-forward must not turn every prototype into production code by default.

---

## D6. Architecture governance

*The capability to define, encode, and enforce architectural standards and design judgment ("taste") across a codebase as code is generated, modified, or extended by agents.*

**Level A — Nascent**

Architectural standards exist only as tribal knowledge or informal conventions, enforced inconsistently through manual review.

**Transition A → B — Externalize architectural judgment**

Document the architectural standards and design judgment currently held in reviewer memory. Capture recurring decisions, constraints, preferred and prohibited patterns, rationale, and reference examples. Assign ownership for maintaining the record.

**Verification:** A capable engineer or agent unfamiliar with the codebase can locate the governing standard and understand the reason behind its most important constraints.

**Level B — Modeled**

Architectural standards are documented (style guides, architecture decision records, design docs) but enforcement remains manual -- reviewers check generated and human-written code against documentation, with consistency dependent on reviewer familiarity with the docs.

**Transition B → C — Encode critical architectural rules**

Select the most common and consequential violations and encode them as deterministic controls: linters, structural tests, dependency rules, schema validation, or CI gates. Retain manual review for judgment that cannot yet be encoded.

**Verification:** The encoded controls prevent or flag a defined set of critical violations consistently across human- and agent-generated changes.

**Level C — Continuous**

Core architectural rules are encoded as automated checks (linters, structural tests, CI gates) covering the most common and critical violations -- but coverage is partial, and violations outside the encoded rules still rely on manual review per Level B.

**Transition C → D — Make the rules usable during generation**

This is a change in *when* enforcement happens, not primarily how much of it exists -- Level C's gates catch violations after code is written; Level D requires the same rules to be readable and applicable by an agent before and during generation, so violations are avoided rather than caught and sent back. Convert encoded checks into constraints agents consume as input to generation itself, not just as a check afterward. Expanding coverage where repeated manual findings reveal missing rules is worth doing alongside this shift, but it doesn't substitute for it -- comprehensive after-the-fact coverage is still Level C if agents never read the rules before generating.

**Verification:** Agents routinely produce compliant changes on the first pass because they consumed the rules before generation -- not because a larger after-the-fact gate caught fewer violations.

**Level D — Integral**

Architectural rules are encoded comprehensively enough that agents read and respect them directly during generation, not just check against them after the fact. Violations are caught and, where possible, accompanied by remediation guidance the agent can act on, reducing round-trips between generation and review.

**Transition D → E — Let agents propose evolution of the standard**

Create a governed mechanism for agents to propose additions or changes to the encoded standard. Each proposal identifies the uncovered or obstructive pattern, supplies evidence and examples, and recommends an enforceable rule or remediation. Human architectural authority accepts, rejects, or revises the proposal.

**Verification:** Repeated novel findings or rule friction produce reviewable, versioned improvements to the standard, with a visible record of why the standard changed.

**Level E — Telemetric**

Agents participate in evolving the encoded standard itself -- when an agent encounters a pattern not covered by existing rules, or notices a rule that has become a recurring obstacle, it proposes an addition or change to the encoded ruleset (linters, structural tests, remediation guidance) for human review. The team's architectural taste and the enforced standard co-evolve, with agents as active contributors to that evolution rather than only subjects of it.

**Sustainment**

Continuously verify that agent-proposed rules improve architectural coherence rather than merely optimizing for easier generation. Architectural taste remains a human-governed capability.

---

## D7. Test-driven development (specification-driven verification)

*The capability to couple test/specification authoring with implementation as one motion, and to scale verification coverage as generation volume scales.*

**Level A — Nascent**

Tests exist and are written close in time to the code they cover, but are authored independently after implementation -- the test verifies what the code happens to do, rather than the code being written to satisfy a pre-specified test.

**Transition A → B — Move tests before implementation**

Establish a test-first workflow for defined classes of work. Require expected behavior and failure conditions before code is written, while allowing the specification and tests to remain separately authored.

**Verification:** For the targeted work classes, implementation begins against a pre-existing test rather than tests being written to describe completed code.

**Level B — Modeled**

Tests are written before implementation (test-first), but as a separate authoring step from the specification -- a developer or agent translates the specification into tests manually, introducing a translation gap between what the specification says and what the test actually checks.

**Transition B → C — Derive tests directly from specifications**

Define a repeatable method that converts D4 specifications into tests. Specify which requirement elements generate which test types, how unsupported or ambiguous cases are surfaced, and who reviews generated tests.

**Verification:** Re-running the method against the same well-formed specification produces materially equivalent tests without routine manual reinterpretation.

**Level C — Continuous**

Test generation is derived directly from the specification (per D4) using a consistent, repeatable method -- the translation gap from Level B is closed for routine cases, though specification authors don't see the generated tests until after the fact.

**Transition C → D — Generate tests during specification authoring**

Generate corresponding tests as the specification is written. Use them to expose missing edge cases, undefined states, contradictory acceptance conditions, and other ambiguities while meaning is still being formed.

**Verification:** Specification authors routinely revise requirements in response to test-generation feedback before implementation begins.

**Level D — Integral**

Test generation occurs concurrently with specification authoring -- as a specification is written, corresponding tests are generated in the same step, surfacing ambiguities in the specification (e.g., undefined edge cases) at authoring time rather than later.

**Transition D → E — Fuse specification, test, and prototype**

Combine specification authoring, test generation, and prototyping into one governed, sequence-agnostic motion with D4-E and D5-E. Ensure that verification coverage scales with generation volume rather than becoming a downstream human bottleneck.

**Verification:** Whether work begins from a specification, prototype, or test, the corresponding verification set is created or updated automatically and remains aligned.

**Level E — Telemetric**

Test generation, specification authoring, and prototyping are a single governed motion (per D4-E / D5-E) -- verification coverage scales automatically as generation volume scales, and the system is sequence-agnostic about which artifact initiates the others.

**Sustainment**

Continuously test whether generated verification still measures intended behavior rather than merely confirming the implementation produced alongside it.

---

## D8. Code verification & review

*The capability to apply human and automated judgment to generated code for correctness, security, maintainability, and alignment with intent, scaled appropriately to risk. Note: review of generated code is not a substitute for execution containment (D11) -- at any D8 level, review happens on code, while execution risk (e.g., an agent running a destructive shell command) is governed by D11's sandboxing and runtime controls. The two dimensions address different surfaces and neither compensates for the other's absence.*

**Level A — Nascent**

Verification relies primarily on human line-by-line review of all generated code, regardless of risk or volume. Review capacity does not scale with generation volume -- as the rate of code generation increases, review either becomes a bottleneck or is skipped under pressure.

**Transition A → B — Put deterministic gates before human review**

Run linters, static analysis, secret detection, basic CI, and other repeatable checks on all generated and human-written code before human review. Retain human review for correctness, design, maintainability, security judgment, and alignment with intent.

**Verification:** Code cannot reach human review or merge while failing the agreed deterministic gates.

**Level B — Modeled**

Deterministic automated gates (linters, SAST, basic CI checks) run on all code before human review, catching style and known-pattern issues. Human review remains the primary mechanism for correctness, design, and intent, and is still applied uniformly regardless of risk.

**Transition B → C — Allocate review by risk**

Define change-risk tiers using factors such as blast radius, data sensitivity, novelty, reversibility, architectural significance, and security consequence. Permit routine low-risk changes to pass with automated gates, while routing higher-risk or novel changes to human review.

**Verification:** Review effort is visibly concentrated according to defined risk rather than applied uniformly or skipped under volume pressure.

**Level C — Continuous**

Review is risk-tiered -- routine, low-risk changes pass with automated gates alone (per Level B), while higher-risk or novel changes are routed to human review. Tiering criteria are defined but applied judgmentally on a per-change basis.

**Transition C → D — Add structurally independent AI review**

Introduce an AI review layer independent from the agent or model that generated the code. Review correctness, security, performance, architecture, maintainability, and intent in parallel; preserve the evidence behind findings; and route high-severity findings and high-risk changes to humans.

**Verification:** Independent review identifies material issues before human review, and humans can inspect the basis and severity of each finding.

**Level D — Integral**

An AI review layer, structurally independent from the agent or model that generated the code, performs first-pass review across multiple concern areas (correctness, security, performance, standards) in parallel, surfacing findings ranked by severity. Human review is concentrated on findings the independent reviewer flags as high-severity, or on changes tiered as high-risk per Level C.

**Transition D → E — Calibrate the review system against outcomes**

Track confirmed findings, dismissed findings, escaped defects, false positives, false negatives, and the accuracy of risk-tier assignments. Use those outcomes to adjust reviewer instructions, rules, severity thresholds, and human-review allocation.

**Verification:** The organization can show how observed review outcomes changed thresholds, criteria, or reviewer behavior.

**Level E — Telemetric**

The independent review layer's findings and the team's risk-tiering criteria (per Levels C/D) are continuously calibrated against outcomes -- false-positive and false-negative rates are tracked, tiering thresholds adjust accordingly, and the review system's own effectiveness is itself under ongoing verification.

**Sustainment**

Keep the independent reviewer under continuous evaluation. A review layer that is no longer calibrated becomes another unchecked generator of confidence.

---

## D9. Environment management

*The capability to provision, configure, and maintain the environments (dev/QA/staging/prod, etc.) through which code moves, including parity, ephemerality, self-provisioning, and cleanup.*

**Level A — Nascent**

No standard environment separation exists -- development happens against a single shared, mutable environment (or directly against production), with no consistent dev/QA/staging/prod distinction.

**Transition A → B — Establish standard environment separation**

Create standard environment classes such as development, QA, staging, and production, with documented purpose, access, ownership, and promotion paths. Separate development and testing from production even if provisioning remains manual.

**Verification:** Teams no longer develop against one shared mutable environment or production by default.

**Level B — Modeled**

Standard environments (dev/QA/staging/prod, etc.) exist but are manually provisioned and configured, with inconsistent parity between them.

**Transition B → C — Define environments as code**

Capture infrastructure, configuration, dependencies, secrets interfaces, and policy in repeatable, versioned definitions. Eliminate known parity gaps and govern environment changes through the same change discipline as application code.

**Verification:** Rebuilding an environment from the governed definition produces a materially equivalent environment without undocumented manual configuration.

**Level C — Continuous**

Environments are defined as code (infrastructure-as-code) with consistent, repeatable configuration -- parity between environments is reliable. Provisioning a new environment instance still requires a human-initiated process.

**Transition C → D — Make environments on-demand and ephemeral**

Create templates and human-triggered lifecycle workflows. A pull request, command, or approved workflow provisions an isolated environment from the governed definition and tears it down predictably.

**Verification:** A team member can create and remove an isolated environment through one standard action without infrastructure-specialist intervention.

**Level D — Integral**

Environments can be spun up and torn down on demand from templates, triggered by a human action (e.g., opening a PR, running a command). Ephemeral environments exist, but provisioning and cleanup remain human-triggered events rather than autonomous.

**Transition D → E — Delegate environment lifecycle to agents**

Allow agents to determine when an environment is needed, select the correct governed template, provision it within policy and quota, verify readiness, and remove it when the work completes or expires. Preserve attribution, exception handling, and human oversight.

**Verification:** Routine environment lifecycle occurs without standing human maintenance, while every environment remains attributable and reconstructable.

**Level E — Telemetric**

Environments are ephemeral and self-provisioned by agents on demand, including automated cleanup/teardown -- environment lifecycle requires no standing human maintenance.

**Sustainment**

Continuously test policy, quota, cleanup, access, and cost controls. Autonomous provisioning must remain bounded stewardship, not unmanaged infrastructure creation.

---

## D10. Release discipline

*The capability to govern how validated changes move into production -- gating, approval, rollback, compliance, and release communications -- as a compressible, on-demand cycle rather than a fixed cadence.*

**Level A — Nascent**

Releases follow a fixed cadence (e.g., sprint boundaries) with manual gating, approval, and announcement.

**Transition A → B — Decouple releases from the sprint calendar**

Permit validated changes to release outside fixed sprint or planning boundaries. Automate the minimum test gates required before release while retaining manual approval and communication.

**Verification:** A release can occur outside the fixed cadence when the automated tests pass and a human approves it.

**Level B — Modeled**

Releases occur more frequently than a fixed sprint cadence, and gating is partially automated (automated test suites must pass before release), but approval and release communications remain manual steps requiring human sign-off before each release.

**Transition B → C — Trigger release from validated change**

Deploy from commits or changes that pass the automated gates rather than from the calendar. Automate deployment and rollback based on deterministic health checks, while keeping human oversight for policy changes and material exceptions.

**Verification:** A qualifying change can reach production without a manually assembled release event, and a failed health check can restore the prior state automatically.

**Level C — Continuous**

Releases are triggered by commits passing automated gates (per D8) rather than by calendar -- deployment to production can happen multiple times per day. Rollback is automated (e.g., automatic revert on failed health check), but is treated as an exception-handling path rather than a normal part of the release pattern.

**Transition C → D — Make on-demand release compliant by construction**

Automate pre-deployment approval, compliance checks, audit evidence, and rollback under governed policy. Define which conditions permit release, block release, or require a named exception. Normalize rollback as a tested primary recovery path.

**Verification:** On-demand releases carry automatically assembled compliance evidence, and rollback works as a practiced response rather than an emergency improvisation.

**Level D — Integral**

Pre-deployment gating, approval, and rollback are fully automated and triggered by signal (per Levels B/C) -- releases are on-demand and compliant by construction, with audit trail and compliance checks built into the gate itself (per D11-D). Rollback-as-primary-recovery is a normal, expected path, not an exception.

**Transition D → E — Extend release judgment into production**

Use progressive delivery and live quality gates to decide whether a release should expand, hold, or roll back based on actual behavior. Include relevant measures such as error budgets, anomaly signals, evidence coverage, and other production-quality indicators.

**Verification:** A release can be expanded, constrained, or reversed automatically from live evidence while preserving its decision and audit trail.

**Level E — Telemetric**

Pre-deployment gates (per Level D) are necessarily incomplete for AI-generated, non-deterministic output -- release decisions extend into production via live quality gates, using real-time performance signals (e.g., error budgets, evidence coverage) as part of the release decision itself, not only as post-release monitoring. A release can be incrementally validated and expanded, or rolled back, based on its live behavior, not only its pre-deployment checks.

**Sustainment**

Continuously recalibrate live quality gates. Production evidence should govern exposure without allowing noisy or poorly understood signals to create release instability.

---

## D11. Security & compliance

*The capability to identify, assess, and mitigate security and regulatory risk introduced at any stage of the lifecycle — including risk novel to AI-generated artifacts and agent tooling — by making every agent action attributable to an agent, a session and an initiating human, bounded to its authorized extent and least-privileged against a declared minimum each role documents, and observed so that departures from the minimum are read as telemetry. Refusal is reserved for what every act must carry — a named actor and an authority path — for the irreversible, and for what an obligation names; every departure from the declared minimum is measured.*

**Level A — Nascent**

Agents act anonymously, with no declared extent and no declared minimum. Agent activity is indistinguishable from the human operating it; what an agent may do is whatever that human may do; nothing records what an agent did that it should not have. Failure is discovered after the fact, if at all, by someone looking.

**Transition A → B — Name and identify every actor**

Give each agent session an identity distinct from the human — a per-agent or per-session credential, or a required provenance mark carried in the change path — and require it on every material action: commits, deploys, publications, external calls. Check it — by review, by a stated convention, or by a hook that warns — so that an unattributed change is seen and attributed before anything relies on it. Scan generated artifacts deterministically (SAST, secret detection) regardless of origin, and read what the scan reports.

**Verification:** Every material agent action can be traced to a specific agent, session and initiating human; an unattributed change is caught and attributed before it is relied on; a scan runs on every generated artifact and its findings are read.

**Level B — Modeled**

Every material agent action is attributable, and attribution is checked by a person or a convention rather than enforced by a gate. Generated artifacts are scanned deterministically and the findings are read. No minimum is yet declared: an agent's authorized extent is whatever the human's is, now with a name on it, and nothing reads how far from a minimum the agent's actions range.

**Transition B → C — Make the floor structural, declare the minimum, and read the departures**

Make the floor a gate: an unattributed change, an act with no authority path, and a pushed secret are refused rather than caught. Then, for each agent role, establish and document the minimum set of actions it needs — least privilege as a stated ideal, not a wall inferred from imagined failures. Install pre-execution observation that classifies every action against the declared minimum and logs each departure by kind — would-refuse, would-ask — without refusing it, except for two classes the practice documents with their sources and denies outright: the irreversible (destruction of pushed history, repositories or releases; exfiltration of secrets; whatever else the practice can show cannot be undone) and the obligated (what a regulator, a contract or a named policy forbids, reversible or not). Calibrate the observation against the practice's real past actions before it runs, so that the minimum is drawn where the work is rather than where fear is. Read the departure log at a stated cadence.

**Verification:** The floor refuses — an unattributed change does not land and a secret does not leave the repository; each role's authorized extent and declared minimum are documented, current, and available to the role that works under it and to anyone assessing it; every departure is logged with its kind; the log is read on its cadence; a minimum contacted often has been revised or the process behind the contact fixed; the irreversible and obligated classes are denied, each documented with its source; and the observation point's reach has been established by attempt, not inferred from its configuration.

**Level C — Continuous**

Each role's authorized extent and declared minimum are documented and current. The floor — a named actor, an authority path, no secret leaving the repository — is refused by a gate rather than checked by a person. Departures from the minimum are observed continuously and read each cycle; beyond the floor, only the irreversible and obligated classes are refused. Agent tooling — skills, plugins, MCP servers — is inventoried as part of the authorized extent. Shared memory and context carry provenance. The practice knows, from counts, which bounds are contacted and which never are, and treats a frequently contacted minimum as a process defect rather than a security success.

**Transition C → D — Earn the refusals, mediate them at runtime, and declare what is not mediated**

Move a departure class from logged to refused only when its log shows the refusal would fire rarely and the harm is real; keep a named, logged exception path for every refusal. Mediate the floor and the refused classes at the point of action — least-privilege scoping and runtime authorization bound each action as it happens, with the ability to constrain or terminate an agent while it acts — and make them non-bypassable by an individual except through that path. Require every observation and refusal point to declare the paths by which it can be crossed, or to assert that none exist. Assemble audit evidence from the logs rather than by hand. Scan the tooling inventory as supply-chain surface, and monitor shared memory and context actively for injected, poisoned or anomalous content, not only for provenance.

**Verification:** Every refusal and every exception identifies its authority, rationale, scope and duration; the set of refused classes can be shown to derive from the departure log; unsafe behavior can be constrained or terminated while it is occurring, and an individual cannot silently bypass the floor or a refused class; every observation and refusal point declares the paths by which it can be crossed, or asserts that none exist; an active context-integrity threat is detected while active; audit evidence assembles itself; and the runtime enforcement has been exercised, not only documented.

**Level D — Integral**

Refusals are earned from telemetry and mediated at the point of action: least-privilege scoping and runtime authorization bound each action as it happens, a kill switch exists and is exercised, and the floor and the refused classes are non-bypassable except by logged exception. Every observation and refusal point states what it does not mediate. Audit evidence is generated from the logs. Agent tooling is inventoried and scanned as supply-chain surface, and shared context is actively monitored. The extent, the minimum, the log and the exception record are one auditable system.

**Transition D → E — Instrument the hits and the silence**

Connect refusals, exceptions and departures to a continuous loop that reads both where bounds were hit and where they never were. A refusal that is never contacted is reviewed for removal unless it guards an irreversible act or a stated obligation; a minimum contacted often is a process defect to fix, not a security success. Feed what the loop finds into the practice's priorities, so that bounds and process are revised on evidence.

**Verification:** The loop reports both bounds that were hit and controls that never fired, and at least one refusal or minimum has been retired, revised or confirmed necessary on that evidence.

**Level E — Telemetric**

Policy is enforced at the point of action and read as telemetry in the same motion. The departure log, the refusals and the controls that never fire are a standing input to the practice's priorities, so that bounds and process co-evolve with the agents that work under them, and a refusal survives only while the evidence, an irreversible act or a stated obligation keeps it.

**Sustainment**

Exercise the kill switch, the exception path, the context-integrity controls and each role's extent and minimum regularly, and keep reading the departure log. A refusal never contacted is reviewed for removal unless it guards an irreversible act or a stated obligation; a minimum contacted often is a process defect, not a security success. Runtime enforcement that is not tested is only documented intent.

---

## D12. Instrumentation & observability

*The capability to monitor, trace, and evaluate system behavior in production, and to structure organizational knowledge (decisions, plans, metrics) for equal consumption by humans and agents, closing the loop back to upstream dimensions. If AI is only used to generate deterministic artifacts (e.g., code, tests, IaC) and is not in the runtime decision path, production observability requirements stay primarily classical; AI-specific tracing/evaluation applies at build time.*

**Level A — Nascent**

Monitoring covers infrastructure/application metrics; organizational knowledge (decisions, plans, metrics) lives in human-readable formats not structured for agent consumption.

**Transition A → B — Retain build-time generation traces**

Capture enough of D4–D8 generation activity to investigate why a deterministic artifact was produced: agent or model identity, relevant inputs and outputs, timing, tool activity, and artifact lineage. Begin with workflows where failure is frequent or consequential.

**Verification:** When generated output fails, the team can inspect the relevant generation record instead of relying on memory or recreating the session.

**Level B — Modeled**

Build-time generation steps (D4-D8) produce some trace of agent reasoning (e.g., logs of prompts and outputs), but this is ad hoc, not systematically retained, and not used for evaluation -- when something goes wrong, the org has a deterministic output but no reliable visibility into why the agent produced it.

**Transition B → C — Turn traces into systematic evaluation**

Standardize retention and use traces to identify recurring failure patterns rather than merely debug isolated incidents. Define failure categories, quality measures, and review practices, and feed findings back into specification, generation, architecture, testing, and review.

**Verification:** Repeated generation failures produce measurable upstream changes, and the organization can show the pattern that justified each change.

**Level C — Continuous**

Build-time tracing (per Level B) is systematic and feeds evaluation -- generation-step traces are retained and used to diagnose recurring failure patterns in D4-D8's output (e.g., why D8's review keeps flagging the same kind of issue from generation), as a continuous practice rather than per-incident debugging.

**Transition C → D — Identify and observe runtime non-determinism**

Classify every place where AI participates in runtime decisions within the delivery system, such as environment provisioning, release gating, or rollback. Instrument and evaluate those surfaces separately from build-time generation, and distinguish them from any AI behavior inside the shipped product.

**Verification:** The organization can enumerate its build-time, delivery-runtime, and product-runtime AI surfaces and show the tracing and evaluation applied to each.

**Level D — Integral**

The organization has identified where, if anywhere, AI participates in its own delivery system's runtime decisions (e.g., D9-E's self-provisioning, D10-E's live release gating) and applies runtime tracing and evaluation there, distinct from and in addition to the build-time tracing per Level C. If the shipped product also has AI in its runtime path, that is recognized as a separate observability surface from the delivery system's own.

**Transition D → E — Make observability directly usable by humans and agents**

Expose build-time traces, delivery-runtime traces, production telemetry, decisions, and plans through governed structures available to both humans and agents. Connect observed behavior back to upstream dimensions, including the Shared Intelligence Layer.

**Verification:** A material production or delivery signal can be traced to the relevant upstream decision and enter the governed feedback path without manual evidence reconstruction.

**Level E — Telemetric**

Build-time generation traces (per C), delivery-system runtime traces (per D), and production telemetry are equally and directly accessible to agents alongside humans, and observability data feeds back into upstream dimensions (e.g., D1) as part of a closed loop. The organization continuously re-evaluates where non-determinism lives in its delivery system as D1-D11 mature, rather than treating the answer from Level D as fixed.

**Sustainment**

Continuously reassess where non-determinism lives as the delivery system evolves. Observability architecture must change when AI crosses a new build-time, delivery-runtime, or product-runtime boundary.

---

## D13. Feedback loop velocity

*The end-to-end cycle time from signal (market, user, incident, failure) to shipped response, as a property of the whole system rather than any individual stage.*

**Level A — Nascent**

End-to-end cycle time from signal (market, user, incident) to shipped response is unmeasured and dominated by handoffs between disconnected stages/teams.

**Transition A → B — Make the end-to-end cycle measurable**

Define the start and end points of the response cycle and measure them retrospectively for major releases, incidents, failures, or market responses. Preserve timestamps and handoffs well enough to reconstruct elapsed time.

**Verification:** The organization can calculate how long a completed response took from originating signal to shipped change and identify the major handoffs involved.

**Level B — Modeled**

Cycle time is measured retrospectively for major releases or incidents (e.g., post-mortems calculate how long the response took), but isn't tracked continuously and isn't used to identify which handoff in the chain is the bottleneck.

**Transition B → C — Measure continuously by stage and handoff**

Instrument the full cycle across D1–D12 and establish a standing view of cycle time by stage and handoff. Use consistent definitions so the organization can identify which current handoff dominates total elapsed time.

**Verification:** At any point, the organization can name the dominant contributor to end-to-end cycle time using current evidence rather than retrospective opinion.

**Level C — Continuous**

Cycle time is tracked continuously as a standing metric, broken down by stage and handoff (per the D1-D3 -> fused D4/D5/D7 -> D6/D8 -> D9/D10 chain) -- the organization can identify which handoff currently dominates total cycle time, though addressing it requires separate prioritization and planning work.

**Transition C → D — Treat bottleneck removal as normal priority work**

When D13 identifies the dominant delay, treat the relevant dimension's next maturity step as comparable to feature work. Assign ownership, investment, and an expected cycle-time effect, then verify whether the bottleneck moved or merely changed form.

**Verification:** At least one identified handoff constraint has been funded and improved through the normal prioritization system with before-and-after evidence.

**Level D — Integral**

Improving cycle time is a routine input to prioritization across D1-D12 -- when D13's measurement identifies a dominant bottleneck, closing it via the relevant dimension's next maturity step is treated as comparable in priority to feature work, not a separate platform initiative competing for attention.

**Transition D → E — Compress the complete closed loop**

Optimize the full cycle rather than isolated stages. Ensure a market, user, incident, failure, or outcome signal can be observed, interpreted, returned to the appropriate upstream model or intent, reprioritized through proper authority, delivered, and observed again. Repeatedly remove whichever handoff currently dominates.

**Verification:** The organization demonstrates repeated governed signal-to-response cycles operating on a days-not-months cadence, including upstream reconsideration where warranted.

**Level E — Telemetric**

End-to-end cycle time is short enough to be a competitive differentiator, operating on a days, not months, cadence -- achieved not by any single dimension but by D12-E's closed loop keeping every stage's transit time visible and D13-D's prioritization continuously compressing whichever handoff currently dominates.

**Sustainment**

Protect quality, evidence, authority, and intent while compressing time. The loop is not mature if speed is achieved by bypassing the very gates that make the response trustworthy.

---

## Cross-dimension boundary checks

These checks exist because a dimension reaching a high level can look, from a distance, like it has absorbed a neighboring dimension's job. It hasn't -- each pairing below names the boundary explicitly so that maturity in one dimension is never mistaken for coverage of another's.

### D4 / D5 / D7

- D4 governs specification quality and traceability.
- D5 governs the prototype-to-production disposition.
- D7 governs verification derived from intended behavior.
- Their Level E convergence is one governed motion, not the disappearance of their distinct concerns.

### D6 / D8

- D6 prevents and remediates architectural nonconformance.
- D8 evaluates broader correctness, security, maintainability, performance, and alignment with intent.
- Encoded architecture rules do not eliminate the need for risk-tiered review.

### D6 / D11

- D6 governs what an agent may build.
- D11 governs what an agent may do.
- A documented minimum is not an architectural rule, and an encoded architecture does not bound execution.

### D8 / D11

- D8 reviews code and artifacts.
- D11 attributes, bounds and observes agent execution, and refuses what lacks the floor, the irreversible and the obligated.
- Strong code review does not make unrestricted agent execution safe.

### D9 / D10

- D9 supplies the environments through which code moves.
- D10 governs whether and how validated changes advance into production.
- Self-provisioning environments do not imply autonomous release authority.

### D11 / D12

- D11 emits the departure log.
- D12 keeps and evaluates it with every other trace.
- A read departure log is D11 at C, not D12 at C.

### D12 / D13

- D12 supplies the evidence of the feedback return.
- D13 measures and compresses the time required for that evidence to change understanding, priority, and shipped behavior.

**D12 makes the loop observable. D13 makes the loop competitive.**

---

*Status: D4-D13 locked baseline, all A-E, now with inline transition and verification notes for every step and Level E sustainment guidance (folded in from `sdlc_transition_states_d4_d13.md` v0.2, 2026-07-27 -- see `CHANGELOG.md`). D11 was rewritten in v1.3.0 (2026-10-06) from the practice's own record and is no longer marked deferred; D11 scores against the v1.2.0 ladder are not comparable with scores against this one (see `CHANGELOG.md`). D1-D3 inherited by reference from `shared_intelligence_layer.md` (STD-SHARED-INTELLIGENCE v1.1 as of 2026-10-06), which carries its own transition notes and verification statements inline -- see that document's own status. Family-wide maturity-level names (Nascent/Modeled/Continuous/Integral/Telemetric) applied throughout as of 2026-07-27. See `README.md` for open items, flagged candidate "lumpy" transitions, and known areas expected to evolve.*