# AI-Native Maturity Models — AI-Readable Digest

This is a machine-readable digest of the AI-Native Maturity Model family, the Strata governance-layer model, the Enterprise Architecture OKF schema they're built on, and the site's Function Models — assembled for handing directly to an AI assistant. Generated at build time from the same canonical sources this site itself renders from; nothing here is hand-duplicated or summarized. CURRENCY BASIS: this digest fetches every model from `main` — it is always current, and it is NOT pinned. The site's Whole-Model Views do NOT share this basis, and they do not all share one basis with each other: the SDLC view reads short-form cells at main and full model text pinned at cb6ffd1; the PDLC view reads short-form cells pinned at a0f1876 and full model text pinned at a0f1876 and shared D1-D3 layer pinned at cb6ffd1. Each of those pages states its own basis where it renders. Same sources, different points in their history: when this digest and a model page disagree, that is temporal skew between two correct renderings, not an error in either, and this sentence is here so a reader can tell which is which rather than discovering it.

## Provenance

**This document is a rendering, not a source of truth.** It is generated at build time and regenerated on every deploy. It carries no independent authority: where it and a canonical source disagree, the canonical source governs and this file is the thing that is wrong.

**What it renders, and from where:**

* The three maturity models — `STD-SDLC-MM`, `STD-PDLC-MM`, `STD-PRIORITIZATION-MM` — fetched at build time from their own public repositories (`ai-native-sdlc-maturity-model`, `ai-native-pdlc-maturity-model`, `ai-native-product-prioritization-maturity-model`). Those repositories are canonical for all model content.
* SDLC and PDLC dimensions D1–D3 — `STD-SHARED-INTELLIGENCE`, inherited by reference by both models rather than owned by either.
* The Strata governance-layer model — `SPEC-STRATA`, which is sole authority for the strata, the intent fiber, the fiber/feedback distinction, and the definition of "consequential."
* The Function Models — the `DS-014` content pattern, which is sole authority for what a Function Model is and is not.
* One of the instructions below restates a governed rule rather than asserting independently: M9's no-averaging rule is `P-11`. G2's preserve-asymmetries posture is this digest's own, stated for a reader who has no one to ask, and is not offered here as a citation to the governed record.

**Where the governed record lives:** a private Enterprise Architecture corpus, not this site. The items named above are cited by identifier so a reader can see what governs a claim, not because those items are reachable from here. Nothing in this digest is the governed record; it is evidence of it.

**Currency:** this rendering is only as current as its last build. A digest depicting a superseded state is misinformation rather than documentation debt — if it disagrees with a canonical source, trust the source and treat this file as stale.

## Instructions for AI use

This digest contains four distinct artifact classes, and the instructions differ by class. Identify which class an artifact belongs to before applying any instruction to it. **Instructions G1–G3 apply across all four** and are stated first, because they govern how to handle conflict and asymmetry wherever you meet it.

* **Maturity models** (SDLC, PDLC, Product Prioritization) — assessment instruments with A–E ladders. Instructions **M1–M11** apply.
* **Strata** (S0–S7) — a governance-layer model for classifying work. Instructions **S1–S4** apply.
* **Function models** (Product Management, Product Marketing, Software Engineering) — flat ontological maps. Instructions **F1–F5** apply.
* **Enterprise Architecture OKF** — the schema this family is written in. Reference context only: it is neither scored nor used to classify work, and none of the instruction sets below apply to it. Read it to understand the vocabulary the other three classes are described in.

Applying one class's instructions to another is a category error, not a judgment call. Function models in particular have no levels, no transitions, and no maturity axis; scoring one is invalid regardless of how the request is phrased.

### G — General posture (applies across all classes)

G1. **These instructions govern.** Where the M/S/F instructions here and older or artifact-local text elsewhere in this digest appear to conflict, the instructions govern — and the tension itself is worth reporting. Do not treat an older passage's wording as silently overriding an instruction, and do not treat the conflict as yours to resolve unremarked.

G2. **Preserve issued asymmetries — do not editorially reconcile.** This digest contains real, deliberate asymmetries: dimensions that carry per-transition verification clauses beside dimensions that do not, one model with an Indicative evidence column and two without, function models with a Boundary Note and one without. These are the issued state, not drafting oversights, and smoothing them into an apparent consistency destroys information. The discipline is *if the record and the statement conflict, ask — never reconcile silently*, stated here for a reader who has no one to ask. Where you cannot ask, report the asymmetry and proceed against what the record actually says.

G3. **Formal-score boundary.** A reader given only this public digest can assess a practice against a model and its verification clauses, and should say so plainly. That assessment is **not** a formal `SPEC-D6-SCORE` result. The scoring instruments (`SPEC-D6-SCORE`, `SPEC-D6-SCORE-PDLC`, `SPEC-D6-SCORE-PRIORITIZATION`) carry their own criteria text, evidence rules, and select rules, and live in a private governance corpus not included here. Do not describe output as a formal instrument result unless that instrument was also supplied to you.

### M — Scoring a maturity model

M1. Treat each dimension independently; do not infer one score from another.
M2. Assign only Pre-AI, A, B, C, D, E, or Exempt with a valid constraint reference.
M3. Score from demonstrated evidence, not stated aspiration or tool ownership.
M4. Use the destination level's own Verification clause as the evidence standard for that score. Where a dimension carries per-transition verification clauses, a level is not reached until its verification test is met in practice, not merely claimed. Where a dimension does not yet carry verification clauses in that form — D1–D3 in both SDLC and PDLC, inherited by reference from the Shared Intelligence Layer and owned by neither model — say so rather than substituting a verification test of your own construction. **That absence does not make the dimension unscoreable** — score it from correspondence to the destination level's own definition, and state explicitly that transition-completeness could not be tested against a public verification clause because none exists in that form. Declining to score is the wrong response; scoring while claiming a verification test you didn't have is the other wrong response. Where a model supplies **both** an Indicative evidence column and a Verification clause — the Product Prioritization model does; SDLC and PDLC do not — they answer different questions and are not interchangeable: indicative evidence is what you would expect to observe at a level and supports the level assignment; the verification clause is the test of whether the transition to it actually landed, and governs completeness. Do not score against the evidence column alone because it reads as a checklist.
M5. Dimension IDs are scoped to their own model and never transfer across models. The Product Prioritization model's D1–D3 (Value Model Coherence, Decision Governance & Portfolio Integration, Outcome Calibration & Adaptation) are entirely unrelated to the Shared Intelligence Layer's D1–D3 (Market discovery, Persona development, Positioning) inherited by SDLC and PDLC. Likewise SDLC's D12 (Instrumentation & observability) and PDLC's D12 (Feedback loop velocity) are different dimensions — PDLC's D12 corresponds in shape to SDLC's **D13**, not its D12. Always name the model alongside the dimension ID.
M6. Distinguish current-state evidence, scoring rationale, transition guidance, and verification criteria in your output.
M7. Recommend the next adjacent transition unless explicitly asked for a longer-range target state.
M8. Preserve the cross-dimension boundaries defined in this digest. Maturity in one dimension is never coverage of another's concern.
M9. Do not average, sum, or otherwise collapse any dimension — Exempt or A–E — into an aggregate maturity score. Each dimension is independently meaningful; a distribution count or modal level is fine, an arithmetic mean is not (OKF TOGAF corpus P-11).
M10. Identify uncertainty and request missing evidence rather than inventing it.
M11. Cite the model version used.
M12. **Level names carry zero scoring semantics.** The family-wide names — Nascent, Modeled, Continuous, Integral, Telemetric — are labels for A through E, not criteria. Never infer or justify a level from what its name *sounds like*; score only from the dimension's own level text. The names were locked family-wide for consistency across thirteen, twelve, and three dimensions respectively, which necessarily means a given name fits some dimensions more naturally than others — "Telemetric" reads more literally for an observability dimension than for a discovery one. That looseness is a known and accepted cost of a shared vocabulary, not a hidden signal to decode.

### S — Classifying work against Strata

These govern how you classify your own proposed or executed work before treating it as real — a different task from scoring the models above.

S1. Before proposing or executing any consequential undertaking, identify: its legal artifact or act type; its architectural stratum; the intent it realizes; the authority under which it may proceed. **"Consequential" has a checkable definition** (governing source: SPEC-STRATA): an undertaking is consequential when treating it as real would **create, change, approve, commit, deploy, publish, allocate, bind, or retire a governed thing — or otherwise exercise authority.** Analysis, explanation, and hypothetical drafting are not consequential merely because the subject matter is important. Thinking about a contract is not issuing one; describing a deployment is not deploying.
S2. Treat a missing, illegal, or unresolved type, stratum, intent reference, or authority as a construction failure — not as a field to infer silently.
S3. Distinguish structural validity from semantic validity: resolution proves that an intent reference exists; human judgment determines whether the undertaking genuinely realizes that intent.
S4. A governed thing's type is formally: `GovernedThing[S](i : Intent)` — indexed by both its stratum and the intent it realizes. In compact notation: `thing : LegalType @ LegalStratum realizes Intent`. A thing missing a legal type is undefined; missing or illegal stratum, misplaced; missing or unresolved intent, ill-typed; missing authority, unactionable regardless of otherwise being well-formed.

### F — Reading a function model

