Secure Architecture (SA)

Software Domain - HAIAMM v3.5

Generated from the canonical cell records in cells/. Do not edit by hand; edit cells/SA-Software-L*.cell.json and re-run tools/render.py.

---

Practice Overview

Business Function: Building

Objective: Publish reference architecture patterns and an antipattern catalogue for each software archetype, so the secure design is the default path rather than an achievement.

Description: A program at this level has drawn the secure shape of each software archetype once, so teams adopt rather than invent. The library covers the agent pattern with an explicit tool allowlist and per-tool argument schema validation, the RAG pattern separating instruction from retrieved content, the LLM-feature pattern with output handling for untrusted responses, and the fine-tuning pattern isolating training data from inference, and it is paired with an antipattern catalogue naming the shapes that recur and what to replace them with. An antipattern catalogue is the more useful half and the more commonly missing one: teams recognise what they are building far more readily than they recognise what they should have built. Every pattern states which threats it mitigates, so adoption is an argument rather than an instruction.

---

Maturity Level 1, Foundational

Objective: Publish reference architecture patterns and an antipattern catalogue for each software archetype, so the secure design is the default path rather than an achievement.

A program at this level has drawn the secure shape of each software archetype once, so teams adopt rather than invent. The library covers the agent pattern with an explicit tool allowlist and per-tool argument schema validation, the RAG pattern separating instruction from retrieved content, the LLM-feature pattern with output handling for untrusted responses, and the fine-tuning pattern isolating training data from inference, and it is paired with an antipattern catalogue naming the shapes that recur and what to replace them with. An antipattern catalogue is the more useful half and the more commonly missing one: teams recognise what they are building far more readily than they recognise what they should have built. Every pattern states which threats it mitigates, so adoption is an argument rather than an instruction.

Dependencies

• Required: SM-Software-L1, TA-Software-L1, SR-Software-L1
• Alignment (not blocking): Enterprise architecture practice, so AI patterns extend the existing pattern estate rather than forming a separate library
• Supports / unblocks: DR-Software-L1; IR-Software-L1; ST-Software-L1; EH-Software-L1; Required by: SA-Software-L2

Desired Outcomes

• Every software archetype has a published reference pattern a team can adopt rather than design.
• An antipattern catalogue names the recurring insecure shapes and states what replaces each one.
• Every pattern states which threats it mitigates, so adoption rests on an argument rather than authority.
• Untrusted content is handled by a documented pattern rather than by each team's judgment.
• Teams can tell at design time whether what they are building matches a sanctioned shape.

Activities

A) Publish reference patterns per archetype

Author one reference pattern per archetype, covering the agent pattern with an explicit tool allowlist and per-tool argument schema validation, the RAG pattern separating instruction from retrieved content, the LLM-feature pattern with output handling for untrusted responses, and the fine-tuning pattern isolating training data from inference. Each pattern states the components and their boundaries, the controls at each boundary, the threats it mitigates by identifier from the TA library, the requirements it satisfies from the SR pack, and the conditions under which it does not apply. Keep each pattern to a length a team reads before designing rather than after, targeting three pages with a diagram. Validate each with an engineer who has built that archetype, because a pattern authored entirely within security describes a system that is secure and unbuildable, and teams respond to that by ignoring it rather than by arguing. Publish patterns in the repository where the work happens rather than in a separate architecture space.

B) Publish the antipattern catalogue

Author an antipattern catalogue naming the insecure shapes that actually recur in this domain, being the agent with an implicit tool surface, the RAG pipeline that concatenates retrieved text into the instruction position, and the long-session agent with no memory bound or session boundary. For each antipattern, state why it is attractive, since it is always attractive for a reason and a catalogue that does not acknowledge that reads as naive; what specifically goes wrong; and which reference pattern replaces it. The antipattern half of the library is the more useful and the more commonly omitted, because teams recognise the thing they are building far more readily than they recognise the thing they should have built instead. Draw the catalogue from real designs seen in review rather than from literature, and add to it whenever review encounters a new recurring shape.

C) Establish the untrusted-content boundary and a design-time self-check

