davidfacer.com / aimaturitymodels.com / Feed This to Your AI

Feed This to Your AI

One markdown file: the AI-Native Maturity Model family, Strata (the architectural governance plane), the Enterprise Architecture OKF explainer, and the site's Function Models. Copy it into your own AI assistant, or point it at /ai/full-context.md directly. An AI agent can also start at the site's map, /llms.txt.

Open raw at /llms.txt →

# AI-Native Maturity Models — AI-Readable Digest

## AI-Native Enterprise Operating Architecture

The practice describes an operating architecture for an AI-native enterprise: an enterprise designed so humans and intelligent agents can share a coherent understanding of work, capability, meaning, authority, and observed reality.

**Philosophy — Ideals over guardrails.**

The ideal practice is finite and can be stated. Its failure modes are not. This practice therefore discovers what is less than ideal through exercise and observation, rather than by trying to anticipate every way it might fail. Investment goes first to making the ideal explicit, instrumenting the practice against it, and reading the delta. The delta is telemetry: it accrues whether or not anyone is working the part that emits it.

Guardrails still matter — linters, hooks, gates, and other controls. Too few and nothing can refuse; too many and every act pays a toll. Guardrails that are frequently contacted mean there is a broken process, and guardrails that are never contacted offer little value outside an obligation or an act that cannot be undone. The practice therefore biases toward explicit ideals, telemetry, and continuous improvement: Toyoda over Taylor.

There are several complementary architectural constructs:

**Function Models — What does the enterprise do?**
Static maps of enterprise functions: their inputs, activities, capabilities, enabling substrates, outputs, and boundaries. They define the anatomy of a function, not a process for performing it.

**Maturity Models — How capable is the enterprise?**
Capability ladders for selected functions and practices. They describe meaningful operating states, the transitions between them, and the observable evidence that distinguishes one state from the next. They measure AI-native capability, not AI adoption, process sequence, or organizational rank.

**Strata — How is enterprise action governed?**
The architectural governance plane for intent, foundations, standards, language, governed records, authority, operations, and observation. Intent is carried as a fiber through consequential action so each realization remains resolvable and checkable against the intent it serves. Observation closes the evidentiary relationship by returning what happened to the stratum whose claims or actions produced it.

**EA OKF — How is the architecture made machine-navigable?**
The machine-readable representation contract for the architecture corpus. Structured YAML headers encode artifact identity, type, relationships, governance, and other architectural metadata, allowing agents to build an in-memory graph, traverse it to determine relevant context, and load Markdown bodies only when needed. Corpus artifacts are Markdown documents carrying EA OKF headers.

**Corpus — What is the governed record?**
The Corpus is the enterprise architecture's single governed record: the authoritative collection of intent, principles, standards, language, decisions, contracts, architecture, evidence, and other governed artifacts. It is the record agents consult rather than relying on memory, embedded extracts, or inferred authority.

These constructs serve different purposes. Do not interpret a Function Model as a maturity ladder, a Maturity Model as a process, Strata as a document hierarchy, the Corpus as a file repository, or EA OKF as an architectural foundation. EA OKF represents and connects the architecture; it is not the architecture itself.