F1. A function model is an ontological map, not an assessment instrument. It names what a function consists of — inputs, activities, capabilities, enabling substrates, outputs — independent of how well any organization performs it.
F2. Do not assign levels, scores, maturity readings, or A–E letters to any element of a function model. There is no maturity axis to place them on. If asked to assess maturity for a function that has a function model here but no corresponding maturity model, say that plainly rather than constructing a ladder.
F3. Function models have no sequence, flow, triggers, or arrows. Inputs and outputs are categories, not steps, and their order in the document carries no temporal meaning. A trigger presumes a time axis this layer does not have. If a question requires sequence, it is asking about a process or lifecycle, which is a different artifact not included in this digest. **This extends to vocabulary:** process-associated words appearing in an activity or capability label — "cadence," "planning," "review," "monitoring" — are names of what the function consists of, not implied recurrence, ordering, or triggering. (Governing source: DS-014, the Function Model pattern's own definition in this practice's governance corpus.)
F4. Use a function model to check completeness and placement: whether an organization's described function has named all its inputs, activities, capabilities, enabling substrates, and outputs, and where a described activity structurally belongs. Do not use it to judge execution quality.
F5. Respect the stated boundary notes. Where a function model declares what an adjacent function owns — Product Management retaining positioning, pricing, packaging, and release-goal authority; Sales owning commercial commitment; Software Engineering owning HOW rather than WHAT — do not reassign that ownership in analysis or recommendations. **Lexical overlap between sibling function models is not automatically an ownership conflict.** The same noun can appear in two models under genuinely different relationships — authority over it, source intelligence feeding it, transformation of it, production of it, consumption of it. "Messaging" appearing in both Product Management and Product Marketing is the designed case, not a defect. Flag a real conflict only where two models assign the *same* decision authority or the *same* accountable production responsibility for the same thing. (Governing source: DS-014.)

**What's included:** all three live models in the AI-Native Maturity Model family. The **SDLC** model, complete — all 13 dimensions, A through E; D4–D13 carry explicit per-transition verification clauses, but D1–D3 (shared with PDLC) carry transitions and Level E sustainment guidance without verification statements in that same per-transition form yet — a real asymmetry between the two halves of this specific model, not an omission from this digest. The **PDLC** model — D4–D12 own content, complete with per-transition verification clauses throughout; D1–D3 inherited by reference from the same shared source SDLC uses. The **Product Prioritization** model — all 3 dimensions, complete with per-transition verification clauses throughout. Also included: the Strata governance-layer model (S0–S7); the Enterprise Architecture OKF explainer; the Function Models family (flat, ontological maps of what a function consists of — deliberately not maturity models, no AI-nativity axis or A-E progression), currently three entries: the Product Management, Product Marketing, and Software Engineering Function Models.

**What's not included, and why:** the interactive self-assessment tool is deliberately excluded — it's a scoring instrument for one organization's own use, not reference material to hand an AI. Formal scoring instruments now exist for all three models (SPEC-D6-SCORE for SDLC, plus SPEC-D6-SCORE-PDLC and SPEC-D6-SCORE-PRIORITIZATION, both added 2026-07-28) — but their own criteria text lives in a private governance corpus, not these public model repos, so it isn't included in this digest either. All three models can be formally blind-scored; the instruments themselves just aren't reference material handed to an AI here.

**A note on internal references:** the canonical text below sometimes points to files not included in this digest — `README.md`, `CHANGELOG.md`, `sdlc_handoff_diagram.png`, superseded-text files, and briefs in a private governance corpus. These are provenance citations, useful to a human tracing a decision's history — not context this digest expects you to have. Treat any such reference as external provenance only: don't assume its contents, and don't treat its absence as a gap in what's handed to you here.

Canonical sources: https://github.com/superdtf-0882/ai-native-sdlc-maturity-model, https://github.com/superdtf-0882/ai-native-pdlc-maturity-model, https://github.com/superdtf-0882/ai-native-product-prioritization-maturity-model (all CC BY 4.0, © David Facer)

---

## AI-Native SDLC Maturity Model

# AI-Native Shared Intelligence Layer — D1–D3

**STD-SHARED-INTELLIGENCE · v1.0.0 · 2026-07-23**

> 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. 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.

**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.

**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.

**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.

**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.

**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.

**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.

**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.

**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.

**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.

**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.

**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.

**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.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.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.

### 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, and Prioritization), 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.0.0), 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 risks novel to AI-generated artifacts and agent tooling. [Deferred -- needs further research/context]*

> **Draft caution:** The underlying D11 maturity definition remains marked for further research. The transitions below operationalize the current ladder but inherit that same provisional status.

**Level A — Nascent**

Agents execute with unrestricted access to the filesystem, shell, and network on whatever system runs them -- no sandboxing, no pre-execution validation of dangerous operations, and no agent-specific identity (agent activity is indistinguishable from the human operating it).

**Transition A → B — Contain agent execution**

Introduce sandboxing, filesystem and network restrictions, pre-execution checks for dangerous operations, and deterministic scanning for generated artifacts. Define the minimum actions an agent may perform and deny unrestricted use of shared human environments.

**Verification:** An agent cannot perform a destructive or unauthorized filesystem, shell, or network action merely because the initiating human could.

**Level B — Modeled**

Agents execute within sandboxed environments (restricted syscalls, network egress controls) with pre-execution static checks for dangerous patterns (e.g., destructive shell commands, unvalidated file I/O); deterministic security scanning (SAST, secret detection) runs on all generated code regardless of origin. Agents still lack distinct identities, and shared memory or context across sessions is not integrity-checked.

**Transition B → C — Give agent activity distinct identity and provenance**

Use per-agent or per-session credentials and associate each agent-authored change with the initiating human and session. Require this provenance in the change path, and add baseline integrity validation for shared memory or context.

**Verification:** Every material agent action is attributable to a specific agent session and initiating human, and shared context has inspectable provenance.

**Level C — Continuous**

Agent actions are mapped to identifiable, auditable identities (per-agent or per-session credentials, not shared human credentials) -- every agent-authored change can be traced to a specific agent, session, and initiating human. PR gates require this labeling, though individual override of the gate remains possible. Shared memory/context stores have basic integrity validation (e.g., provenance tagging) but no active poisoning detection.

**Transition C → D — Make controls centrally enforced and non-bypassable**

Replace individually bypassable controls with mandatory gates and a named, logged exception process. Inventory skills, plugins, MCP servers, and other agent tooling as supply-chain components subject to approval and scanning. Automate audit-evidence assembly.

**Verification:** An individual cannot silently bypass required controls, and every exception identifies its authority, rationale, scope, and duration.

**Level D — Integral**

PR gates for agent-authored changes are mandatory and non-bypassable by individual override -- required checks (security scanning, review, labeling) can only be waived through a named, logged exception process. Agent tooling itself (skills, MCP servers, plugins) is inventoried and treated as supply-chain surface subject to the same scanning. Audit evidence generation is automated rather than manually assembled.

**Transition D → E — Enforce policy at the point of action**

Apply least privilege, runtime authorization, behavior guardrails, and real-time termination capability during agent execution. Actively monitor shared memory and context for injected, poisoned, anomalous, or unauthorized content.

**Verification:** The organization can constrain or terminate unsafe behavior while it is occurring and can detect active context-integrity threats.

**Level E — Telemetric**

Security policy for agent behavior is enforced at the point of action -- least-privilege scoping and runtime guardrails constrain what an agent can do during execution, with real-time termination ('kill switch') capability rather than after-the-fact logging alone. Shared memory and context are actively monitored for injected or anomalous content, not merely provenance-tagged.

**Sustainment**

Exercise kill switches, exception paths, context-integrity controls, and least-privilege boundaries regularly. 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.

### D8 / D11

- D8 reviews code and artifacts.
- D11 contains agent execution and governs agent identity, tooling, runtime action, and context integrity.
- 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.

### 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`). "Locked baseline" describes the issued state of the matrix as a whole, not a claim that every dimension's content is equally settled: D11 is explicitly provisional (marked "Deferred -- needs further research/context" at its own definition, its transitions inheriting that same provisional status) and is included in this baseline deliberately, not excluded -- the point is that its status stays visible rather than silently smoothed over. D1-D3 inherited by reference from `shared_intelligence_layer.md` (STD-SHARED-INTELLIGENCE v1.0.0) as of 2026-07-23, which carries its own transition notes inline already -- 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.*

---

## AI-Native PDLC Maturity Model

# AI-Native PDLC Maturity Model — Matrix