Document explicitly where untrusted content enters each archetype and how it is kept separate from instruction, control and identity. This is the single most consequential architectural decision in AI systems and the one most often left implicit, because the failure it prevents, content becoming instruction, does not look like a boundary violation in any conventional sense. State the pattern for isolation, for provenance marking, and for what the system must never do with content it did not author. Publish a short design-time self-check, at most ten questions, that a team can answer before requesting review, which both raises the quality of what arrives at review and tells the team what the review will ask, removing the asymmetry that makes design review feel arbitrary.

Outcome Metrics (L1)

Metric	Baseline	L1 Target	Source
Software archetypes with a published reference pattern	first pattern authoring round	≥85% of inventoried archetypes within 9 months	Pattern library register joined to the asset inventory
Patterns stating the threats they mitigate by TA identifier and the requirements they satisfy	first pattern audit	100% of published patterns	Pattern library traceability audit
Antipatterns in the catalogue drawn from designs actually seen in review	first catalogue build	≥8 antipatterns, each traced to an observed design	Antipattern catalogue with review references
Archetypes with a documented untrusted-content boundary	first boundary pass	100% of archetypes that ingest content the organisation does not author	Pattern library boundary section audit
Designs arriving at review having completed the design-time self-check	first quarter after publication	≥70%	Design review intake records

Process Metrics (leading)

• Every pattern validated with an engineer who has built that archetype, recorded per pattern.
• Antipattern catalogue extended whenever review encounters a new recurring shape.
• Patterns reviewed at least annually, with the review date published.
• Self-check completion tracked at design review intake and fed back to teams.

Effectiveness Metrics (business value)

• Pattern reuse rises relative to bespoke design, which is the primary outcome the library exists to produce.
• Design review findings relating to known antipatterns fall as the catalogue circulates.
• Time from design start to review-ready falls for teams adopting a pattern unchanged.

Oversight Metrics (the HAI control, measured)

Metric	Oversight failure it detects	Source
Share of designs where the reviewer recorded a required change before approval	rubber-stamping at design review, where approval is recorded without the review having altered anything, which is the default state of a review with no capacity to say no	Design review decision log with change records
Designs approved with a human gate declared on a side-effecting tool call but no stated refusal authority	a gate that exists structurally while the person holding it cannot actually refuse, which satisfies the control on paper and not in fact	Pattern conformance review of gate specifications

Level of Effort (incremental over the level below)

• Stand-up: 180 hours · Ongoing: 80 hours/quarter
• Security Architect — primary, 30 days/year
• AppSec / SecEng — regular, 14 days/year
• AI/ML Engineer — regular, 12 days/year
• DevOps / Platform Engineer — low, 6 days/year

Success Criteria

• A reference pattern exists for at least 85% of inventoried software archetypes, each validated with an engineer who has built that archetype.
• Every pattern states the threats it mitigates by TA identifier and the requirements it satisfies.
• An antipattern catalogue of at least eight entries is published, each drawn from a design actually seen in review and naming its replacement pattern.
• Every archetype ingesting content the organisation does not author has a documented untrusted-content boundary.
• A design-time self-check of at most ten questions is published and completed by at least 70% of designs arriving at review.

---

Maturity Level 2, Comprehensive

Objective: Calibrate the reference-pattern set by risk tier and make the autonomy controls in each pattern scale with the asset's capability tier.

At L2 the pattern library stops being one-size-fits-all. Patterns carry a declared tier applicability, so a Critical-tier agent platform adopts the full set while a Low-tier LLM-integrated feature adopts a named subset, and the difference is a published decision rather than a team's discretion. The autonomy controls inside each pattern -- approval gates on side-effecting actions, bounded blast radius, an autonomy-step budget between human checkpoints -- tighten as the asset's capability tier rises, so the same pattern demands more of a tool-using agent than of a retrieval-only assistant. Patterns are version-controlled artifacts with owners, and every incident that reaches a root cause is checked against the library for a pattern that should have prevented it.

Dependencies

• Required: SA-Software-L1, SR-Software-L2, SM-Software-L2, PC-Software-L2
• Alignment (not blocking): Platform engineering paved-road program; Cloud landing-zone standards
• Supports / unblocks: DR-Software-L2; IR-Software-L2; ST-Software-L2; EH-Software-L2; Required by: SA-Software-L3