This is a machine-readable digest of the AI-Native Maturity Model family, Strata (the architectural governance plane), the Enterprise Architecture OKF explainer, 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 reads every model at the commit this site pins for it, not at `main` — SDLC at de2668a, PDLC at 418a0df, Prioritization at 5edc31d — so a model release reaches it when a site commit moves the pin. 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 pinned at df8735b and full model text pinned at de2668a; the PDLC view reads short-form cells pinned at 418a0df and full model text pinned at 418a0df and shared D1-D3 layer pinned at de2668a. 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 four maturity models — `STD-SDLC-MM`, `STD-PDLC-MM`, `STD-PRIORITIZATION-MM`, `STD-EA-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`, `ai-native-ea-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.
* Strata, the architectural governance plane — `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, Portfolio Prioritization, Enterprise Architecture) — assessment instruments with A–E ladders. Instructions **M1–M11** apply.
* **Strata** (S0–S7) — the architectural governance plane, used here to classify work. Instructions **S1–S4** apply.
* **Function models** (Product Management, Product Marketing, Software Engineering) — flat ontological maps. Instructions **F1–F5** apply.
* **Enterprise Architecture OKF** — the machine-readable representation contract for the architecture corpus. 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: one model with an Indicative evidence column and three 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 carry verification clauses in that form, 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 Portfolio 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 Portfolio 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, three, and ten dimensions (SDLC, PDLC, Portfolio Prioritization, Enterprise Architecture), 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 four live models in the AI-Native Maturity Model family. The **SDLC** model, complete — all 13 dimensions, A through E; every dimension carries explicit per-transition verification clauses — D4–D13 in the model's own matrix, D1–D3 (shared with PDLC) in the Shared Intelligence Layer, STD-SHARED-INTELLIGENCE v1.1. 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 **Portfolio Prioritization** model — all 3 dimensions, complete with per-transition verification clauses throughout. The **Enterprise Architecture** model — all 10 dimensions, complete with per-transition verification clauses and Level E sustainment throughout; three of its dimensions (D4, D5, D6) ship carrying a visible open question about the dimension itself, which is a statement about the question and not about the cell content, and the model's page renders those questions rather than hiding them. Also included: Strata, the architectural governance plane (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 exist for three of the four 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. Those three can be formally blind-scored; the instruments themselves just aren't reference material handed to an AI here. **The Enterprise Architecture model has no scoring instrument yet** — it is a tracked, open piece of work, and this sentence says so rather than letting a family-wide "all" quietly absorb the exception.

**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, https://github.com/superdtf-0882/ai-native-ea-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.1 · 2026-10-06**

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

---

## How to read this layer

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

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

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

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

---

## D1. Market discovery & definition

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

**Level A**

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

**Transition from A to B**

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

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

**Level B**

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

**Transition from B to C**

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

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

**Level C**

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

**Transition from C to D**

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

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

**Level D**

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

**Transition from D to E**

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

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

**Level E**

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

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

**Sustainment**

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

---

## D2. Buyer & user persona development

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

**Level A**

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

**Transition from A to B**

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

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

**Level B**

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

**Transition from B to C**

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

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

**Level C**

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

**Transition from C to D**

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

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

**Level D**

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

**Transition from D to E**

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

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

**Level E**

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

**Sustainment**

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

---

## D3. Positioning & competitive intelligence

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

**Level A**

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

**Transition from A to B**

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

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

**Level B**

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

**Transition from B to C**

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

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

**Level C**

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

**Transition from C to D**

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

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

**Level D**

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

**Transition from D to E**

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

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

**Level E**

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

**Sustainment**

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

---

## Shared Level E convergence rule

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

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

The convergence test is:

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

---

## Lifecycle interfaces

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

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

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

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

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

---

## Canonical-source rule — in force

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

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

## Reconciliation record

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

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

## Changelog

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

---

# AI-Native SDLC Maturity Model — Matrix

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

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

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

---

## How to read this matrix

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

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

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

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

### Maturity-level names

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

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

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

---

### Pre-AI — The Threshold State

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

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

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

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

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

---

### Exempt — The Governed Stance

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

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

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

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

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

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

---

### Assessment values

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

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

---

## D1–D3. Shared Intelligence Layer

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

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

---

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

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

**Level A — Nascent**

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

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

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

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

**Level B — Modeled**

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

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

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

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

**Level C — Continuous**

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

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

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

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

**Level D — Integral**

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

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

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

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

**Level E — Telemetric**

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

**Sustainment**

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

---

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

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

**Level A — Nascent**

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

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

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

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

**Level B — Modeled**

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

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

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

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

**Level C — Continuous**

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

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

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

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

**Level D — Integral**

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

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

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

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

**Level E — Telemetric**

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

**Sustainment**

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

---

## D6. Architecture governance

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

**Level A — Nascent**

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

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

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

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

**Level B — Modeled**

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

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

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

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

**Level C — Continuous**

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

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

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

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

**Level D — Integral**

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

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

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

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

**Level E — Telemetric**

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

**Sustainment**

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

---

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

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

**Level A — Nascent**

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

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

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

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

**Level B — Modeled**

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

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

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

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

**Level C — Continuous**

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

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

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

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

**Level D — Integral**

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

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

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

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

**Level E — Telemetric**

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

**Sustainment**

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

---

## D8. Code verification & review

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

**Level A — Nascent**

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

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

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

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

**Level B — Modeled**

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

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

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

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

**Level C — Continuous**

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

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

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

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

**Level D — Integral**

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

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

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

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

**Level E — Telemetric**

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

**Sustainment**

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

---

## D9. Environment management

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

**Level A — Nascent**

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

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

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

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

**Level B — Modeled**

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

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

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

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

**Level C — Continuous**

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

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

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

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

**Level D — Integral**

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

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

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

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

**Level E — Telemetric**

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

**Sustainment**

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

---

## D10. Release discipline

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

**Level A — Nascent**

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

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

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

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

**Level B — Modeled**

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

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

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

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

**Level C — Continuous**

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

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

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

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

**Level D — Integral**

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

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

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

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

**Level E — Telemetric**

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

**Sustainment**

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

---

## D11. Security & compliance

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

**Level A — Nascent**

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

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

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

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

**Level B — Modeled**

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

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

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

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

**Level C — Continuous**

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

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

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

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

**Level D — Integral**

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

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

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

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

**Level E — Telemetric**

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

**Sustainment**

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

---

## D12. Instrumentation & observability

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

**Level A — Nascent**

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

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

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

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

**Level B — Modeled**

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

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

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

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

**Level C — Continuous**

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

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

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

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

**Level D — Integral**

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

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

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

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

**Level E — Telemetric**

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

**Sustainment**

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

---

## D13. Feedback loop velocity

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

**Level A — Nascent**

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

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

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

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

**Level B — Modeled**

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

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

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

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

**Level C — Continuous**

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

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

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

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

**Level D — Integral**

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

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

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

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

**Level E — Telemetric**

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

**Sustainment**

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

---

## Cross-dimension boundary checks

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

### D4 / D5 / D7

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

### D6 / D8

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

### D6 / D11

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

### D8 / D11

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

### D9 / D10

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

### D11 / D12

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

### D12 / D13

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

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

---

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

---

## AI-Native PDLC Maturity Model

# AI-Native PDLC Maturity Model — Matrix

**Version 1.2.3 — 2026-10-08** (the level names line now names all four models in the family, Enterprise Architecture included, by their current names. No level, transition or verification changed; scores against v1.2.2 are unaffected) Previously: **Version 1.2.2 — 2026-10-08** (this line corrected: v1.2.1 changed D5's and D11's notes to name the AI-Native Portfolio Prioritization Maturity Model and did not update this version line. No level, transition or verification changed in either release) Previously: **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, Portfolio Prioritization, and Enterprise Architecture), used as column headers wherever the matrix is rendered:

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

These names describe a general shape of maturity, not this dimension's own specific content — read each level's own text below for what that shape means concretely at 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 Portfolio 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 Portfolio 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 Portfolio Prioritization Maturity Model

# AI-Native Portfolio Prioritization Maturity Model — Matrix

**Version 1.4.1 — 2026-10-08** (the level names line now names all four models in the family by their current names, and this version line names the release. v1.4.0 renamed this model the AI-Native Portfolio Prioritization Maturity Model and added Roots; v1.3.0 added the Strategic Value Matrix beside this matrix, which it left unchanged. No level, transition or verification changed in v1.4.1; scores against v1.4.0 are unaffected) Previously: **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 portfolio prioritization capability — its ability to see the whole of its discretionary work, product and internal alike, as one portfolio of fungible assets, and to allocate capital, capacity and attention across it on an explicit value model. It is not an appraisal of any 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 portfolio 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, Portfolio Prioritization, and Enterprise Architecture):

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

## Roots

The roots here reach deeper than 2015. In 2010, a colleague and I implemented enterprise wide portfolio management from the Product Management function, but we captured all internal work outside of core ops functions so that we could present a true, universal backlog to executives. In this way they weren't living in a fantasy world believing there was available capacity when there was not.

## 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 portfolio 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 portfolio-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 | Portfolio 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. | — |

### The Strategic Value Matrix — this model's Level E reference pattern

Frame version: 1.10