**Version 1.2.0 — 2026-07-28** (Per-Dimension Deep-Dive essays added in `deep_dives/` for all 12 dimensions — narrative content, no change to this matrix. v1.1.0 added per-transition verification clauses for D4–D12, matching the family's own precedent — SDLC's D4–D13 each carry an explicit test of whether the destination state was actually reached, not just claimed. D1–D3 are unaffected — they're inherited by reference from `shared_intelligence_layer.md`, not owned here. No change to any dimension's underlying maturity-state content; where a transition already carried an informal "The test: ..." sentence, it's reformatted as an explicit **Verification:** clause with the same substance, not rewritten. See `CHANGELOG.md`. Locked baseline remains v1.0.0 — 2026-07-27, unchanged below.)

This is the full A–E maturity matrix for the AI-Native PDLC Maturity Model — 12 dimensions (D1–D3 by reference, D4–D12 in full below), readable in-browser and directly usable as input to AI tools. **This markdown document is the source of truth for D4–D12.** D1–D3 are sourced from `shared_intelligence_layer.md`, not this file — PDLC and SDLC converge on genuinely identical language for those three dimensions; D4 is where the two models diverge, in kind rather than degree (see D4's own note below).

For the design principles and provenance behind this matrix, see `README.md`.

---

## 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.

Dimensions are independently scored — an organization can be advanced in one dimension and nascent in another.

Each level is followed by the transition required to reach the next level, and a verification clause — a practical test of whether the destination state was actually 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.

**Family position:** PDLC measures the Product Management function. D1–D4 are inherited from the shared intelligence layer / SDLC (D1–D3 fully shared; D4 diverges by design). D5–D11 are PM-native, with no SDLC equivalent. D12 is this model's own feedback-loop-velocity dimension — an S0 echo, virtually identical in shape to SDLC's D13.

### 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, and Prioritization), 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 D5, D6, and so on.

---

### INTELLIGENCE LAYER / D1–D3 / Inherited from the Shared Intelligence Layer / Converge at Level E

D1 (Market discovery & definition), D2 (Buyer/user persona development), and D3 (Positioning & competitive intelligence) are inherited by reference from `shared_intelligence_layer.md` — the canonical, shared-with-SDLC source, ratified 2026-07-23. This matrix does not maintain its own copy of D1–D3; see that document for the full A–E ladder text for all three.

PDLC-specific deltas on top of the shared text:

- **D1 (Market discovery & definition):** PDLC extends the shared definition to include the portfolio-investment feed — market discovery output directly informs D8 (portfolio & investment management) as well as requirements work.
- **D2 (Buyer/user persona development):** no PDLC-specific delta beyond the shared text.
- **D3 (Positioning & competitive intelligence):** PDLC explicitly absorbs strategic synthesis — the organization's live claim about what it will specifically be better at than competitors (cheaper, faster, higher quality) is PM-owned territory in this model.

---

### SPECIFICATION LAYER / D4 / Diverges from SDLC by design

#### D4. Requirements management

**Type:** Shared origin, diverged content | **Note:** PDLC delta: traceability extends upstream to market/user signal (D1–D3) and downstream to portfolio investment (D8). The PM function owns this bridge. D1–D3 converge to genuinely identical language across SDLC/PDLC; D4 is where the divergence begins — different in kind, not degree (SDLC's D4 gates generation quality; PDLC's D4 gates portfolio investment and upstream/downstream traceability). Per that reasoning, D4 carries its own full ladder here rather than a shared-source reference.

**Definition:** The capability to author precise, testable, machine-actionable specifications with full traceability from market/user signal through delivery, such that specification quality directly gates AI generation quality, verification coverage, and portfolio investment decisions.

| Level | Description | Transition to next level | Verification |
|-------|-------------|--------------------------|---------------|
| A - Nascent | Specifications are written informally with no consistent structure or format. Traceability from source signal to delivery is manual or absent. AI assistance is individual and unsystematic. | Adopt a consistent specification format and require AI assistance in drafting. Define the minimum fields (intent, acceptance criteria, source signal) and apply them uniformly. Establish a shared system of record with cross-functional access. | A teammate outside the original author can locate the current specification, its source signal, and its acceptance criteria without asking that author. |
| B - Modeled | A consistent specification format is adopted and AI assists with drafting. The system of record is shared with cross-functional access (Product, Engineering, QA, Release Management), with UX designs and wireframes linked. Specifications are not yet machine-actionable — they require human interpretation before AI generation can act on them directly. | Make specifications machine-actionable. Define what machine-actionable means for your engineering context such that an AI generation tool can consume a specification without human reformulation. Begin building systematic traceability from market/user signal to specification. | An AI generation tool consumes a specification as written and produces a usable draft artifact without a person first restructuring or reformulating it. |
| C - Continuous | Specifications are structured and machine-actionable. AI generation tools can consume them without human reformulation. Traceability from market/user signal to specification is maintained systematically. | Close bidirectional traceability from market/user signal through specification to delivered artifact. Automate flagging: when an upstream signal changes, affected specifications should surface without manual audit. Connect requirements to prioritization and portfolio investment as a live input. | When an upstream market/user signal changes, the specifications it affects are flagged automatically, without a person auditing the backlog to find them. |
| D - Integral | Full bidirectional traceability from market/user signal through specification to delivered artifact is maintained automatically. When an upstream signal changes, affected specifications are flagged without manual audit. Specifications are a live asset consumed directly by prioritization, portfolio investment, and engineering. | Make the requirements layer self-maintaining. The system should continuously reconcile specifications against upstream intelligence and downstream delivery signal, surfacing gaps and conflicts without manual review cycles. | Specifications reconcile against upstream and downstream signal on their own cadence, and a genuine conflict surfaces without a scheduled review triggering the check. |
| E - Telemetric | Specification quality and traceability are self-maintaining — the requirements layer continuously reconciles against upstream intelligence and downstream delivery signal, surfacing gaps and conflicts without manual audit. PM work shifts from authoring to reviewing AI-surfaced conflicts and ratifying resolutions. | Sustain: verify that the self-maintaining requirements layer is surfacing genuine conflicts rather than generating noise, and that ratification is meaningfully improving on AI-surfaced recommendations. | — |

---

### PM-NATIVE DIMENSIONS / D5–D11 / No SDLC equivalent

#### D5. Prioritization & tradeoffs

**Type:** Model-native | **Note:** See also the AI-Native Product Prioritization Maturity Model (standalone), which elaborates this dimension at sub-dimension depth.

**Definition:** The capability to make and maintain explicit, AI-assisted investment decisions across a contested backlog, with documented tradeoff rationale continuously reconciled against market intelligence, portfolio thresholds, and outcome signals.

| Level | Description | Transition to next level | Verification |
|-------|-------------|--------------------------|---------------|
| A - Nascent | Prioritization is an informal, recurring negotiation — no consistent framework, no documented tradeoff rationale, and no stable authority over who decides. The backlog reflects whoever argued most recently rather than deliberate investment logic. | Name a consistent prioritization method and require documented tradeoff rationale for every contested priority decision. | Any stakeholder can reconstruct why the backlog is ordered the way it is without asking the PM. |
| B - Modeled | Prioritization is a formalized, recurring activity with the elements of a framework and explicit ties to strategy. Formal decision roles exist, but financial expedience is the clear arbiter in contested priorities. | Adopt a consistent prioritization framework with defined decision roles. Require documented tradeoff rationale for every contested priority decision — even when financial expedience is the outcome. | A contested decision from the current cycle has documented tradeoff rationale on file, even where financial expedience was the deciding factor. |
| C - Continuous | Prioritization is a formalized event occurring on a cadence more frequent than release. A strategic prioritization framework accounts for current commitments, technical debt, and aspirational market goals. Decision authority is defined, but not yet tightly linked to budget authority. | Tie decision authority explicitly to budget authority. Require the prioritization framework to account for current D1-D3 market intelligence and D4 requirements state at each cadence. | A prioritization cycle can be shown to have used current D1-D3 intelligence and D4 requirements state, not a stale snapshot from an earlier cycle. |
| D - Integral | Prioritization is a continuous or automatically intervalic activity governed by a constituted framework ratified by key business stakeholders. Current business, market, and customer intelligence actively informs prioritization. Decision authority is explicit and linked to budget authority. | Connect prioritization to D8 (portfolio investment) and D11 (outcome signals) as live inputs. AI should surface prioritization recommendations; the PM function ratifies or overrides with documented reasoning. | An AI-surfaced prioritization recommendation exists for a real decision, with the PM's ratification or override reasoning recorded alongside it. |
| E - Telemetric | Prioritization decisions are AI-assisted, continuously maintained, and fully traceable — every item in the portfolio carries documented tradeoff rationale tied to D1-D3 intelligence, D8 investment thresholds, and D11 outcome signals. PM work shifts from arguing for priorities to ratifying AI-surfaced recommendations and deciding on genuinely novel tradeoffs the model cannot resolve. | Sustain: verify that AI-surfaced prioritization recommendations are improving decision quality, not merely accelerating existing biases. Audit tradeoff rationale periodically for systematic patterns that may indicate model drift or authority creep. | — |

#### D6. Executive engagement & authority

**Type:** Model-native | **Note:** The progression describes consolidation of structural authority. Authority is maintained structurally, not won through ongoing conflict.

**Definition:** The capability to maintain structural authority over portfolio, roadmap, pricing, and release scope decisions through a governed executive interface cadence — where authority is maintained, not negotiated.

| Level | Description | Transition to next level | Verification |
|-------|-------------|--------------------------|---------------|
| A - Nascent | Authority over portfolio, roadmap, pricing, and release scope is diffuse — held informally by whoever has organizational leverage at a given moment (Sales, Finance, Engineering, individual executives). Product Management coordinates rather than decides. | Establish a recurring executive interface cadence with defined agenda, documented decisions, and named PM authority for roadmap and prioritization. | Every roadmap or prioritization decision from the current cadence can be traced to a named owner without asking who made it. |
| B - Modeled | Authority over portfolio, roadmap, pricing, and release scope is guided by Product Management, but ultimate authority continues to be held by senior leadership. The function is no longer whipsawed by peer organizations — Sales, Finance, and Engineering are no longer contesting day-to-day product decisions — but PM operates under ratification rather than independent mandate. | Formalize the scope of PM authority explicitly — document which decisions PM makes independently, which require ratification, and which require approval. | A contested decision can be resolved by referencing the authority document, not by convening a stakeholder meeting. |
| C - Continuous | Authority over portfolio, roadmap, pricing, and release scope is held by Product Management and ratified by senior leadership. PM defines the terms of decisions; leadership approves rather than initiates. The scope of unilateral PM authority is explicit and documented, even where it remains narrow. | Remove ratification requirements from day-to-day portfolio, roadmap, and pricing decisions. Reserve senior leadership engagement for portfolio-level strategic conflicts and fiduciary exceptions. | PM can make and execute a significant roadmap or pricing decision without waiting for an approval cycle. |
| D - Integral | Product Management holds portfolio, roadmap, pricing, and release scope authority on its own terms. Decisions are transparent, documented, and supportable without requiring executive defense. The executive interface cadence governs strategic alignment and exception handling — it is the arena for surfacing conflicts PM cannot resolve unilaterally, not the mechanism by which authority is granted or withheld. | Instrument decision transparency so that the basis for every major PM decision is visible and auditable to executive stakeholders without a dedicated briefing. | The basis for a major PM decision is visible to an executive stakeholder without that stakeholder requesting a dedicated briefing. |
| E - Telemetric | Authority is structurally maintained by the PM function, with AI-assisted transparency making the basis for every major decision visible and auditable to executive stakeholders in real time — executive engagement is no longer about securing permission or defending decisions, but about surfacing strategic conflicts PM cannot resolve unilaterally and ensuring fiduciary alignment at the portfolio level. | Sustain: verify that AI-assisted transparency is genuinely informing executive judgment rather than creating audit theatre. Test periodically whether the executive interface cadence is surfacing real strategic conflicts or smoothing them over. | — |

#### D7. Organizational evangelism & alignment

**Type:** Model-native | **Note:** AI-assisted, not AI-defined. Not every level transition is defined by AI depth — this dimension tracks organizational reach and coherence.

**Definition:** The capability to propagate product direction continuously and at appropriate fidelity across organizational functions — Engineering, GTM, Leadership — and to surface misalignment signals proactively.

| Level | Description | Transition to next level | Verification |
|-------|-------------|--------------------------|---------------|
| A - Nascent | Product direction is communicated reactively and inconsistently — teams learn about roadmap decisions when they affect their work, not in advance. Alignment is achieved through repeated one-on-one conversations rather than any systematic mechanism. | Establish a recurring product direction communication cadence with a consistent format. Define the minimum information Engineering, GTM, and Leadership each need. | Engineering, GTM, and Leadership can each name the current product direction without checking with the PM directly. |
| B - Modeled | Product direction is communicated on a defined cadence using consistent artifacts (e.g., roadmap reviews, all-hands updates, written strategy documents). AI assists in drafting and formatting these artifacts but delivery remains manual and audience-undifferentiated. | Differentiate communication by audience. Engineering, GTM, and Leadership should each receive a rendering of product direction at the fidelity appropriate to their function. | Each audience can act on what they receive without requesting clarification. |
| C - Continuous | Product direction is communicated in audience-differentiated form — Engineering receives specification-level context, GTM receives positioning-level context, Leadership receives portfolio-level context. AI assists in producing these differentiated renderings from shared source artifacts, but the propagation cadence remains event-driven rather than continuous. | Move from event-driven to continuous propagation. Product direction artifacts should update as PM artifacts update. | A material roadmap change propagates to all audiences within a defined timeframe without a manual communication step. |
| D - Integral | Product direction propagation becomes continuous rather than event-driven. AI produces audience-differentiated renderings from the current PM artifact set on an ongoing basis. Misalignment detection remains reactive — teams flag inconsistencies when they surface rather than the system surfacing them proactively. | Add proactive misalignment detection. The system should surface when a team is acting inconsistently with current product direction before that inconsistency becomes a costly handoff failure. | A team's inconsistency with current product direction is flagged by the system before it becomes a costly handoff failure, not after. |
| E - Telemetric | Product direction is continuously and automatically propagated across the organization at appropriate fidelity for each audience — all renderings derived from the same underlying PM artifacts without manual reformulation. Misalignment signals are surfaced proactively rather than discovered at handoff. | Sustain: verify that automated propagation is accurately representing current product direction and that misalignment detection is surfacing genuine signals rather than noise. | — |

#### D8. Portfolio & investment management

**Type:** Model-native | **Note:** Applies in this model because the PM function owns the P&L.

**Definition:** The capability to make start/stop/scale decisions across the product portfolio with explicit AI-assisted investment modeling, continuously reconciled against market intelligence and outcome data.

| Level | Description | Transition to next level | Verification |
|-------|-------------|--------------------------|---------------|
| A - Nascent | Portfolio decisions (start, stop, scale) are made episodically at planning cycles, based on subjective assessment rather than explicit investment models, with no systematic tracking of whether prior portfolio bets produced expected returns. | Establish a consistent investment framework for portfolio decisions. Define what information is required to make a start/stop/scale decision and require that information for every portfolio decision. Begin recording the expected return basis for every portfolio bet. | A portfolio decision from the current planning cycle records the expected return basis it was made against, not just the decision itself. |
| B - Modeled | Portfolio decisions are made at defined planning cycles using a consistent investment framework. AI assists in assembling investment cases and summarizing portfolio state, but decisions are based primarily on qualitative judgment — no systematic tracking of prior portfolio bet outcomes. | Connect the portfolio framework to D1-D3 market intelligence and D4 requirements state as explicit inputs. AI should support scenario modeling across portfolio options. Begin tracking whether prior portfolio bets are producing expected returns. | When an outcome signal materially changes the expected return of a portfolio bet, the portfolio framework surfaces that change without a manual review being triggered. |
| C - Continuous | Portfolio decisions are made using a framework that explicitly incorporates current market intelligence (D1-D3) and requirements state (D4). AI supports scenario modeling across portfolio options. Tracking of prior portfolio bet outcomes begins, but feedback from outcomes into future investment decisions is manual and episodic. | Close the feedback loop from D11 (outcome measurement) into portfolio investment modeling. | An AI-surfaced investment recommendation exists that required only ratification or override, not manual assembly of the underlying case. |
| D - Integral | Portfolio investment decisions are continuously modeled against D1-D3 market intelligence and D5 prioritization signals. Prior outcome data (D11) begins feeding into investment modeling automatically, though investment recommendations are AI-surfaced but require significant human assembly before they are decision-ready. Start/stop/scale triggers are defined but remain calendar-driven rather than signal-driven. | Move start/stop/scale triggers from calendar-driven to signal-driven. AI-surfaced investment recommendations should be decision-ready — the PM function's work shifts from assembling the investment case to ratifying or overriding with documented reasoning. | A start/stop/scale decision can be shown to have been triggered by a signal, not by the arrival of a calendar date. |
| E - Telemetric | Portfolio investment decisions are continuously modeled against D1-D3 market intelligence, D11 outcome data, and D5 prioritization signals — start/stop/scale decisions are triggered by signal rather than calendar, with AI-surfaced investment recommendations that PM ratifies or overrides with documented reasoning. Portfolio health is a standing metric visible to executive stakeholders (D6) without manual assembly. | Sustain: verify that signal-triggered portfolio decisions are preserving strategic coherence and that AI-surfaced recommendations are improving investment quality, not merely accelerating decisions. | — |

#### D9. GTM cadence & market activation

**Type:** Model-native | **Note:** Includes pricing maturity arc.

**Definition:** The capability to continuously move product positioning, pricing, messaging, and provisioning decisions from the PM function to market-facing execution — as a continuously maintained model rather than a launch event.

| Level | Description | Transition to next level | Verification |
|-------|-------------|--------------------------|---------------|
| A - Nascent | GTM execution is episodic and launch-driven — positioning, pricing, and messaging are set at launch, revisited only for major releases, and produced by separate functions (Marketing, Sales, Finance) without a shared PM-owned model driving them. | Establish a GTM cadence tied to release milestones. Define the minimum PM-owned artifacts that drive GTM activation (positioning statement, pricing rationale, messaging brief) and require them for every release. | The positioning statement, pricing rationale, and messaging brief driving the current release all originate from the same PM-owned source, not independently produced by each market-facing function. |
| B - Modeled | GTM execution runs on a defined cadence tied to release milestones. Positioning, pricing, and messaging are updated at each release using a consistent AI-assisted process. Market-facing functions are briefed from PM-owned artifacts, but produce their own renderings independently. | Build a shared PM-owned model that drives positioning, pricing, and messaging across all market-facing functions from the same source. | A competitive move triggers a GTM model update without requiring a new release. |
| C - Continuous | A shared PM-owned model drives positioning, pricing, and messaging across market-facing functions. AI assists in producing function-specific renderings (Sales battlecards, Marketing messaging briefs, pricing rationale) from the shared model. GTM updates remain milestone-triggered rather than continuous. | Move from milestone-triggered to signal-responsive GTM. The shared model should begin updating in response to D1-D3 intelligence signals rather than only at release boundaries. | Pricing has been reviewed and updated in response to a market signal since the last release, not only at the release boundary itself. |
| D - Integral | GTM activation becomes push/pull rather than milestone-triggered. Pricing intelligence is continuously available and informs GTM positioning on a formalized but ongoing basis — pricing is no longer set once per release but reviewed and updated in response to market signals on a defined cadence. Market-facing functions can pull current positioning, pricing, and messaging from the shared model on demand, or receive pushed updates when material signals trigger a GTM review. | Move from formalized continuous pricing review to near-real-time pricing response. Eliminate the remaining dependency on a defined cadence — GTM model updates should be triggered by D1-D3 signals and D11 outcome data directly, without a human scheduling a review. | A GTM model update can be shown to have been triggered directly by a D1-D3 signal or D11 outcome data, without a human scheduling the review that produced it. |
| E - Telemetric | Positioning, pricing, messaging, and provisioning are continuously maintained by a shared AI-driven model fed by D1-D3 intelligence and D11 outcome data — market-facing functions consume function-specific renderings from the same underlying model rather than commissioning separate work. Pricing responds to competitive signals and willingness-to-pay data in near-real-time. GTM activation for a new capability is not a launch event but a continuous adjustment. | Sustain: verify that continuous GTM activation is preserving positioning coherence across all market-facing functions and that near-real-time pricing is improving revenue outcomes without eroding market trust. | — |

#### D10. Experimentation & validation

**Type:** Model-native | **Note:** Subsumption principle — at Level E, this activity is subsumed into the main delivery and feedback cycle. Level E is not better prototyping — it is the disappearance of the prototype track as a distinct practice.

**Definition:** The capability to define hypotheses, design MVPs/increments, validate against market signals, and close the learning loop back to requirements and portfolio decisions.

| Level | Description | Transition to next level | Verification |
|-------|-------------|--------------------------|---------------|
| A - Nascent | Prototyping and market validation are ad hoc — initiated informally when someone decides they are needed, not connected to a systematic hypothesis framework, and producing findings that are rarely captured in a form that feeds back into requirements or portfolio decisions. | Establish a hypothesis documentation standard for all prototyping and market validation work. Every experiment should state its hypothesis, success criteria, and intended destination (which D4 requirement or D8 portfolio decision it is intended to inform) before it begins. | A prototyping or validation effort in flight has a stated hypothesis, success criteria, and intended destination on record before it concludes, not reconstructed after the fact. |
| B - Modeled | Prototyping and market validation run on a defined process with explicit hypothesis documentation. AI assists in synthesizing validation findings and comparing outcomes against hypotheses. The parallel track remains clearly separate from production delivery — findings must be manually reformulated into D4 requirements before engineering can act on them. | Connect validation findings directly to D4 (requirements) without manual reformulation. AI should assist in translating validated hypotheses into specification-ready form. | A validated hypothesis can move into engineering without a separate requirements-authoring step. |
| C - Continuous | The parallel prototype track is formally integrated with the main delivery cycle — validated hypotheses flow directly into D4 (requirements) without manual reformulation, and the prioritization framework (D5) treats validation findings as first-class inputs. AI assists in accelerating prototype construction and synthesizing market signals. The parallel track remains distinct but its output latency is visibly shorter than at Level B. | Reduce the cycle time of the parallel track until it approaches the cadence of the main delivery cycle. | The elapsed time from hypothesis to validated finding is measured and trending toward the main delivery cycle time. |
| D - Integral | The velocity of the parallel prototype track matches or approaches the main delivery cycle — at this level the distinction between prototype and production-ready begins to dissolve as a practical matter. When a hypothesis is validated, the prototype artifact is often production-worthy by the time validation is complete, and the decision of whether to promote it or discard it is a product decision, not a technical one. The parallel track still exists as a named practice, but its output is indistinguishable in quality and cadence from the main track. | Remove the named distinction between the prototype track and the main delivery cycle. At Level E, hypotheses enter D4 (requirements) directly — there is no separate prototype intake path. | The organization cannot point to a prototype environment or a validation sprint as distinct from its normal delivery motion. |
| E - Telemetric | The experimentation and validation activity has been subsumed into the main delivery and feedback cycle — there is no separate prototype track. A well-formed hypothesis enters D4 (requirements), moves through D5 (prioritization), ships, and is validated by D11 (outcome measurement) within the same cycle time D12 measures. | Sustain: verify that the subsumption of the parallel track is a consequence of cycle time maturity and not a result of abandoning validation discipline. Hypotheses are still being formally stated and evaluated — they are simply moving through the main track rather than a parallel one. | — |

#### D11. Analytics & outcome measurement

**Type:** Model-native | **Note:** This is the PM-function view of instrumentation — product outcome measurement, not delivery-system observability (that is SDLC's own D12). Failure classification vocabulary at Level D is borrowed from the AI-Native Product Prioritization Maturity Model.

**Definition:** The capability to continuously measure whether PM decisions are producing intended results — revenue impact, adoption, retention, customer satisfaction — and feed those signals back into upstream dimensions as a closed loop.

| Level | Description | Transition to next level | Verification |
|-------|-------------|--------------------------|---------------|
| A - Nascent | Outcome measurement is retrospective and anecdotal — success is assessed informally after the fact, based on revenue reports or customer complaints rather than instrumented product signals. The PM function has no standing view of whether its decisions are producing intended results. | For every material prioritization decision, record the expected outcome, measure, owner, and review date before commitment. | The PM function can state what success looks like for every item in the active portfolio — before delivery, not after. |
| B - Modeled | Major initiatives receive scheduled outcome reviews. AI assists in assembling outcome data and comparing realized results against original hypotheses. Outcome measurement is initiative-scoped — there is no standing view of portfolio-level outcome performance, and findings do not automatically feed back into D1 or D5. | Extend outcome tracking to all material decisions, not only major initiatives. Establish a benefits register and require scheduled outcome reviews for every tracked decision. | A benefits register entry exists for a material decision outside the initiative-scoped set that previously would have gone untracked. |
| C - Continuous | Outcome measurement is systematic and covers all material prioritization decisions, not only major initiatives. A benefits register links each decision to its expected outcome, measure, owner, and review date. AI assembles outcome evidence packages at scheduled review points. Findings are manually surfaced to D5 and D8 — the feedback is present but not automatic. | Automate outcome anomaly detection. AI should surface results diverging materially from expectations without waiting for a scheduled review. | An outcome anomaly is surfaced by the system before a scheduled review would have caught it. |
| D - Integral | Outcome measurement operates continuously rather than at scheduled review points. AI surfaces outcome anomalies without waiting for a scheduled review. Findings begin feeding automatically into D5 and D8, though the connection to D1 (market discovery model recalibration) remains manual. The PM function can distinguish execution failure from forecast error at this level, but cannot yet systematically distinguish model error or intent failure. | Close the full outcome feedback loop to D1 (market discovery). The PM function should be able to distinguish all four failure classes (execution failure, forecast error, model error, possible intent failure) and route each to its correct correction path. | The PM function's own account of a miss names one of the four specific failure classes, not a generic "execution" catch-all. |
| E - Telemetric | Outcome measurement is a continuously operating, AI-assisted feedback layer — revenue impact, adoption, retention, customer satisfaction, and competitive response are instrumented and visible in real time, feeding back automatically into D1, D5, D8, and D9. The PM function can distinguish all four failure classes and routes each to its correct correction path. PM analytical work shifts from assembling outcome data to interpreting AI-surfaced anomalies and deciding on responses the model cannot resolve. | Sustain: verify that the continuous outcome measurement layer is surfacing genuine anomalies rather than generating noise, and that the four-way failure classification is being applied rigorously rather than defaulting to execution failure as the catch-all explanation. | — |

---

### SYSTEM VELOCITY / D12 / S0 echo / Virtually identical to SDLC D13

#### D12. Feedback loop velocity

**Type:** Model-native (virtually identical in shape to SDLC's D13) | **Note:** PDLC's measurement frame is the full PDLC chain (D1–D11) rather than the engineering delivery chain. S0 echo: slow feedback is an existential threat; fast feedback is a going-concern advantage.

**Definition:** The end-to-end cycle time from signal — market, user, outcome, competitive — to shipped and validated response, as a property of the whole PM system rather than any individual stage.

| Level | Description | Transition to next level | Verification |
|-------|-------------|--------------------------|---------------|
| A - Nascent | End-to-end cycle time from signal to shipped response is unmeasured and dominated by handoffs between disconnected stages and teams. The organization cannot say how long it takes to respond to a market shift, a competitive move, or a customer outcome signal. | Instrument end-to-end cycle time across the D1-D11 chain. Define what counts as a signal (market shift, competitive move, outcome data point, customer feedback escalation), what counts as a shipped response, and begin measuring elapsed time between them. | The organization can state, in a specific unit of time, how long it took to respond to the most recent market shift or competitive move. |
| B - Modeled | Cycle time is measured retrospectively for major releases or strategic pivots, but is not tracked continuously and is not used to identify which handoff in the PM chain is the current bottleneck. | Move from retrospective measurement to continuous tracking. Cycle time should be a standing metric, broken down by stage and handoff across the D1-D11 chain, so the organization can identify which handoff currently dominates total cycle time. | Cycle time is reported as a standing metric broken down by stage and handoff, not recomputed specially when someone asks. |
| C - Continuous | Cycle time is tracked continuously as a standing metric, broken down by stage and handoff across the D1-D11 chain — the organization can identify which handoff currently dominates total cycle time, though addressing it requires separate prioritization and planning work. | Make bottleneck resolution a routine prioritization input. When D12's measurement identifies a dominant handoff bottleneck, closing it via the relevant dimension's next maturity step should be treated as comparable in priority to feature work. | A bottleneck D12 identified has a corresponding prioritized work item addressing it, not just a measurement sitting unacted on. |
| D - Integral | Improving cycle time is a routine input to prioritization across D1-D11 — when D12'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. | Compress cycle time to days-not-months on the dominant signal types. Verify that D10's experimentation and validation activity is beginning to merge with the main delivery cycle — the parallel prototype track should be visibly shrinking as a distinct practice. | A dominant bottleneck closes within a days-not-months window, not the months-long cadence the organization operated on previously. |
| E - Telemetric | End-to-end cycle time is short enough to be a competitive differentiator, operating on a days-not-months cadence. At this level, D10's experimentation and validation activity has been subsumed: a validated idea is no longer a parallel-track activity but a property of the cycle itself. | Sustain: verify that cycle time compression is preserving strategic coherence and human authority rather than amplifying speed at the cost of governance. Audit whether the D10 subsumption is complete — its disappearance should be a consequence of cycle time maturity, not a result of abandoning validation discipline. | — |


---

## AI-Native Product Prioritization Maturity Model

# AI-Native Product Prioritization Maturity Model — Matrix

**Version 1.2.0 — 2026-07-28** (Per-Dimension Deep-Dive essays added in `deep_dives/` for all three dimensions — narrative content, no change to this matrix. v1.1.1 fixed a header-label bug — each table declared a phantom "Dimension-specific state" column that never had distinct data; removed, no content affected. v1.1.0 added per-transition verification clauses for D1–D3, matching the family's own precedent — SDLC's D4–D13 and PDLC's D4–D12 each carry an explicit test of whether the destination state was actually reached, not just claimed. See `CHANGELOG.md`. Locked baseline remains v1.0.0 — 2026-07-28, unchanged below.)

This model appraises an organization's product prioritization capability — not the elegance of a single scorecard or roadmap decision. It has three dimensions, each independently scored on the same family-wide five-level ladder (A–E) as every other model in this family, but each dimension's own state descriptions, evidence, and transitions are specific to prioritization — they are not shared with or inherited from the SDLC or PDLC models, whose own D1–D3 cover market/persona/positioning intelligence, a genuinely different capability.

**This markdown document is the source of truth.** `AI_Native_Product_Prioritization_Maturity_Model_v1.0.xlsx`, retained in the SDLC repo, is the historical working draft this document was transcribed from — not a distribution rendering of it.

## Purpose

Level A is the least mature state; Level E is the most mature. Each step describes a realistically adjacent operating state specific to the dimension.

## AI-native design rule

AI use does not increase maturity by itself. It increases maturity only when it improves evidence quality, decision coherence, traceability, calibration, or adaptation without obscuring authority or converting inference into fact. The model therefore moves from incidental AI use, to governed participation, to independent challenge, and finally to closed-loop learning.

## The three dimensions

| ID | Dimension | Core question |
|---|---|---|
| D1 | Value Model Coherence | Is product value explicit, multi-dimensional, defensible, and usable by governed human and AI participants? |
| D2 | Decision Governance & Portfolio Integration | Do those value judgments govern real funding, capacity, sequencing, and trade-offs, with explicit human and AI authority? |
| D3 | Outcome Calibration & Adaptation | Does realized evidence improve forecasts, the value model, portfolio decisions, and — when warranted — the originating intent? |

### 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, and Prioritization):

| Letter | Name |
|---|---|
| A | **Nascent** |
| B | **Modeled** |
| C | **Continuous** |
| D | **Integral** |
| E | **Telemetric** |

## The governing loop

Enterprise intent → D1 value model → D2 portfolio decision → execution and outcomes → D3 calibration → portfolio/model correction → reconsideration of enterprise intent when the evidence indicates possible intent failure.

D3-E is the capstone: it distinguishes execution failure, forecasting error, model error, and possible intent failure, then routes each to its proper authority.

| Failure class | What failed? | Primary correction | AI-native contribution | Authority |
|---|---|---|---|---|
| Execution failure | The work did not realize an otherwise sound hypothesis. | Correct delivery, sequencing, capability, or implementation. | Detect variance and assemble evidence without rewriting the original hypothesis. | Delivery / portfolio authority |
| Forecast error | The value, effort, timing, or risk estimate was wrong. | Calibrate scoring anchors, confidence, and forecasting method. | Identify systematic bias by criterion, team, product area, or investment type. | Model owner / portfolio governance |
| Model error | The prioritization model omitted, duplicated, or misweighted a material factor. | Revise criteria, weights, evidence standards, or governance. | Detect model drift and propose explainable changes with preserved provenance. | Value-model authority |
| Possible intent failure | The decision and model may be working against stale, incoherent, or incorrect enterprise intent. | Reconsider originating intent through its proper constitutional authority. | Surface the pattern and evidence; never silently redefine intent. | Enterprise intent authority |

AI does not own the loop. It keeps the evidence, alternatives, consequences, and learning continuously available and governable. Human authority remains explicit at every correction point, especially when the evidence reaches back to the organization's originating intent.

## The 2015 Strategic Value Matrix

Authored by David Facer, predating this model by over a decade, the Strategic Value Matrix is the reference pattern for Level E Value Model Coherence: explicit multi-factor value logic, visible weights, and explainable trade-offs. Overall Level E still requires comparable maturity in decision governance and closed-loop intent calibration.

## How to read this matrix

Each dimension below has a definition followed by a five-level maturity ladder (A through E). A given level is not inherently good or bad; score the normal operating capability — not the best team, workshop, artifact, or AI demonstration.

Dimensions are independently scored — an organization can be advanced in one dimension and nascent in another. Treat the three-grade profile as authoritative; the overall grade is only a directional summary. Prefer proximate improvement: use the current level's transition statement as the next design target, not a longer-range one.

Each level is followed by its transition, indicative evidence, and a verification clause — a practical test of whether the destination state was actually reached, not just claimed. Level E is followed by a sustainment note instead of a further transition, since there is no Level F.

---

### D1. Value Model Coherence

**Definition:** The capability to define and maintain an explicit model of product value that makes unlike drivers comparable without collapsing them — including strategic, customer, market, economic, architectural, delivery, risk, and debt considerations. AI becomes relevant only when it can use, challenge, or help improve that governed model.

| Level | Maturity definition | Indicative evidence | Transition to next level | Verification |
|-------|--------------------------|--------------------------|--------------------------|---------------|
| A - Nascent | Priority is determined mainly by advocacy, urgency, executive request, anecdote, or estimated effort. Individuals may use AI privately to draft business cases or make a preferred item sound more compelling, but there is no stable value model against which the output can be tested. | Roadmaps built from requests; inconsistent rationale; private AI-generated business cases; value and effort discussed as one undifferentiated judgment. | Name a small common set of criteria, separate value from implementation difficulty, and require the same logic for every candidate. | A prioritization decision from the current cycle can point to a documented value score, not just an argued case. |
| B - Modeled | A common prioritization method is used — such as value-versus-effort, RICE, MoSCoW, or a simple weighted score. AI may summarize proposals, normalize submissions, or collect preliminary evidence, but criteria remain generic, scoring anchors are weak, and humans manually translate AI output into the model. | Reusable scorecard; simple ranking; AI-assisted proposal summaries; shared criteria with limited definitions; workshop-dependent interpretation. | Define dimension-specific criteria and scoring anchors, state the evidence expected for material scores, and preserve source provenance. | Two different scorers, using the same criteria and evidence, arrive at materially the same score for the same candidate. |
| C - Continuous | The organization uses a shared product-value model with distinct scoring dimensions, defined scales, and explicit separation of business value from implementation difficulty. The model is structured enough that AI can map proposals to criteria, assemble cited evidence, identify missing inputs, and flag inconsistent scoring. Humans retain responsibility for weights and final value judgment. | Defined scales and weights; separate business-value and implementation factors; machine-readable scoring structure; cited evidence; AI-flagged gaps or inconsistencies. | Assign formal ownership, version the model, test criteria for overlap or double-counting, and make assumptions, confidence, and exceptions visible. | A ranking change can be explained by pointing to a specific, named criterion or assumption shift, not general judgment. |
| D - Integral | The value model is formally owned, versioned, and tied to current strategy and portfolio context. AI performs scenario and sensitivity analysis, challenges unsupported assumptions, detects likely double-counting or scoring drift, and explains why rankings change. The model, weights, evidence standards, and decision authority remain human-governed. | Model owner; version history; criterion provenance; AI-supported sensitivity analysis; confidence notes; scoring-drift review; documented exceptions. | Connect the value model to realized outcomes so evidence can recalibrate scoring anchors, weights, and strategic assumptions. | A completed portfolio bet's realized outcome has been fed back into a scoring anchor or weight, visible in the model's own version history. |
| E - Telemetric | A multi-factor strategic value system — of the kind represented by the Strategic Value Matrix — balances revenue magnitude and velocity, strategic alignment, market and customer fit, architecture, implementation size, technical-debt reduction, and delivery risk through explicit scales and weights. AI continuously refreshes relevant evidence, detects model or strategy drift, and proposes changes to criteria, anchors, or weights. Every change remains explainable, versioned, and human-authorized, and the organization can reconstruct why one item outranked another at any point in time. | Governed strategic value matrix; transparent positive and negative drivers; continuously refreshed evidence; explainable scenarios; model-drift detection; preserved decision history. | Sustain empirical and strategic integrity: verify that evidence refresh improves the model without allowing automation, recency, or persuasive inference to redefine value silently. | — |

### D2. Decision Governance & Portfolio Integration

**Definition:** The capability to turn value judgments into transparent, authoritative portfolio choices that account for funding, capacity, dependencies, sequencing, exceptions, and displacement of other work. AI becomes relevant only when its role, evidence obligations, and authority limits are explicit.

| Level | Maturity definition | Indicative evidence | Transition to next level | Verification |
|-------|--------------------------|--------------------------|--------------------------|---------------|
| A - Nascent | Prioritization is a series of local decisions made by the loudest stakeholder, highest-ranking executive, or most urgent customer request. AI may be used privately to strengthen advocacy, but its evidence, reasoning, and influence are invisible. There is no stable decision forum, no visible displacement of other work, and little distinction between recommending, approving, and committing. | Unrecorded overrides; backlog churn; private AI-generated narratives; urgent work inserted without explicit trade-off; no portfolio-level decision record. | Create a recurring decision forum and name who proposes, challenges, decides, records, and commits the outcome. | A record exists naming who proposed, decided, and committed the most recent contested priority — not reconstructed from memory afterward. |
| B - Modeled | A scorecard or ranking is used in recurring prioritization meetings, and decisions are documented. AI may prepare summaries, compare proposals, expose obvious conflicts, or record rationale, but it has no governed role and lacks complete access to capacity, funding, dependencies, sequencing, and portfolio context. Executives may still override the result without a standard exception path. | Recurring workshop; ranked list; AI-generated meeting preparation; documented decisions; limited constraint analysis; informal overrides. | Define decision rights, an exception path, the portfolio constraints that must be applied, and the specific AI role in evidence assembly and analysis. | A decision from the current cycle names the specific AI role that produced it (evidence assembly, dependency check), distinct from the human who made the call. |
| C - Continuous | Scoring, challenge, approval, exception, and commitment are distinct and traceable. AI roles and limits are explicit: AI assembles evidence, checks candidate completeness, verifies dependencies and capacity constraints, and records provenance; named humans make consequential decisions. Funding, sequencing, risk, and portfolio balance constrain the ranked list, and the result directly governs committed work within a portfolio. | Decision log; named authorities; governed AI role; evidence provenance; capacity plan; dependency view; exception record; roadmap traceability. | Extend the same decision system across Product, Engineering, Architecture, Finance, and go-to-market portfolios, with common scenario semantics. | A cross-functional scenario exists showing what a single investment displaces or puts at risk elsewhere in the portfolio, not just its own standalone case. |
| D - Integral | A shared prioritization system operates across functions and product areas. AI traverses product, engineering, architecture, finance, customer, and go-to-market evidence to model displacement and second-order effects. Independent analysis can challenge the originating proposal and show what is delayed, unfunded, or made riskier when one investment advances. Humans govern the scenarios, thresholds, and final commitments. | Cross-portfolio scenarios; integrated funding and capacity views; AI-supported displacement analysis; independent challenge; architecture and dependency impacts. | Reduce the latency between material evidence changes and governed reconsideration while preserving authority, evidence, and exception discipline. | A material evidence change triggered a reconsideration of a portfolio decision without waiting for the next scheduled cycle. |
| E - Telemetric | Prioritization operates as a standing management system rather than an episodic workshop. New demand enters through a known path; comparable evidence is assembled; alternatives are challenged; and capacity, funding, dependencies, sequencing, and portfolio balance are resolved continuously. AI monitors material changes, maintains decision-ready scenarios, and initiates governed reconsideration. Routine low-consequence actions may be delegated within explicit authority, while consequential portfolio choices remain visibly human-owned. | Governed intake-to-commit flow; live portfolio scenarios; event-driven reconsideration; bounded AI authority; rapid but traceable continue, pause, stop, accelerate, and reallocate decisions. | Continuously test whether adaptive speed is preserving strategic coherence and constitutional authority rather than amplifying short-term noise. | — |

### D3. Outcome Calibration & Adaptation

**Definition:** The capability to compare predicted value, effort, timing, and risk with realized outcomes; distinguish execution, forecast, model, and intent failure; and return the findings to the portfolio, value model, and — when warranted — the originating enterprise intent.

| Level | Maturity definition | Indicative evidence | Transition to next level | Verification |
|-------|--------------------------|--------------------------|--------------------------|---------------|
| A - Nascent | Once work is approved, the prioritization decision is rarely revisited. Delivery may be tracked, and AI may summarize results after the fact, but the original value hypothesis, evidence, assumptions, and intended outcome are not preserved well enough to determine whether the decision was right. | Shipped equals successful; no benefits review; no record of original assumptions; post-hoc AI summaries without a comparison baseline. | For every material decision, preserve the expected outcome, measure, owner, review date, underlying value hypothesis, and originating intent. | A completed initiative has an after-action review on file comparing planned versus actual outcome, not just delivery status. |
| B - Modeled | Major initiatives receive occasional after-action review. AI helps synthesize retrospectives and compare planned versus actual effort, timing, or selected business outcomes, but the analysis is episodic and selective. Lessons usually affect the next project informally rather than changing the prioritization model or portfolio. | Project retrospectives; AI-assisted synthesis; planned-versus-actual delivery review; informal benefits discussion; isolated lessons. | Require consistent outcome hypotheses and scheduled reviews, and link realized evidence back to the original decision rather than only to delivery performance. | A material decision outside the initiative-scoped set has a benefits-register entry naming its expected outcome, owner, and review date. |
| C - Continuous | Material prioritization decisions carry explicit expected outcomes, measures, timing, ownership, value hypotheses, and originating intent. AI connects the original decision to subsequent customer, market, financial, delivery, architectural, debt, and risk evidence, flags material variance, and keeps verified evidence, reported information, assumptions, and inference visibly distinct. | Benefits register; decision-to-outcome traceability; named outcome owner; AI-assembled evidence package; forecast-versus-actual review; model-change log. | Measure forecast accuracy and recurring bias by criterion, investment type, product area, and decision team, using independent analysis where practical. | A specific, named bias (by criterion, team, or product area) has been identified and used to adjust a scoring anchor or confidence range. |
| D - Integral | AI identifies where the organization systematically overstates value, understates effort, misses timing, discounts risk, or misreads evidence. Forecast accuracy and bias are measured by criterion, team, product area, and investment type. Scoring anchors, confidence ranges, weights, and governance practices are adjusted empirically, and continue, expand, pause, or stop decisions occur before all planned investment is consumed. | Bias analysis; criterion calibration; confidence ranges; independent AI review; stage decisions; evidence-based model revisions; preserved decision lineage. | Close the loop to enterprise intent: distinguish execution failure, forecast error, model error, and possible intent failure, then route each to its proper authority. | A recent miss has been classified into one of the four named failure classes, with the correction routed to that class's own proper authority, not defaulted to "execution failure." |
| E - Telemetric | Product prioritization operates as a continuous learning loop. Customer, market, financial, delivery, architectural, debt, and risk evidence is traced back to the original value hypothesis and the intent it served. AI assistance detects variance, systematic bias, model drift, and emerging opportunity while work is still underway, distinguishing execution failure from forecasting error, model error, and possible intent failure. The portfolio, prioritization model, and — when warranted — the originating intent can each be reconsidered through their proper authority, without losing decision lineage or converting inference into fact. | Continuous outcome signals; intent-to-decision-to-outcome traceability; failure-class diagnosis; model-drift checks; early continue, pause, stop, or redirect decisions; preserved evidence and authority lineage. | Sustain epistemic and constitutional discipline: ensure the loop can challenge intent without allowing AI inference to silently become enterprise intent. | — |


---

## Strata — the governance-layer model (S0–S7)

AI coding agents need a disciplined conceptual world that defines what kinds of things may exist, where they belong, what intent they realize, and what authority allows them to act. Type it, locate it, and resolve what it's for — before it acts, not after.

### S0. Intent — Why the practice exists

The originating motivation for the practice — ineffable until it's actually elucidated. Not itself a governed artifact until expressed; everything below exists in service of it. Intent is also not a label attached to architecture afterward: every valid governed thing must resolve to the Intent it exists to realize.

### S1. Fundamentum — Principles, constraints, and charters

The first governed expression of Intent. Principles and foundational constraints that rarely change, together with the charters defining what actors — including AI colleagues — are authorized to do. These are generated from Intent, not selected independently and rationalized afterward.

### S2. Normae — Adopted frameworks, standards, and maturity models

The standards against which the practice chooses to govern or measure itself. Adopted, not generated from first principles — selected because they serve the Intent and Fundamentum already established. The AI-Native maturity models in this family are examples; TOGAF® is another. A standard can therefore be entirely legitimate and still be wrong for a practice, if it doesn't serve that practice's Intent.

### S3. Vocabula — Shared language: ontology, taxonomy, lexicon, semantics

The shared language that makes governance checkable — what the practice means by a term, what kinds of entities exist, how they're classified, and which distinctions must stay distinct. This is what lets a human and an AI system inspect the same governed record and recognize the same kind of thing. Without it, governance stays dependent on interpretation.

### S4. Corpus — The governed record

The official archive of the practice. Corpus answers what is part of the record. It does not answer what is in force — a document can sit in the Corpus without possessing authority. Membership establishes that something belongs to the governed record; it doesn't enact, approve, or operationalize what the artifact says. Recorded is not the same as authorized.

### S5. Auctoritas — Authorization, contracts, and briefs

The machinery by which governed work becomes sanctioned — where permission becomes real. A draft authorization is not authorization merely because its text says "approved"; the constitutive act, issuance by the proper authority, is what changes its status. This is the difference between a record describing authority and authority actually having been exercised.

### S6. Operationes — Live systems, tools, and execution

The running practice: systems execute, tools act, processes run, agents perform work, and authorized decisions affect the world. Correct placement here does not itself authorize an action — a system can be well described, correctly classified, and traceable to Intent while still lacking authority for a particular consequential act. Well-formed is not the same as permitted.

### S7. Observatio — Reports, gaps, results, feedback

What operation teaches the practice — the evidence produced when architecture meets reality: results, exceptions, failures, measurements, gaps, and lessons. Those observations may justify changes elsewhere in the governed world, and at the deepest level may challenge the Intent the practice set out to realize. That is where feedback closes the loop.

**S2/Normae, concretely:** the AI-Native SDLC Maturity Model above is itself an instance of this layer — an external standard this practice measures itself against, adopted rather than generated. TOGAF® is another. Recognizing that placement is exactly the discipline instructions S1–S4 ask of you for your own proposed work.

**Fiber and feedback are different.** The intent fiber is not a loop — it is present throughout every valid descent from S0 to S7; a governed thing without a resolved intent reference is ill-typed at any stratum, not just at the ends. Feedback is a separate, additional claim: S7 (Observatio) returns findings to S0 (Intent) so that intent itself can be reconsidered — closing a loop the fiber's own presence doesn't by itself require. A stratum can carry the fiber correctly with no feedback event having happened yet; feedback, when it does happen, still has to carry its own resolved intent reference to be real, the same as everything else.

---

## Enterprise Architecture OKF

The governed schema every model in this family is written in — an Ontology, Lexicon, and Taxonomy for running a technology practice with the help of AI colleagues, precise enough that both a human and an AI system recognize exactly what they're looking at.

## A corpus, not a wiki

At the center of it sits the Corpus: one official archive, not a loose collection of documents that happen to be true. Everything inside the Corpus is part of the governed record, but corpus membership alone does not place an artifact in force — authority arises through the applicable issuance or authorization mechanism (Auctoritas). Everything outside the Corpus — notes, drafts, working files — is evidence: useful, but not part of the governed record at all. That distinction is what keeps a growing body of decisions from quietly drifting out of sync with what a practice actually does.

## What it actually holds

A small number of entity kinds, kept cleanly separated: the Intent a practice exists to serve; Principles and Constraints that rarely change; named Standards the practice measures itself against (this is exactly where a maturity model like the ones in this family lives); Decision Records for choices already made, so they aren't re-litigated; Work Packages with a clear scope and owner; Authorizations — formal, constitutive acts by which a human owner sanctions specific work; the Systems and Operations doing the actual work day to day; and Observations, the feedback that sharpens Intent over time as those systems actually run.

## Where the models in this family stand

EA OKF is the schema this family is written in — not itself one of the models, the ground they all stand on. Each model is the actual product: a named Standard, expressed as structured, machine-readable governance rather than a one-off document, using exactly this schema underneath. [Strata](/strata) is the structure explaining how they relate to each other once they're in place.

---

## Function Models

Flat, ontological maps of what a function actually consists of — inputs, activities, capabilities, enabling substrates, and outputs. Unlike the maturity models above, a Function Model doesn't measure AI-nativity or progression; it names what the function is, independent of how well any organization currently does it. Three entries today; more are planned.

## Product Management Function Model

Product management turns market, user, and business inputs into product decisions and outcomes. A governed system of activities, capabilities, and tools — this is a function model, not a process nor a lifecycle — inputs to outputs.

### Function, Process, and Lifecycle

Most experienced product executives can feel when product management is working and when it's fragmented. It can be difficult to articulate why. The usual answers reach for process maturity or tooling — which is an overcomplication.

PMs are taught sprints, ceremonies, and cadences without knowing the layer beneath. They get the verbs without the nouns.

The product management function can be represented at three levels, and each answers a different question:

- **Function model:** flat and structural. What must exist: inputs, activities, capabilities, outputs. No sequence, no arrows. A trigger presumes a time axis, and this layer has none.
- **Process:** a linear path through part of the function. The function model is the dictionary; a process is a sentence built from it.
- **Lifecycle:** the function projected onto time, derived from the processes that form the flywheel of a practice.

Most organizations struggle to adopt lifecycles before they understand the function.

In short:

- **The function model:** is a flat, ontological form; what the function is and what it does.
- **Processes:** are linear renderings of portions of the function.
- **A lifecycle:** is an approximate rendering of the function in motion. That's what it looks like when it's running.

This page represents the first layer only. Nothing here is missing an arrow. Arrows belong to a different diagram, answering a different question.


### Inputs

- Organizational strategy
- Market targets
- Revenue requirements
- **Market intelligence:** Competitor data, Buyer intelligence, Customer/user insights, Analyst insights

### Product Management Function

**Activities** (What the PM does all day):

- Define Markets
- Requirements Management
- Prioritization & Tradeoffs
- Engineering Interface Cadence
- Executive Interface Cadence
- Organizational Evangelism
- Product Portfolio Alignment Cadence
- GTM Cadence
- Experimentation & Validation
- User/Customer/Analyst Meetings

**Capabilities** (What the PM is good at):

- **Market intimacy** — Customer/Buyer Engagement, User Intimacy, Market/Analyst Engagement. *Deep knowledge of markets, customers, users & analysts.*
- **Persona generation** — User Personas, Buyer Personas, Delivery & Support Personas. *Structured archetypes for effective PDLC and key stakeholder groups.*
- **Strategic Analysis** — *Beat competitors — cheaper, faster, higher quality.*
- **Requirements Articulation**
- **Executive Engagement** — *Where authority over portfolio, prioritization, roadmap, pricing & scope is maintained.*
- Pricing · Market positioning

**Enabling substrates:**

- **Tools:** RMS / ALM / Engineering Collaboration Tools, Document & Presentation Tools, Design & UI Tools, GTM & MarCom Tools, Analytics & Outcomes & Market Measurement Tools.
- **Governance:** Stage-gate reviews, OKR cadence, Compliance & risk review.
- **Resources:** PMs, Designers, Engineers, Data analysts, GTM stakeholders. *Resources execute the function, but do not define it.*
- **Standards:** Agile / SAFe / dual-track discovery, Data privacy, Accessibility.

### Outputs

- **Engineering & delivery** (What engineering needs to know what to build): Requirements, Prioritization, Release goals
- **GTM & market-facing** (What sales and the market need to price, position, and sell): Positioning & Pricing, Market messaging, Provisioning & Billing Plans, Buyer Personas & Battlecards
- **Operations** (What operations needs to keep customers happy and paying): Support materials & training, User feedback mechanism
- **Leadership & governance** (What leadership needs for cadence, fiduciary duty & alignment): Product strategy, Executive transparency

---

## Product Marketing Function Model

A bounded corollary to the Product Management function — focused on market translation, launch communication, and field enablement.

### Inputs

- **Product Management Direction:** Product strategy, roadmap, release intent, requirements context, positioning, pricing & packaging guidance.
- **Market & Buyer Context:** Target segments, buyer personas, use cases, market context.
- **Competitive & Commercial Evidence:** Objections, win/loss patterns, competitor moves, sales feedback, market reactions.
- **Customer Evidence:** Adoption themes, support issues, customer questions, expansion signals.
- **Governance & Constraints:** Brand, legal, claims, messaging standards.

### Product Marketing Function

Product Marketing governs product meaning at the enterprise boundary.

**Activities** (What we repeatedly do):

- Interpret Product for the Market
- Translate Positioning into Messaging
- Create Product Narratives, Proof & Launch Assets
- Equip Sales, Partners & Customer Success
- Coordinate Market Introduction & Launch Readiness
- Monitor Market Response & Feed Back to Product Management

**Capabilities** (What we must be good at):

- **Messaging Architecture**
- **Sales & Partner Enablement**
- **Launch Communication**
- **Product Content & Proof Strategy**
- **Customer Adoption Communication**
- **Market-Response Learning**

**Enabling substrates:**

- **People & Resources:** Skilled product marketers, Cross-functional partners, Advisory network, Adequate capacity.
- **Tools & Data:** Market intelligence, Content & asset tools, Analytics & listening, CRM & usage data.
- **Governance:** Decision rights, Review & approval, Feedback loops, Compliance guardrails.
- **Standards & Definitions:** Messaging framework, Asset taxonomy, Launch checklist, Success metrics.

### Outputs

- **To Demand Generation**: Campaign inputs, Launch themes, Messaging assets, Product proof
- **To Sales & Partners**: Battlecards, Objection handling, Product decks, Enablement materials
- **To Customer Success**: Release communications, Adoption assets, Customer education materials
- **To Product Management**: Message resonance, Objection patterns, Adoption barriers, Unmet needs
- **To Leadership**: Launch readiness, Market pulse, Product-market narrative

### Boundary Note

- Product Management retains positioning, pricing, packaging, and release-goal authority.
- Product Marketing translates and operationalizes that guidance for the market and the field.
- Sales owns commercial commitment.
- Customer Success owns realized customer outcomes.

---

## Software Engineering Function Model

Transforms approved requirements into reliable, secure, maintainable software that delivers value in production.

### Inputs

- **Approved Requirements:** Epics, features, stories, acceptance criteria, non-functional requirements.
- **Architecture & Design:** Solution architecture, design standards, interface contracts, technical constraints.
- **Product & Technical Context:** Product roadmap, priorities, market context, usage data, operational context.
- **Quality & Security Requirements:** Quality goals, test strategy, security & compliance requirements, risk appetite.
- **Data & Integration Contracts:** Data models, schemas, API contracts, event models, integration requirements.
- **Platform & Infrastructure:** Platform capabilities, environments, cloud services, network & infrastructure standards.
- **Operational & Support Input:** Monitoring data, incident reports, support tickets, postmortems, capacity data.
- **Governance & Compliance:** Policies, regulatory requirements, audit obligations, legal constraints.

### Software Engineering Function

Software Engineering delivers reliable, secure, maintainable software that meets requirements, performs in production, and can evolve.

**Activities** (What we repeatedly do):

- **Plan & Decompose Work:** Break down work; estimate; plan iterations; manage dependencies and commitments.
- **Design Solutions:** Create technical designs; define components, APIs, data models, and interfaces.
- **Develop Code:** Write clean, efficient, secure code; follow standards and coding conventions.
- **Build & Verify:** Compile, lint, unit test; static analysis; quality gates in CI.
- **Test & Validate:** Automated tests, integration tests, performance tests, security tests.
- **Integrate & Merge:** Code reviews; integrate changes; resolve conflicts; maintain mainline health.
- **Deploy & Release:** Deploy to environments; blue/green, canary, or feature flags; release to production.
- **Operate & Improve:** Monitor health; respond to incidents; optimize performance and reliability.
- **Refactor & Evolve:** Improve code quality; reduce technical debt; modernize; continuous improvement.

**Capabilities** (What we must be good at):

- **Software Design** — *Craft modular, scalable, maintainable, and extensible solutions.*
- **Security Engineering** — *Build secure by design; threat modeling; secure coding; vulnerability management.*
- **Coding Excellence** — *Write high-quality code; standards; readability; simplicity; reusability.*
- **Test Engineering** — *Test strategy; automation; test data; coverage; quality engineering.*
- **Integration Engineering** — *APIs, events, services; dependencies; contract management.*
- **DevOps Engineering** — *CI/CD; environments; infrastructure as code; automation.*
- **Data Engineering** — *Data modeling; migrations; data quality; performance; data access.*
- **Observability Engineering** — *Logging, metrics, tracing, dashboards, alerts.*
- **Performance Engineering** — *Performance testing; profiling; tuning; capacity planning.*
- **Reliability Engineering** — *SLOs; resilience; chaos testing; capacity; error budgets.*
- **Collaborative Engineering** — *Cross-functional teamwork; pairing; code reviews; knowledge sharing.*
- **Engineering Practices** — *Standards; architecture governance; documentation; continuous learning.*

**Enabling substrates:**

- **People & Resources:** Software engineers, Tech leads & architects, QA engineers, Security engineers, DevOps / SRE engineers, Data & integration engineers.
- **Tools & Technology:** IDEs & coding tools, Build, test & analysis tools, CI/CD & deployment tools, Artifact repositories, Observability & monitoring tools, Collaboration tools.
- **Platforms & Infrastructure:** Cloud environments, Runtimes & middleware, Databases & storage, Network & security services, Kubernetes / containers, Developer platforms.
- **Standards & Definitions:** Coding standards, Architecture patterns, API & data standards, Environment standards, CI/CD pipeline standards, Naming & branching standards.

### Outputs

- **To Product Management**: Working software increments, Technical feasibility & estimates, Risks, constraints & trade-offs, Technical insights & options
- **To GTM (Sales & Marketing)**: Product capabilities, Demos & sandbox access, Integration samples & docs, Release notes & materials
- **To Operations & Support**: Deployed, monitored systems, Runbooks & operational docs, Incident response support, RCA & remediation
- **To Leadership**: Delivery commitments, Progress & metrics, Risk & issue reports, Investment needs
- **To Security & Compliance**: Secure software, Compliance evidence, Vulnerability reports, Audit artifacts
- **To Data & Platform Teams**: Data schemas & migrations, APIs & service contracts, Integration components, Platform feedback

### Key Boundaries

- Product Management defines WHAT and WHY. Software Engineering owns HOW.
- Engineering builds within approved requirements, architecture, standards, and constraints.
- We do not choose features, set priorities, or make market commitments.
- We partner across functions; we do not own their outcomes.