Desired Outcomes

• Every published pattern carries a declared tier applicability and a named owner.
• Critical-tier software assets use the full pattern set; lower tiers use a documented subset with the delta recorded as an accepted risk.
• Autonomy controls inside each pattern scale with the asset's capability tier rather than being uniform.
• Pattern adoption is visible per asset without asking the team that built it.
• Incidents with a root cause trace to either a pattern gap or a pattern-adoption gap, and the library carries the resulting change.

Activities

A) Declare tier applicability across the pattern library

For each pattern in the L1 library, publish a tier-applicability row: which of Critical, High, Medium and Low must adopt it, and what a compliant subset looks like for the tiers that do not. Derive applicability from the SM-Software L2 tier rubric rather than from author preference, so two reviewers reach the same answer. Where a pattern is mandatory only above a threshold, state the threshold in the pattern itself, not in a separate matrix that will drift. Record for each pattern a named owner accountable for its currency, and a review date no more than twelve months out. Teams building a Medium-tier or Low-tier asset must be able to read the library and know, without a meeting, which patterns are binding on them and which are optional. Publish the tier-applicability rows alongside the patterns in the same repository so a single pull request changes both.

B) Scale autonomy controls to the asset's capability tier

Extend every pattern that governs a side-effecting or tool-using asset with an escalating autonomy-control block keyed to the asset's capability tier. At minimum: any asset that takes an action with effects outside itself requires an approval gate on that class of action; higher-autonomy assets additionally require an enforced blast-radius scope and a declared autonomy-step budget bounding how many sequential actions may run between human checkpoints; the highest tier additionally requires verification by a party independent of the build team. Express each requirement as a configuration or IaC assertion a reviewer can check, not as guidance. Critically, the approval gate must specify what makes the gate real -- who approves, at what volume, and with what authority to refuse -- because an approval step satisfied by an approver who has never refused is not a control. Pair the block with the oversight metrics below so the gate's effectiveness is observed rather than assumed.

C) Run the incident-to-pattern learning loop

Establish a standing review, at least quarterly and additionally after any Critical or High severity AI incident, in which the pattern owners walk the period's incidents and findings from IM-Software and ST-Software and classify each root cause into one of three dispositions: no pattern existed and one is now required; a pattern existed and was not adopted; a pattern existed, was adopted, and failed. Each disposition has a different remedy -- author, enforce, or revise -- and each produces a tracked change with an owner and a due date. Record the disposition on the incident record itself so the loop is auditable in both directions. Version every resulting pattern change and note in the changelog which incident drove it, so a reader can see the library learning. A quarter in which no incident produced a disposition is itself a finding: either the loop is not running or incident root-causing is not reaching design.

Outcome Metrics (L2)

Metric	Baseline	L2 Target	Source
% of Critical-tier software assets adopting the full mandated pattern set	38%	>=95% of Critical-tier and >=80% of High-tier, trending up quarter over quarter	Architecture repo pattern-adoption manifest reconciled against SM-Software inventory
% of patterns carrying a current tier-applicability row and named owner	0%	100%, with no pattern past its review date	Pattern registry in the architecture repository
% of tool-using assets whose autonomy controls match their capability tier	measure at first reconciliation	>=90% at Critical and High tier; zero Critical-tier assets with an unbounded autonomy-step budget	Orchestrator and IaC configuration reconciled against the pattern's autonomy block
Incidents with a root cause that produced a pattern disposition within 30 days	measure at first quarterly review	>=90% of Critical and High severity incidents, trending up	Incident tracker disposition field cross-referenced with the pattern changelog

Process Metrics (leading)

• Pattern review meetings held per quarter against the target cadence
• Median age of a pattern at time of review, in days
• Open pattern-change items past their due date

Effectiveness Metrics (business value)

• Reduction in repeat design-caused findings across DR and IR for the same root cause
• Reduction in median design-review cycle time for assets that adopt patterns from the library
• Proportion of new Critical-tier assets that pass design review on first submission

Oversight Metrics (the HAI control, measured)