*Authored by David Facer in 2015, and the reference pattern for Level E Value Model Coherence in the [AI-Native Portfolio Prioritization Maturity Model](https://github.com/superdtf-0882/ai-native-product-prioritization-maturity-model/blob/5edc31d631b1807263dffadcff123b39704e7752/ai_native_product_prioritization_maturity_model.md). Derived content, not independently versioned.*

## What it is

A method for ranking work by value against ease, so that a portfolio's competing items can be ordered on one explicit scale. Every item is scored in two halves: what it is worth (**Business Value**) and how readily it can be done (**Ease of Implementation**). The ranking is computed from the scores; nothing about the order is typed in by hand.

This page states the **frame**: the rules every adopter shares. The **criteria and their weights are not part of it**. Each organization sets its own (rule 2). The sample in `svm_sample.yml` uses seven illustrative criteria and eight fictional initiatives so the method can be seen working. **They are examples, not a recommended set.**

## The rules

1. **The scale is geometric, and its ratios are asserted.** A score takes one of four values: Low 1, Medium 3, High 9, Massive 27. Each is three times the last. That is a claim: Massive is worth twenty-seven times Low. **Making the claim is what makes it legitimate to weight and add scores at all.** A 1-to-4 scale only puts things in order; it asserts no ratio between them, so its scores cannot honestly be summed. The ease criteria are scored inverted: a huge item scores 1 and a tiny one 27, so a higher score is always better.

2. **Two composites, with weights summing to 1.00.** Business Value and Ease of Implementation are each a weighted sum of the organization's own criteria, and an item's total is their sum. **The criteria and the weights must be the adopter's own.** So must the split between the two halves, which records how much ease matters against value.

3. **Dependency lift.** If an item ranks below something that depends on it, it inherits that dependent's score: it must be done first, so it ranks as high as the work it unblocks. **The lift runs through whole chains.** A prerequisite of a prerequisite rises too, as far as the chain goes.

4. **Several dependents: take the higher, never the sum.** Summing would count the same value twice, and would put any universal prerequisite permanently at the top.

5. **Ties break toward smaller and safer.** Among equal totals, the item with the higher size inversion plus risk inversion goes first: the smaller, lower-risk item.

6. **A lifted score needs a note.** Any item ranked above its own merit because of a dependency must say why. An unexplained lift is flagged when it occurs, not when someone remembers to look.

7. **Lifted scores are computed, never typed.** Dependencies are recorded; the inherited score is derived from them every time the ranking is computed. **An item's own scores are never adjusted to move it in the ranking.** The lift exists so that adjustment is never necessary.

8. **A prerequisite sorts before its dependent.** Rule 3 makes ties the normal outcome, because a lifted item equals the item it unblocks, and rule 5 knows nothing about direction. **So direction is applied first:** within a tie, prerequisites come before what depends on them, and size and risk decide only what direction leaves open.

## Leaving the ranking

**An item leaves when it is confirmed complete at the reach it declared when it entered**, not when someone marks it done. For public work, the reach is normally the live page a reader actually arrives at. *Done* names a state; a **reach** names where the result can be seen, and the confirmation names how it was checked. **An item finished somewhere nobody looks is still in the ranking.**

## The sample, and the test

- **`svm_sample.yml`** holds seven illustrative criteria, four for value and three for ease, and eight fictional initiatives. Two of the initiatives are prerequisites of others.
- **`svm_conformance.yml`** holds the cases any implementation of these rules must pass. They include a chain of four, which an implementation that follows dependencies only part of the way will rank wrongly, and the cases say so. **A calculator that disagrees with them is not this method.**

---

## AI-Native EA Maturity Model

# AI-Native Enterprise Architecture Maturity Model — Matrix

**Version 1.1.1 — 2026-09-15.** Ten dimensions, five levels (A–E)
per dimension, family vocabulary and matrix form identical to
`STD-SDLC-MM`, `STD-PDLC-MM` and `STD-PRIORITIZATION-MM`. **Locked and
released. Registered as `STD-EA-MM`.** Dimension provenance: the nine elements
of the US Department of Commerce ACMM, as cited in TOGAF's Architecture
Maturity Models chapter, with two deliberate substitutions recorded under
*Dimension provenance* below.

This markdown document is intended as the source of truth for the matrix.
This model does **not** inherit D1–D3 from `STD-SHARED-INTELLIGENCE`:
that layer is market-scoped — market discovery, buyer persona,
positioning — and enterprise architecture is not a market-facing
function. Confirmed by reading the shared layer's own definition, not
assumed.

---

## How to read this matrix

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

Dimensions are scored independently. An enterprise can be Integral in
one and Nascent in another, and ordinal levels are never averaged into a
composite score.

Each level is followed by the transition required to reach the next and
a **verification** statement — a practical test of whether the
destination has actually been reached rather than claimed. Level E is
followed by a sustainment note instead of a transition: at the top of
the ladder the work shifts from climbing to keeping the capability from
quietly regressing.

### Maturity-level names

Family-wide, identical across every dimension and every model in this
family.

---

### Pre-AI — the threshold state

**Pre-AI** designates a dimension in which an enterprise 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.

**Pre-AI is not an assessment of general EA maturity.** A practice with
a rigorous TOGAF ADM cadence, a well-governed repository, and a scoring
history against classic EA maturity frameworks — but no AI tooling —
scores Pre-AI exactly as a practice with none of that does. This model
measures AI-native maturity; general architectural excellence is already
well measured elsewhere.

**Transition velocity.** Existing architectural discipline is
transferable substrate. A practice with a real ontology, enforced
metamodel conformance, or an operating repository will typically cross
levels faster than one without — the discipline transfers, the tooling
changes. Pre-AI dimensions may carry a narrative **readiness note**
recording the non-AI maturity that predicts transition speed. The
readiness note is not a score.

**Expect this state to be common.** Enterprise architecture is later to
agentic adoption than software delivery. An assessment in which most
dimensions score Pre-AI is an ordinary result, not a failing one.

### Exempt — the governed stance

**Exempt** designates a dimension an enterprise 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 enterprise
intends to move from, Exempt records a decision it has made and stands
behind. An Exempt designation cites the governing constraint, is
excluded from aggregates, is always rendered rather than hidden, and is
reviewable.

---

### Dimension provenance

Seven dimensions carry the DoC ACMM element names unchanged:
Architecture Process, Architecture Development, Business Linkage, Senior
Management Involvement, Operating Unit Participation, Architecture
Communication, and Architecture Governance.

Two are substituted deliberately:

- **IT Investment and Acquisition Strategy → Strategic Portfolio
Management & Asset Allocation (D8).** The original frames the scarce
resource as software procurement. In an AI-native enterprise the
scarce resources are capital, compute, token budget, and agentic
capacity, and they are reallocated continuously rather than acquired
annually.
- **IT Security → Governance & Authority Plane (D7).** Security as a
*domain* was always an odd member of an architecture *capability*
model. What agentic operation requires in its place is an explicit
model of decision rights and the surfaces those rights reach.

**Scope boundary, stated rather than left absent.** This model does not
assess the security programme — data protection, secrets hygiene, vendor
risk, and regulatory security compliance are out of scope. What D7 does
carry is **reachability**: whether an authority boundary has been
established against the surface it actually covers.

---

## D1. Architecture process

*The capability to create, maintain, and align architectural intent, and
the degree to which semantic discipline and AI assist in translating
human strategy into executable governance.*

**Level A — Nascent**

Architecture processes are manual, document-heavy, and local to IT
silos. Semantic definitions vary by team: what counts as a "service" or
a "customer" differs between the groups that use the words. AI appears
informally, as an individual's brainstorming tool, with no shared
prompts, no common ontology, and no method for validating what it
produces.

**Transition A → B — Establish a machine-readable ontology**

Define a foundational enterprise ontology in a machine-readable form,
and a standardized, AI-assisted method for translating business
capabilities and technology standards into it. Replace fragmented
word-processing documents and static diagrams as the place architectural
meaning lives.

**Verification:** Two teams that previously used a term differently now
resolve it to the same definition by looking it up, and can say where
that definition lives.

**Level B — Modeled**

Architecture is captured in a formal, machine-readable schema grounded
in a stated ontology. Humans do the authoring and the mapping of
business intent into that schema. Generative AI is used as a copilot —
typically to normalize legacy documentation into the shared taxonomy —
but humans remain the mechanical drafters.

**Transition B → C — Charter agents to author, and move humans to validation**

Formally charter architectural AI agents with write access to the
architecture repository, under an explicit statement of what each may
and may not author. Shift the mechanical burden of drafting from humans
to agents, and redefine the human architectural role as validation of
the agent's output against the ontology.

**Verification:** A material architectural change was authored by a
chartered agent and accepted after human semantic review, and the
charter under which it acted can be produced.

**Level C — Continuous**

Chartered agents mechanically author and update the architecture into
the machine-readable single source of truth under stated constraints.
The human process has shifted from document creation to **semantic
validation** — confirming that generated models reflect business intent
and hold to the lexical discipline of the ontology.

**Transition C → D — Make the architecture answer planning questions**

Connect the machine-readable architecture into business planning cycles.
Require that a proposed strategic change be run as a simulation against
the architecture graph, showing downstream impact, before executive
approval.

**Verification:** At least one strategic decision was materially altered
— scope, sequence, or rejection — by what a simulation against the graph
showed, and the alteration is traceable to that run.

**Level D — Integral**

The ontology bridges the business and technology divide. During
planning, agents parse the semantic graph to run simulations that show
stakeholders the operational impact, risk, and cost of a proposed change
before it is committed. Once human consensus is reached, the updated
architecture dictates downstream execution constraints without manual
translation.

**Transition D → E — Close the loop with operational evidence**

Instrument the runtime environment to feed execution signal — system
logs, agent state, resource consumption — back to the architectural
agents, so that operational reality can be compared against declared
intent rather than assumed to match it.

**Verification:** A divergence between declared architecture and
operational reality was detected from telemetry rather than reported by
a person, and produced a reviewed proposal.

**Level E — Telemetric**

The architecture process is a continuous, empirically driven loop rather
than a scheduled drafting exercise. Agents ingest runtime telemetry and
compare operational reality against the ontology. When **semantic
drift** appears — the same concept realized inconsistently across the
estate — the agents draft and propose refactoring or process
optimization for the human review board.

**Sustainment**

Continuously refine the ontology as new business models emerge. The
specific risk at this level is an ontology that stops being revised
because everything downstream now depends on it: stability of meaning
and ossification of meaning look identical from inside.

---

## D2. Architecture development (artifacts and substrate)

*The capability to evolve architecture artifacts from static documents
into a machine-readable substrate that actively binds runtime
execution.*

**Level A — Nascent**

Artifacts are static, disparate, human-readable documents —
presentations, PDFs, whiteboard photographs. There is no central
repository and no consistent structure. AI cannot reliably reason over
the architecture because it has no standard form to read.

**Transition A → B — Impose structure before imposing schema**

Establish standardized templates, taxonomies, and structured formats to
replace ad-hoc documents, preparing the architecture for reliable
machine ingestion. This is a formatting discipline, not yet a data
model.

**Verification:** A tool — not a person — can enumerate the
architecture's artifacts and their types without bespoke parsing per
document.

**Level B — Modeled**

Architecture is developed using strict templates and a formal taxonomy,
but remains fundamentally document-centric rather than a schema or a
graph. Human architects manage the artifacts. AI ingests,
cross-references, and validates them, but the source of truth is still a
collection of human-authored files.

**Transition B → C — Migrate from documents to a schema, and generate the views**

Migrate the structured documentation into a unified machine-readable
schema. Charter an agent to maintain it and to generate human-readable
views on demand, so that no human-facing rendering is separately
maintained.

**Verification:** A human-consumable rendering — workbook, report,
diagram — was regenerated from the schema rather than edited, and the
previously hand-maintained version has been retired.

**Level C — Continuous**

Architecture is natively developed as data within a machine-readable
schema. A chartered agent maintains it and recomposes the graph into
human-consumable formats on demand, eliminating separately maintained
static diagrams. Traversal is fast enough that recomposition is
interactive rather than a batch job.

**Transition C → D — Extend the same schema to execution**

Extend access to the architecture repository down into engineering
execution environments, so that engineering agents and architectural
agents parse and traverse the same schema rather than a translation of
it.

**Verification:** An engineering agent took a constraint directly from
the architecture repository, and no separate engineering-facing copy of
that constraint exists to drift.

**Level D — Integral**

Architecture artifacts and engineering context are nodes in one
structure. Engineering agents parse the same repository to inherit their
constraints, rules, and configuration natively. The artifacts bound the
autonomy of the runtime environment without being translated into
separate engineering documents.

**Transition D → E — Let execution write back**

Embed telemetry hooks in execution environments and configure them to
write operational state changes and performance signal back into the
corresponding architectural nodes.

**Verification:** A node's recorded state changed because the system
changed, with no human edit in the path, and the change is attributable
to a named signal.

**Level E — Telemetric**

Nodes update their own status from execution telemetry. The artifacts
represent not the intended architecture but **the current operational
reality** of the estate, and human-readable exports carry empirical
drift and performance alongside design intent.

**Sustainment**

Prune and optimize the schema as telemetry volume and relationship
density grow, so that traversal stays interactive. Watch specifically
for nodes that update automatically and are read by no one: an
auto-updating artifact nobody consumes is cost without signal.

---

## D3. Business linkage

*The capability to connect business intent, strategic goals, and value
streams structurally to execution, so that technical and agentic work
traces to business authority.*

**Level A — Nascent**

Business strategy exists in isolation from architecture and engineering
backlogs, communicated as narrative documents. Units use conflicting
terms for the same functions. AI initiatives are shadow pilots with no
traceable linkage to enterprise value streams.

**Transition A → B — Distil narrative strategy into named structures**

Distil narrative business strategy into flat, ontological function
models and capability maps, with each function and capability formally
named and defined under the same semantic discipline as the rest of the
architecture.

**Verification:** Every strategic priority currently being funded can be
named as a capability that exists in the map, or is visibly absent from
it.

**Level B — Modeled**

The enterprise holds flat, ontological function models and capability
maps. Business functions and capabilities are formally named and
defined. Linkage between these artifacts and the execution layers
remains manual — cross-referenced by hand. AI assists in parsing
narrative strategy to draft the models.

**Transition B → C — Make lineage an edge, not a spreadsheet**

Ingest the function models and capability maps into the machine-readable
repository as first-class nodes, and replace manual cross-referencing
with lineage edges that resolve.

**Verification:** A proposed initiative was refused, or sent back, for
lacking a resolving edge to an approved capability — and the refusal
came from a check rather than from a person's recollection.

**Level C — Continuous**

Function models and capability maps are interconnected nodes in the
repository. Strategic intent is linked to technical components by
edges. Chartered agents evaluate proposed initiatives and engineering
tasks for an unbroken lineage to an approved capability, and work
lacking machine-verifiable lineage is rejected.

**Transition C → D — Bind operational constraints to capability nodes**

Bind decision thresholds, priority weightings, and agent autonomy
budgets directly to capability nodes, so that a shift in strategic
priority alters runtime constraints rather than only documentation.

**Verification:** A change made to a capability node — and nothing else
— measurably altered runtime behaviour downstream.

**Level D — Integral**

Business intent governs runtime boundaries. When executives alter
strategy, the change is made to the business nodes; because engineering
agents inherit constraints from those nodes, operational parameters,
authorization limits, and tool access reconfigure without manual
translation.

**Transition D → E — Measure realization, not just conformance**

Connect business performance measures — revenue, conversion, unit
economics — to runtime telemetry, so the architecture can evaluate
execution against outcomes rather than against compliance.

**Verification:** A capability that was fully conformant and
nevertheless failed to deliver its expected outcome was identified as
such, and the distinction was visible in the record.

**Level E — Telemetric**

The link between strategy and architecture is a self-evaluating loop.
Telemetry measures **value realization per capability node** against its
declared intent. When a component or agentic workflow fails to deliver
its expected outcome or exceeds unit-economic thresholds, the system
flags the strategic disconnect and models realignments for executive
review.

**Sustainment**

Recalibrate outcome measures as markets shift, so the loop does not
optimize against obsolete indicators. A closed loop pointed at a stale
KPI is more dangerous than an open one, because it acts.

---

## D4. Senior management involvement

*The capability of executive leadership to author foundational intent,
champion semantic discipline enterprise-wide, and trust the
architectural substrate to govern execution.*

**Level A — Nascent**

Executives treat architecture as an IT paperwork exercise. Strategic
intent is implicit, undocumented, or scattered across memos. No one
sponsors semantic alignment across units, so marketing, finance, and
technology operate with different definitions of the same things.

**Transition A → B — Put a name on the intent**

Executives formally endorse a unified effort to establish semantic
discipline, and begin explicitly authoring — or explicitly endorsing —
foundational strategic intent as a recorded artifact rather than a
shared understanding.

**Verification:** Foundational intent exists as a citable artifact with
a named author or endorser and a date, and a disputed definition has
been settled by reference to it.

**Level B — Modeled**

Executives author or formally endorse foundational intent, and champion
ontological work across non-technology functions. Management spends the
political capital required to make separate functions agree on unified
function models and capability maps, acting as final arbiter of semantic
disputes.

**Transition B → C — Mandate the repository as the system of record**

Mandate that the machine-readable repository is the official system of
record for strategic planning, and retire bespoke departmental strategy
decks as competing sources.

**Verification:** A strategic planning cycle completed with the
repository as its source, and at least one departmental deck was retired
rather than maintained alongside.

**Level C — Continuous**

Management mandates the repository as sole source of truth for strategy
and architecture. Executives consume strategic updates through the
chartered agent's generated renderings rather than commissioning manual
decks. No capital is deployed and no initiative funded unless it traces
to executive-authored intent in the graph.

**Transition C → D — Simulate before committing**

Shift executive decision-making to use the graph's simulation capability
before approving strategic pivots, organizational changes, or capability
reconfigurations.

**Verification:** A capital commitment was withheld, resized, or
resequenced on simulation evidence, and the decision record cites the
run.

**Level D — Integral**

Executives use the graph as their primary steering mechanism, relying on
simulation before committing capital. They understand that updating
foundational intent or capability constraints is not a documentation act
but an operational one that alters the boundaries and autonomy budgets
of downstream agents.

**Transition D → E — Let evidence reach intent**

Require executive review of operational telemetry, establishing that
runtime evidence informs the next cycle of intent authoring rather than
only the next cycle of delivery.

**Verification:** Foundational intent was revised, and the revision
cites operational evidence rather than conviction.

**Level E — Telemetric**

Executives consume architecture as an empirical feedback loop. When
agents flag that a capability is drifting from authored intent on
runtime evidence, management reviews the proposed realignments.
Foundational intent is refined on operational evidence — and **revisions
to intent are rare but non-zero**, which is itself the signal: intent
revised continuously cannot serve as a benchmark, and intent never
revised is not being tested.

**Sustainment**

Continuously calibrate the boundaries of agentic autonomy against risk
appetite as the market and the technology change. Watch the revision
rate of intent in both directions.

---

## D5. Operating unit participation

*The capability of business units, functions, and capability owners to
engage with, consume, and ultimately be guided by the enterprise
architecture.*

**Level A — Nascent**

Operating units treat architecture as an impediment. Functions operate
in silos with local, unstandardized terminology, relying on shadow
tooling and unsanctioned AI to solve local problems — bypassing the
architecture and creating blind spots in it.

**Transition A → B — Make the units author their own domains**

Require functional leaders to map their operations into the enterprise's
function models and capability maps, distinguishing their functions from
their capabilities in the shared ontology. Participation is authorship,
not review.

**Verification:** Each operating unit's domain is represented in the
shared models by text its own leaders wrote, and they can find it.

**Level B — Modeled**

Operating units participate in the semantic discipline. Leaders define
their domains explicitly within the standardized ontology. Units consume
the architecture as static reference to understand boundaries and
dependencies, but daily execution stays largely disconnected from the
model.

**Transition B → C — Move from reading documents to querying the model**

Shift units from consuming static reference material to querying the
chartered agent for tailored, current recompositions of the architecture
as an input to their own planning cycles.

**Verification:** A unit's planning cycle used a generated
recomposition, and the unit can state when its view was last current —
because the answer is "now."

**Level C — Continuous**

Units actively consume the architecture. Because the agent recomposes
the repository into formats tailored to each domain, functional and
capability leaders use it as their primary trusted tool for operational
planning, dependency tracking, and roadmap alignment. They trust it
because it is current.

**Transition C → D — Let the edge build, bound by the centre**

Empower units to deploy their own local workflow or engineering agents,
under the strict condition that those agents inherit execution
constraints natively from the enterprise repository rather than being
separately configured.

**Verification:** A unit-deployed agent was constrained by an enterprise
boundary it never had configured locally, demonstrated by the constraint
changing centrally and the unit's agent following.

**Level D — Integral**

Units drive innovation at the edge with their own agents and automated
workflows, which parse and bind to the enterprise repository. The
architecture informs and constrains unit execution in real time, so
local agility does not violate enterprise intent or security boundaries.

**Transition D → E — Expose the telemetry to the edge**

Expose runtime telemetry directly to unit leaders, shifting their focus
from deploying capabilities to measuring them against the graph.

**Verification:** A unit changed its own local workflow on telemetry it
read itself, without central prompting.

**Level E — Telemetric**

Units consume the architecture as a live operational view. Functional
leaders monitor the feedback loop to see how their domains execute
against intent, and rely on agents to highlight local inefficiency and
propose refactoring. **The distinctive measure at this level is the
centre's accuracy about the edge**: how faithfully the enterprise
repository reflects what operating units are actually doing.

**Sustainment**

Units must formalize local ontologies as they spin up new capabilities,
so the centre stays accurate. The failure mode is a repository that
describes the edge as it was chartered rather than as it operates.

---

## D6. Architecture communication

*The capability to socialize, query, and proactively surface
architectural intent, constraints, and semantics to humans and AI
assistants across the enterprise.*

**Level A — Nascent**

Communication is pull-based and human-to-human. Anyone needing
architectural guidance must find the right architect or search
fragmented repositories. Answers are frequently out of date by the time
they are given, and no channel is authoritative.

**Transition A → B — Give the architecture one address**

Centralize structured documentation and capability maps into a single,
visible repository that is the explicit reference point for all teams.

**Verification:** A question previously answered by asking a person is
now answered by going to a known location, and the location is the same
one for every team.

**Level B — Modeled**

The enterprise communicates architecture through a central repository
holding the function models and capability maps. Information is
standardized but communication is static and pull-based: users must
navigate to find the constraints relevant to their work.

**Transition B → C — Put a query layer in front of the graph**

Deploy an interface over the repository that allows the chartered agent
to act as a conversational query layer, recomposing the graph on demand
into the form the asker needs.

**Verification:** A non-architect obtained a correct, current answer to
an architectural question without knowing the repository's structure.

**Level C — Continuous**

Architecture is communicated through a browsable interface over the
repository and through natural-language query of the chartered agent.
Instead of searching static documents, stakeholders ask; the agent
traverses the graph and answers by recomposing it into a form tailored
to the asker.

**Transition C → D — Open the graph to non-technology assistants**

Open the repository to specialized functional AI assistants outside
technology — finance, HR, executive copilots — so they parse the
architecture at runtime to give their own users contextual guidance.

**Verification:** A functional assistant outside the technology
organization gave architecturally correct guidance, sourced from the
repository, to a user who never queried it.

**Level D — Integral**

Communication is decentralized and embedded in daily work. Functional
assistants parse the repository continuously, guiding their users and
defending the ontology in the moment — for instance, surfacing the
approved term while a memo is being drafted, so semantic drift is
prevented rather than corrected.

**Transition D → E — Let the architecture initiate**

Configure the architecture to speak without being asked: telemetry-driven
alerts when execution approaches or crosses an architectural boundary,
addressed to the owner of the thing affected.

**Verification:** An owner learned of a boundary condition from an
unsolicited, correctly addressed alert before anyone thought to look.

**Level E — Telemetric**

The architecture moves from queried reference to **initiator**. Driven
by telemetry, agents alert capability owners, functional assistants, and
engineering teams when semantic drift appears in production, performance
degrades, or a boundary is breached. The dialogue is empirical and
started by the system.

**Sustainment**

Continue training agents on local context and operational vernacular so
that proactive guidance is phrased in the language of the unit receiving
it. The failure mode at this level is alert fatigue: an unsolicited
channel that is ignored is worse than one that does not exist, because
it is believed to be working.

---

## D7. Governance and authority plane (Auctoritas)

*The capability to model, delegate, and programmatically enforce
decision rights, authority boundaries, the surfaces those boundaries
actually cover, and policy compliance across both human actors and
machine agents.*

**Level A — Nascent**

Governance is manual, fragmented, and bureaucratic. Policies live in
static documents or are enforced through ad-hoc committee review.
Nothing structurally distinguishes an action requiring executive
sign-off from a routine automated task, and no record states which
surfaces any given authority applies to. Agents and operational teams
act on implicit, unmonitored decision rights.

**Transition A → B — Name the authorities and their extent**

Model governance rules, decision thresholds, and authority delegations
as structured ontological nodes mapped to the capability map. For each
authority, state the surfaces it covers — the systems, data, and tools
inside its extent. An authority with no stated extent is undefined
rather than merely undocumented, because nothing can later establish
whether it was honoured.

**Verification:** For any consequential action, a reader can name both
who may authorize it and which surfaces that authorization reaches,
without asking the person who wrote the policy.

**Level B — Modeled**

Governance policies, decision rights, and authority boundaries are
formally defined and mapped to functions and capabilities within the
ontology, each naming the surfaces it covers. The enterprise holds a
documented map of who — or which agentic tier — may take which action
over what. Enforcement remains manual: periodic audits, human sign-offs,
and review boards.

**Transition B → C — Make the rules machine-verifiable, and establish reach by attempt**

Ingest the governance nodes and authority tokens into the
machine-readable repository so that proposed initiatives, changes, and
agentic workflows are checked automatically before clearance. In the
same motion, establish each boundary's actual reach by attempting access
rather than by reading configuration. A control's declared scope and its
enforced scope are two different claims, and only the second protects
anything.

**Verification:** A gate refuses a real action lacking a valid authority
path, demonstrated by attempting it rather than by inspecting the rule;
and for each enforced boundary, the reachable surface has been probed
rather than inferred from settings.

**Level C — Continuous**

Governance policies and authority tokens are active nodes in the
repository. Automated checks clear or block proposed initiatives,
engineering changes, and agentic workflows before deployment without
routing through committee review. Each enforced boundary's reach has
been established by attempt, so the surface a control actually covers is
known rather than assumed.

**Transition C → D — Mediate at runtime, and declare what is not mediated**

Move enforcement from deploy-time gating to runtime mediation, verifying
an actor's graph-backed authority at the moment of execution. Require
every mediation point to declare the paths by which it can be crossed,
or to assert that none exist. An undeclared exclusion is the boundary
most likely to be found first by someone outside the enterprise.

**Verification:** A consequential action is refused at runtime on
authority grounds; and every mediation point carries a current statement
of what it does not mediate, with at least one exclusion traceable to a
deliberate design decision rather than to an oversight.

**Level D — Integral**

The governance plane mediates execution in real time. No actor — a human
operating through an assistant, or an autonomous workflow — executes a
consequential action without the runtime verifying an explicit,
graph-backed authority token against the repository. Policies bind
dynamically: updating a risk threshold or decision right alters the
operational boundary across the system. Every mediation point states its
own exclusions.

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

Connect runtime governance exceptions, policy violations, and
authority-boundary hits to a continuous telemetric loop. Instrument the
inverse in the same motion: a control that has never refused anything is
either unnecessary or pointed where nothing passes, and only telemetry
distinguishes the two.

**Verification:** The loop reports both boundary hits and un-fired
controls, and at least one control has been retired, retargeted, or
confirmed necessary on that evidence.

**Level E — Telemetric**

The governance plane is a self-regulating empirical loop. The system
continuously evaluates friction, exceptions, and risk events against
stated risk appetite, reporting not only where boundaries were hit but
**where they never were**. When policies prove overly restrictive, fail
to catch emerging risk, or enforce nothing at all, the architecture
flags the disconnect and proposes optimized rules and authority
realignments for executive endorsement.

**Sustainment**

Audit the governance graph against shifting regulatory landscapes and
macro strategy. Re-establish boundary reach by attempt on a standing
cadence: a surface probed once is a claim with a date on it, and
infrastructure changes without announcing itself.

---

## D8. Strategic portfolio management and asset allocation

*The capability to price, prioritize, and allocate capital, compute, and
agentic resources across competing initiatives on machine-verifiable
capability lineage.*

**Level A — Nascent**

Initiatives, software acquisitions, and AI projects are funded through
annual cycles and departmental politics. No shared model exists for
pricing risk or comparing competing efforts. AI spending is fragmented
across uncoordinated budgets with no portfolio-level visibility.

**Transition A → B — Price against the capability map**

Establish standardized, ontological frameworks for pricing initiatives
and mapping competing backlogs to enterprise capabilities, so that
competing proposals are compared on a common basis.

**Verification:** Two initiatives from different units were compared on
the same stated criteria, and the criteria existed before the comparison
rather than being constructed for it.

**Level B — Modeled**

The enterprise uses function models and capability maps to categorize
proposals, and standardized criteria to price and prioritize competing
initiatives. Allocation remains a periodic manual review, with budgets
locked into static allocations rather than shifting with feedback.

**Transition B → C — Require lineage to hold funding**

Ingest prioritized backlogs and portfolio allocations into the
repository, and require every funded initiative to hold valid, resolving
capability lineage.

**Verification:** Funding was withheld or withdrawn from an initiative
for lacking machine-verifiable lineage, not merely flagged for it.

**Level C — Continuous**

Portfolio priorities and allocations are maintained in the repository.
Proposed features, internal tooling, and agentic workflows are
prioritized against capability nodes using shared economic models.
Chartered agents assess the backlog continuously so that no capital or
compute is allocated without machine-verifiable business lineage.

**Transition C → D — Let resources move between planning cycles**

Move from periodic planning to continuous allocation, so that compute,
token budget, and agentic capacity flow toward verified high-yield
capabilities as evidence changes, with switching costs priced rather
than ignored.

**Verification:** Resources moved materially between capabilities
outside a planning cycle, and the switching cost of the move was
computed rather than assumed negligible.

**Level D — Integral**

Allocation operates as a continuous portfolio engine. The enterprise
prices and re-prices competing initiatives against shifting market
signal and strategic intent. Compute, token budgets, and agentic
capacity route to capability nodes demonstrating value realization, and
underperforming initiatives are deliberately starved.

**Transition D → E — Close the loop on unit economics**

Connect runtime telemetry and actual unit-economic outcomes to the
valuation engine, so reallocation responds to realized return rather
than projected return.

**Verification:** A reallocation was driven by realized unit economics
that contradicted the initiative's original valuation, and the
contradiction is on the record.

**Level E — Telemetric**

Portfolio management is an empirical, self-optimizing loop. The system
measures **realized economic return and operational efficiency per
funded capability** against its original valuation. When markets shift
or bottlenecks appear, the engine models — and where authorized,
executes — reallocation of compute, capital, and agentic capacity.

**Sustainment**

Recalibrate pricing and prioritization as macroeconomic conditions and
technology cost curves move, particularly token economics, which can
invalidate a valuation model without any change in the initiatives it
ranks.

---

## D9. Architecture governance

*The capability to maintain architectural integrity — shifting from
gatekeeping review toward hyper-available clarity and anomaly-driven
architecture review.*

**Level A — Nascent**

Architecture governance does not exist in practice. Teams build in
isolation, producing semantic fragmentation and structural debt.
Architectural failures are handled reactively as incidents, with no
systemic review.

**Transition A → B — Establish a baseline and a reference**

Establish a review process and centralize documentation so that teams
have a single point of reference for architectural standards, and a
known moment at which conformance is examined.

**Verification:** A change was examined against a written standard
before release, and the standard existed before the change.

**Level B — Modeled**

Governance relies on periodic review boards and manual audits. Teams
submit static artifacts for evaluation, and compliance is enforced
through scheduled meetings rather than continuous visibility.

**Transition B → C — Replace policing with availability**

Make the architecture hyper-available through a traversable repository
and conversational tooling, so that teams align their intent before
execution rather than being corrected after it. Reserve governance
intervention for friction that rises above ordinary noise.

**Verification:** The proportion of review findings raised *before*
implementation exceeded those raised after, and teams can say what they
consulted.

**Level C — Continuous**

Governance rests on proactive clarity rather than policing. Because the
repository is available and traversable, teams align to the models
without being made to. Intervention is the exception: operational
friction or semantic misalignment above baseline triggers a review that
treats the friction as a symptom of a design flaw rather than a
violation to punish.

**Transition C → D — Detect the friction rather than wait for it**

Automate detection of systemic friction and repeated boundary hits, and
feed those anomaly signals into the architecture practice as review
triggers.

**Verification:** An architecture review was triggered by detected
friction rather than by a person noticing, and the trigger threshold was
set in advance.

**Level D — Integral**

The governance plane monitors for systemic anomalies. When friction
points or repeated boundary hits cluster around a capability or a
boundary, the system flags a probable defect in the ontology or the
capability map and triggers a targeted review of the root cause rather
than the symptom.

**Transition D → E — Measure the health of the graph itself**

Connect anomaly detection into a continuous loop measuring the overall
structural and semantic stability of the enterprise graph, not only
individual incidents.

**Verification:** A structural pattern spanning multiple unrelated
incidents was identified from the loop, and no single incident would
have revealed it.

**Level E — Telemetric**

Architecture governance is a self-diagnosing system. The practice tracks
**the rate and distribution of friction-triggered reviews across the
graph** as its own health measure. When structural patterns emerge,
agents model and propose ontological refactoring, capability
adjustments, or intent realignments that eliminate friction at its
source.

**Sustainment**

Refine the sensitivity threshold for what counts as actionable friction
against normal variance. Both failure modes are live at this level: a
threshold too tight produces chase, and a threshold too loose produces a
governance function that reports health while the estate fragments.

---

## D10. Shared language (*Vocabula*)

*The capability to hold one governed vocabulary for the enterprise's
working language — not the architecture's formal ontology — and
operate it in both directions: resolving a term inward to its precise
sense, and translating it outward with a record of what was
collapsed.*

**Level A — Nascent**

Terms are used without shared referents and nothing surfaces the
divergence. The same word means different things in different
functions, and the difference is discovered in rework — a launch built
for one population, a contract written about another. Either no
glossary exists, or one exists and nobody can say where. Outward-facing
language is written per document, in whatever voice the author has.

**Transition A → B — Name the terms and their senses**

Enumerate the terms that actually collide, each with its distinct
senses and the function that owns each sense. **The test of inclusion
is collision in practice, not importance in the abstract** — a term
nobody disputes does not need a row. Each sense states what it covers
and what it excludes, because a definition without an exclusion cannot
settle an argument.

**Verification:** A reader can establish, without asking the author,
that the enterprise distinguishes *customer*, *buyer* and *user*, and
what each one excludes.

**Level B — Modeled**

A governed vocabulary exists. Terms have senses, senses have owners,
and the document is findable. **Nothing consults it.** The definitions
are correct and inert — read when someone is already suspicious, which
is the case where they were least needed. Outward translation remains a
per-author judgment. **An organization at B typically believes it is
higher, because the artifact exists and is not wrong.**

**Transition B → C — Put the definition where the language is produced**

Bind the vocabulary to the surfaces where writing happens — the
editor, the ticket, the document, the agent's context — so the
definition **arrives at the moment of authorship** instead of waiting
to be looked up. An agent meeting an ambiguous term challenges it in
one interaction, **cites the vocabulary as the source of the
challenge**, and makes the answer cheap to give.

**Verification:** An author writing an ambiguous term is challenged as
they write it; the challenge names the vocabulary it came from; and
answering costs one click rather than a sentence.

**Level C — Continuous**

The vocabulary is active at the point of authorship. Ambiguity is
surfaced rather than discovered downstream, and the challenge cites its
source so the author can judge whether to trust it. **The author can
answer *loose sense, deliberately* and proceed.** Outward-facing
language is still handled term by term: nothing distinguishes a term
that must be translated for an external reader from one that may cross
unchanged.

**Transition C → D — Resolve what context settles, and invert the control at the boundary**

**Two moves, one capability.** *Inward:* give the agent enough governed
context — function, audience, document type — that a term whose sense
the context settles is **resolved rather than queried**, with the agent
stating which sense it used. **Asking is correct for genuine ambiguity
and is a tax everywhere else.** *Outward:* at the boundary the
operation inverts. An internal term leaving for an external reader is
not disambiguated, it is **translated**, and the translation **records
what it collapsed**.

**Verification:** For an internal document in a known function, the
agent resolves without asking and names the sense it used. For an
outbound document, the same term raises the reverse challenge — *this
word carries three senses inside and one outside; is the collapse
intended?* — and the answer is recorded with the document.

**Level D — Integral**

One vocabulary, two governed operations. Inside, terms resolve from
context and the agent states its reading, so precision is affordable
and traversal is deep — a term reaches its sense, its siblings and its
owner. At the boundary, translation is a controlled act whose
collapses are recorded with the document that made them, so a later
reader of the contract and a later reader of the press release can each
establish what was meant. **The distinction survives the crossing in
both directions.**

**Transition D → E — Measure the vocabulary against its own use**

Instrument both operations: where terms are queried, where they
resolve, where authors mark a sense deliberately loose, and where an
outbound translation is overridden. **Read the results as evidence
about the MODEL rather than about the authors.** A distinction
repeatedly waved away is one the enterprise does not hold.

**Verification:** A term is retired, merged or re-scoped on the
evidence of its own usage record, and the change is traceable to the
measurements that prompted it.

**Level E — Telemetric**

The vocabulary is a measured instrument. The enterprise can see which
distinctions its people operate and which they route around, and
corrects the model on that evidence rather than on advocacy. **Terms
are retired and merged as readily as they are added.** The outward
translation layer is tuned by what external readers actually misread,
not by what internal authors assume they will.

**Sustainment**

Reconcile the model against its own usage record on a standing
cadence, retiring distinctions nobody operates. Both failure modes are
live here: a term that matters only in rare documents reads as dead to
a record that counts volume, and one retired on aggregate waivers
takes the single function still using it.

---

### D1 / D2

- D1 governs **how architectural intent is formed and validated** — the
process and the human role within it.
- D2 governs **what the architecture is made of** — the artifacts and
the substrate they live in.
- A practice can run a mature process over a poor substrate, and a rich
substrate can be maintained by an immature process. Score them apart.

### D3 / D8

- D3 governs whether work **traces to business authority** — lineage and
intent.
- D8 governs how **scarce resources are allocated among** things that
all trace correctly.
- Valid lineage is a precondition for D8, not a substitute for it:
everything in a portfolio can be properly linked and still be the
wrong portfolio.

### D4 / D5

- D4 governs the **authoring of intent** and the trust placed in the
substrate by those who author it.
- D5 governs **consumption and participation** by those who operate
within it.
- The two move independently and often diverge: executive mandate
without unit participation produces a repository nobody uses, and unit
adoption without executive mandate produces a repository nobody obeys.

### D7 / D9

- D7 governs whether an actor **may act**, and over **which surfaces**.
- D9 governs whether the architecture itself remains **coherent**, and
treats friction as a symptom of a design flaw.
- An action can be fully authorized and still indicate an ontological
defect. That is D9's signal, not D7's.
- **Neither covers the security programme.** Data protection, secrets
hygiene, vendor risk, and regulatory security compliance are outside
this model's scope — stated as a boundary rather than left as an
absence.

---

## Strata — the architectural governance plane (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 feedback, and it returns to the stratum it bears on — Intent among them, rarely. Naming that stratum is part of the claim.

**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 the stratum they bear on — Intent among them, rarely — and naming that stratum is part of the claim (`SPEC-STRATA` v2.4). 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 machine-readable representation contract for the architecture corpus. Structured YAML headers encode artifact identity, type, relationships, governance, and other architectural metadata, allowing agents to build an in-memory graph, traverse it to determine relevant context, and load Markdown bodies only when needed. Corpus artifacts are Markdown documents carrying EA OKF headers.

## 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 represents and connects the architecture; it is not the architecture itself, and not one of the models. Each model is the actual product: a named Standard, expressed as structured, machine-readable governance rather than a one-off document. [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.