Architecture governance

Every codebase has architectural taste, even if it only lives in one senior engineer's head. This dimension asks whether that taste — the patterns to follow, the ones to avoid, the reasons behind both — is something the organization actually has, in a form anyone (or any agent) can find and act on, or something that only exists as tribal memory.

Where most organizations start (Nascent)

Architectural standards exist only as tribal knowledge or informal convention, enforced inconsistently through manual review — meaning quality depends entirely on which reviewer happens to look at a given change. The first real step is externalizing that judgment: documented decisions, constraints, preferred and prohibited patterns, with a named owner for keeping the record current.

Where the real gains happen (Modeled → Integral)

The meaningful shift starts with encoding the most common and consequential violations as deterministic checks — linters, structural tests, CI gates — so consistency stops depending on which reviewer is on duty. From there, the bigger change is converting those checks from after-the-fact gates into something agents can read and apply during generation, with remediation guidance attached, so violations get caught before code exists rather than after.

Worth knowing about this step: the shift from encoded-but-partial checks to comprehensively agent-readable, generation-time architecture is a genuinely larger lift than its neighboring steps — flagged as a candidate "lumpy" transition, reviewed and confirmed rather than smoothed over. David's own review: "Steep but inescapable given current understanding, and maps to a correspondingly large reward for the cost."

What the top of the curve actually looks like (Telemetric)

At full maturity, agents don't just follow the encoded standard — they participate in evolving it. When an agent hits a pattern the rules don't cover, or notices a rule that's become a recurring obstacle, it proposes a change, with evidence, for human review. The architecture and the enforced standard co-evolve, with agents as contributors to that evolution, not just subjects of it.

Why this dimension matters

D6 sits over the seam between what gets built (D4, D5) and what gets verified (D7, D8) — it's the dimension that decides whether "good architecture" is a matter of luck-of-the-reviewer or something the system itself actually protects.

---

Drafted from the SDLC model's real locked content — including the transition and verification notes now folded into ai_native_sdlc_maturity_model.md itself (2026-07-27). D6's C→D "lumpy transition" question, named in this model's own Open Items, was reviewed and resolved 2026-07-24 — no open review flag remains.