Metric	Oversight failure it detects	Source
Approver override rate on gated side-effecting actions, per approver, per quarter	Rubber-stamping. An approval gate whose approver has never refused is a logging step wearing the costume of a control, and it satisfies every boolean check the pattern makes.	Approval system decision log joined to the orchestrator action log
Approval volume per approver per day, and median decision latency on gated actions	Approver overload. Scrutiny does not survive volume; an approver clearing hundreds of items a day is not reviewing them, and latency in the low seconds is the observable signature.	Approval system decision log
Proportion of Critical-tier assets whose approver is credentialed for that asset class	Unqualified oversight. A human is in the loop but lacks the context to recognise the failure the gate exists to catch, so the gate passes traffic it should stop.	EG-Software reviewer credential registry joined to the asset inventory

Level of Effort (incremental over the level below)

• Stand-up: 120 hours · Ongoing: 40 hours/quarter
• Security Architect — primary, 12 days/year
• AI/ML Engineer — regular, 5 days/year
• AppSec / SecEng — regular, 4 days/year
• DevOps / Platform Engineer — regular, 4 days/year
• Program Manager / Practice Lead — low, 2 days/year
• Material new tooling: Pattern-adoption reconciliation job (build or extend an existing IaC scanner)

Success Criteria

• Every pattern in the library carries a tier-applicability row, a named owner, and a review date within twelve months.
• Critical-tier pattern adoption is at or above 95% and is evidenced from the adoption manifest, not from team self-report.
• Every tool-using asset above the lowest capability tier has a declared, enforced autonomy-step budget and an approval gate on side-effecting actions.
• Approver override rate and approval volume are reported per quarter for every gated action class, and an out-of-range value opens a tracked item.
• The quarterly incident-to-pattern review has run for two consecutive quarters with recorded dispositions traceable to pattern changes.

---

Maturity Level 3, Industry-Leading

Objective: Publish software patterns as executable artifacts adopted by default, verify conformance continuously, and contribute the pattern library back to the field.

At this level patterns are adopted because they are the path of least resistance rather than because they are mandated. Patterns ship as executable artifacts, being infrastructure modules, scaffolds or libraries, so adopting the secure shape is faster than building a bespoke one. Conformance is verified continuously against the running system rather than assessed at review, which closes the gap between the design that was approved and the system that exists. The library is contributed back in executable form, where peers can adopt it rather than only read it.

Dependencies

• Required: SA-Software-L2, IR-Software-L2, ML-Software-L2
• Alignment (not blocking): Platform engineering ownership, since executable patterns ship through their scaffolding and tooling
• Supports / unblocks: Every other Software practice at L3, which inherits continuously verified architecture; Required by: DR-Software-L3, EH-Software-L3, IR-Software-L3

Desired Outcomes

• Patterns ship as executable artifacts, so the secure shape is faster to adopt than a bespoke one.
• Conformance is verified continuously against the running system rather than assessed at design time.
• Architecture drift between the approved design and the running system is detected in days.
• The pattern library is contributed back in executable form that peers can adopt directly.
• Pattern adoption is driven by convenience rather than by mandate.

Activities

A) Ship patterns as executable artifacts

Convert each reference pattern into something a team runs rather than reads: infrastructure modules, project scaffolds, libraries or configuration bundles that instantiate the pattern correctly by default. This is the level's central move and the one that changes adoption economics, because a pattern that is faster to adopt than to circumvent is adopted without enforcement, and no amount of mandate achieves what convenience achieves. Version the artifacts, publish their change history, and provide a migration path when a pattern changes so that existing adopters are not stranded on an old version, which is the most common reason executable pattern libraries decay. Measure adoption of the artifact rather than conformance to the document, since the artifact is now the pattern. In this domain the executable artifact is usually a project scaffold or an SDK wrapper that instantiates tool allowlisting, argument validation and session bounds by default, so the secure agent is the one that takes least effort to start.

B) Verify conformance continuously against the running system

Verify that what is running still matches the pattern that was approved, continuously rather than at review. Draw the signals from configuration state, runtime telemetry and the deployment pipeline, and evaluate each pattern's invariants as checks that can fail. Architecture drift is the defining failure of this practice at scale: designs are reviewed once and systems change continuously, so a library verified only at design time describes the past. Publish a service level covering detection of a Critical-tier conformance breach within 5 business days, and route breaches to the issue-management practice with tier-appropriate severity rather than to a report nobody owns. Where an invariant cannot be checked automatically, list it explicitly so the verification's real reach is known. Conformance verification reads the running tool manifest, the active prompt template and the model reference, comparing them against what the pattern declares, which catches the tool added after review.

C) Contribute the executable pattern library back

Contribute at least four substantive artifacts per year, weighted toward executable form: reference implementations, infrastructure modules, scaffolds and the conformance checks that verify them. Executable contributions carry disproportionate value in this practice, because a peer organisation can adopt a module and can only read a diagram, and the adoption gap between the two is the difference between influencing the field and describing it. Work through OpenSSF AI, CNCF where infrastructure applies, OWASP projects and sector bodies. Count only accepted artifacts, review each legally before release, and prefer contributing the patterns with the highest internal adoption, since those carry the most operational evidence and are the most likely to survive contact with another organisation's environment. Software patterns contribute well because the agent and RAG shapes are near-universal, and a reference implementation transfers across organisations with little adaptation.

Outcome Metrics (L3)

Metric	Baseline	L3 Target	Source
Reference patterns shipped as executable artifacts rather than documents alone	L2 pattern library	≥80% of patterns	Pattern artifact registry
New assets adopting the executable pattern artifact at creation	first quarter after publication	≥75% of new Critical- and High-tier assets	Scaffold and module adoption telemetry
Pattern invariants verified continuously against the running system	first verification pass	≥85%, with unverifiable invariants listed explicitly	Conformance verification registry
Time to detect a Critical-tier architecture conformance breach	L2 review cadence	≤5 business days at the 90th percentile	Conformance verification event log
Accepted external contributions per year in executable form	0	≥4 accepted, majority executable	Contribution log with acceptance references

Process Metrics (leading)

• Pattern artifacts versioned with a published migration path on every breaking change.
• Conformance verification runs continuously, with feed freshness monitored and alerted.
• Unverifiable-invariant list reviewed quarterly with an explicit reduction target.
• Contribution pipeline carries at least two executable artifacts in draft or review.

Effectiveness Metrics (business value)

• Bespoke architecture for Critical- and High-tier assets falls toward zero as the executable path becomes the fast path.
• Architecture drift incidents fall, which is the outcome continuous verification exists to produce.
• Time from project start to a conformant running system falls, reported for new assets.
• External adoption of contributed modules by peer organisations.

Oversight Metrics (the HAI control, measured)

Metric	Oversight failure it detects	Source
Pattern deviations later implicated in an incident, as a share of deviations approved	deviation approval that is procedurally correct and substantively wrong, which only post-hoc linkage to incidents can reveal	Incident root-cause analysis joined to the deviation register
Automated pattern conformance checks overridden by a human, with the override sustained	automation override becoming the routine path around a check that is inconvenient rather than wrong, which is how enforced patterns quietly become advisory	Pipeline conformance override log
Reviewer disagreement rate on a blind double-review sample of Critical-tier designs	reviewer drift, where the same design would be approved by one architect and refused by another, making the gate a lottery rather than a control	Double-review calibration records

Level of Effort (incremental over the level below)

• Stand-up: 240 hours · Ongoing: 120 hours/quarter
• Security Architect — primary, 24 days/year
• DevOps / Platform Engineer — regular, 26 days/year
• AppSec / SecEng — regular, 16 days/year
• AI/ML Engineer — low, 8 days/year
• Material new tooling: Executable pattern artifacts in the platform scaffolding, Continuous conformance verification against configuration and runtime state

Success Criteria

• At least 80% of reference patterns ship as executable artifacts with versioning and a migration path on breaking change.
• At least 75% of new Critical- and High-tier assets adopt the executable artifact at creation.
• At least 85% of pattern invariants are verified continuously against the running system, with unverifiable invariants listed explicitly.
• Critical-tier conformance breaches are detected within 5 business days and routed to issue management with tier-appropriate severity.
• At least four accepted external contributions per year, the majority executable rather than documentary.

---

Key Success Indicators

Level 1:

• A reference pattern exists for at least 85% of inventoried software archetypes, each validated with an engineer who has built that archetype.
• Every pattern states the threats it mitigates by TA identifier and the requirements it satisfies.
• An antipattern catalogue of at least eight entries is published, each drawn from a design actually seen in review and naming its replacement pattern.
• Every archetype ingesting content the organisation does not author has a documented untrusted-content boundary.
• A design-time self-check of at most ten questions is published and completed by at least 70% of designs arriving at review.

Level 2:

• Every pattern in the library carries a tier-applicability row, a named owner, and a review date within twelve months.
• Critical-tier pattern adoption is at or above 95% and is evidenced from the adoption manifest, not from team self-report.
• Every tool-using asset above the lowest capability tier has a declared, enforced autonomy-step budget and an approval gate on side-effecting actions.
• Approver override rate and approval volume are reported per quarter for every gated action class, and an out-of-range value opens a tracked item.
• The quarterly incident-to-pattern review has run for two consecutive quarters with recorded dispositions traceable to pattern changes.

Level 3:

• At least 80% of reference patterns ship as executable artifacts with versioning and a migration path on breaking change.
• At least 75% of new Critical- and High-tier assets adopt the executable artifact at creation.
• At least 85% of pattern invariants are verified continuously against the running system, with unverifiable invariants listed explicitly.
• Critical-tier conformance breaches are detected within 5 business days and routed to issue management with tier-appropriate severity.
• At least four accepted external contributions per year, the majority executable rather than documentary.

---

Common Pitfalls

Level 1:

• ❌ Authoring patterns entirely within security, producing designs that are secure and unbuildable, which teams ignore rather than contest.
• ❌ Publishing reference patterns without an antipattern catalogue, omitting the half teams actually recognise themselves in.
• ❌ Writing an antipattern catalogue that does not acknowledge why each shape is attractive, which reads as naive and is dismissed.
• ❌ Leaving the untrusted-content boundary implicit, which is the most consequential architectural decision in AI systems and the least conventional-looking.
• ❌ Publishing patterns in a separate architecture space rather than where the work happens, after which they are found only by people already looking.

Level 2:

• ❌ Tier applicability published as a separate matrix that drifts from the patterns it governs.
• ❌ Autonomy controls written as guidance rather than as configuration assertions a reviewer can check.
• ❌ Treating the approval gate as satisfied by its existence, with no measurement of whether the approver ever refuses.
• ❌ Adoption measured by asking teams whether they adopted the pattern.
• ❌ An incident review that produces discussion but no versioned pattern change with an owner.

Level 3:

• ❌ Shipping executable patterns without a migration path, which strands existing adopters on old versions and is the usual cause of library decay.
• ❌ Verifying conformance only at design time, which describes the past while the running system changes continuously.
• ❌ Measuring conformance to the document after the artifact has become the real pattern, which measures the wrong thing.
• ❌ Leaving unverifiable invariants unlisted, so the verification's actual reach is unknown and overstated.
• ❌ Contributing diagrams rather than modules, which peers read and do not adopt.

---

Practice Maturity Questions

Level 1:

1. Does a reference pattern exist for at least 85% of inventoried software archetypes, each stating components, boundaries, controls, the threats it mitigates by TA identifier, the requirements it satisfies and where it does not apply, validated with an engineer who has built that archetype?
2. Is there an antipattern catalogue of at least eight entries drawn from designs actually seen in review, each stating why the shape is attractive, what goes wrong, and which reference pattern replaces it? For Software, the assessor should be shown the agent reference pattern and the antipattern it replaces.
3. Does every archetype ingesting content the organisation does not author have a documented untrusted-content boundary, and is a design-time self-check published and completed by at least 70% of designs arriving at review? In Software, ask to see the agent reference pattern and the antipattern it replaces.

Level 2:

1. Is every pattern in the library published with a tier-applicability row derived from the SM-Software L2 risk rubric, a named accountable owner, and a review date, with no pattern currently past that date?
2. Do the patterns governing tool-using assets carry autonomy controls that escalate with capability tier -- approval gates on side-effecting actions, enforced blast-radius scope, and a declared autonomy-step budget -- and can you evidence conformance from configuration rather than self-report?
3. Has the incident-to-pattern review run for at least two consecutive quarters, with each Critical or High severity root cause carrying a recorded disposition traceable to a versioned pattern change?

Level 3:

1. Do at least 80% of reference patterns ship as executable artifacts with versioning and a migration path, and do at least 75% of new Critical- and High-tier assets adopt the artifact at creation rather than adopting the document? Evidence this in the Software domain against the agent reference pattern and the antipattern it replaces.
2. Are at least 85% of pattern invariants verified continuously against the running system with unverifiable invariants listed explicitly, and are Critical-tier breaches detected within 5 business days and routed to issue management? For Software, the assessor should be shown the agent reference pattern and the antipattern it replaces.
3. Does the organisation contribute at least four accepted artifacts per year in majority-executable form, prioritising the patterns with the highest internal adoption and therefore the most operational evidence? In Software, ask to see the agent reference pattern and the antipattern it replaces.

---

Lightweight Questions (E0 rung)

Answerable yes/no by one person in under 30 seconds, with nothing open.

Level 1:

• Is there a reference architecture for each kind of AI software asset?
• Can a team tell at design time whether their shape is sanctioned?
• Is it documented where untrusted content enters your AI systems?

Level 2:

• Does each published pattern say which risk tiers must adopt it?
• Do your higher-autonomy AI assets face stricter controls than your read-only ones?
• Has a pattern changed in the last two quarters because of an incident?

Level 3:

• Can a team adopt your secure architecture by running something rather than reading something?
• Would you detect a running system drifting from its approved design?
• Have you published an architecture module others can actually deploy?

---

Tracking

Level 1 — Jira Epic, labels haiamm-sa-software-l1, haiamm-building

• Done when: Reference pattern coverage at or above 85% of inventoried archetypes with full threat traceability and an antipattern catalogue of at least eight observed entries, sustained two consecutive quarters.
• Git artifacts: architecture/patterns/software/, architecture/patterns/index.json, architecture/antipatterns.json
• Git signal: Every pattern file carries a commit within its annual review interval and a recorded practitioner validation, and antipatterns.json references the review record each entry was drawn from.
• CI check: pattern-library-freshness

Level 2 — Jira Epic, labels haiamm-sa-software-l2, haiamm-building, haiamm-oversight

• Done when: Critical-tier pattern adoption reported at or above 95% from the adoption manifest for two consecutive quarters, with zero Critical-tier assets carrying an unbounded autonomy-step budget.
• Git artifacts: architecture/patterns/*.md, architecture/patterns/tier-applicability.json, architecture/pattern-adoption.json
• Git signal: Every pattern file has a commit within its declared review interval, and pattern-adoption.json is regenerated by CI on each main-branch build rather than edited by hand.
• CI check: pattern-adoption-reconcile

Level 3 — Jira Epic, labels haiamm-sa-software-l3, haiamm-building

• Done when: Executable pattern coverage at or above 80% with new Critical and High tier asset adoption at or above 75% and continuous invariant verification at or above 85%, sustained two quarters.
• Git artifacts: architecture/patterns/artifact-registry.json, architecture/conformance-checks/, governance/contribution-log.json
• Git signal: Pattern artifacts are versioned in the platform scaffolding with a migration note per breaking change, and conformance checks emit results per evaluation rather than per review.
• CI check: architecture-conformance-continuous

---

Mappings

Level	HAI TTP	ATLAS	OWASP LLM 2025	Compliance
L1	EA, AGH, TM, RA	AML.T0051, AML.T0053	LLM01, LLM05, LLM06	EU AI Act Art. 15; EU AI Act Art. 9; NIST AI RMF MAP 2.3; ISO/IEC 42001 8.1; ISO/IEC 27001 A.8.27
L2	EA, TM, AGH	AML.T0051, AML.T0053	LLM01, LLM05, LLM06, LLM08	EU AI Act Art. 14; EU AI Act Art. 26; ISO/IEC 42001 8.3
L3	EA, AGH, TM, RA	AML.T0051, AML.T0053	LLM01, LLM05, LLM06	EU AI Act Art. 15; EU AI Act Art. 17; NIST AI RMF MANAGE 1.3; ISO/IEC 42001 8.1; ISO/IEC 42001 9.1

---

Document Version: HAIAMM v3.5 (generated) / Practice: Secure Architecture (SA) / Domain: Software