Secure Architecture (SA)

Vendors Domain - HAIAMM v3.5

Generated from the canonical cell records in cells/. Do not edit by hand; edit cells/SA-Vendors-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 vendors 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 vendors archetype once, so teams adopt rather than invent. The library covers the brokered-access pattern routing vendor AI through an organisational gateway, the data-minimisation pattern filtering before egress to the vendor, the fallback pattern surviving vendor unavailability, and the exit pattern keeping data portable by construction, 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 vendors 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 vendors archetype once, so teams adopt rather than invent. The library covers the brokered-access pattern routing vendor AI through an organisational gateway, the data-minimisation pattern filtering before egress to the vendor, the fallback pattern surviving vendor unavailability, and the exit pattern keeping data portable by construction, 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-Vendors-L1, TA-Vendors-L1, SR-Vendors-L1
• Alignment (not blocking): Enterprise architecture practice, so AI patterns extend the existing pattern estate rather than forming a separate library
• Supports / unblocks: DR-Vendors-L1; IR-Vendors-L1; ST-Vendors-L1; EH-Vendors-L1; Required by: SA-Vendors-L2

Desired Outcomes

• Every vendors 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 brokered-access pattern routing vendor AI through an organisational gateway, the data-minimisation pattern filtering before egress to the vendor, the fallback pattern surviving vendor unavailability, and the exit pattern keeping data portable by construction. 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 direct vendor API access from application code with credentials embedded, unfiltered organisational data sent to a vendor endpoint, and a vendor dependency with no fallback and no tested exit. 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
Vendors 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 new data class flowing to a vendor 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 vendors 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 vendors reference-pattern set by risk tier and scale the autonomy and oversight controls in each pattern with the asset's capability tier.

At this level the pattern library stops being one size fits all. Patterns carry a declared tier applicability, so a Critical-tier asset adopts the full set while a Low-tier one adopts a named subset, and the difference is a published decision rather than a team's discretion. The controls inside each pattern tighten as capability rises, so the same pattern demands more of an asset that acts than of one that only advises. Every incident reaching a root cause is checked against the library for a pattern that should have prevented it.

Dependencies

• Required: SA-Vendors-L1, SM-Vendors-L2, TA-Vendors-L2, SR-Vendors-L2
• Alignment (not blocking): Enterprise architecture governance, so AI patterns join the existing pattern estate
• Supports / unblocks: DR-Vendors-L2; IR-Vendors-L2; ST-Vendors-L2; EH-Vendors-L2; Required by: SA-Vendors-L3

Desired Outcomes

• Every pattern declares which tiers it applies to, so adoption scope is derived rather than negotiated.
• Controls inside each pattern scale with the asset's capability, demanding more of assets that act than of assets that advise.
• Deviations from a pattern are approved by a named authority with a recorded rationale and an expiry.
• Critical-tier assets follow a reference pattern or carry a full-lane review of their deviation, with no third option.
• Incidents are routinely checked against the library for a pattern that should have prevented them.

Activities

A) Declare tier applicability across the pattern library

Annotate every pattern in the library with the tiers it applies to and the tiers at which it is mandatory rather than recommended. Publish the mapping so that a team's pattern set is derived from the asset's tier rather than assembled by preference. At Critical tier, pattern adherence is mandatory and any deviation requires a full-lane design review with a named architect; at Low tier the pattern is recommended and deviation needs only a recorded note. Stating this removes the ambiguity that otherwise resolves in favour of whatever is quickest to build. Re-derive the applicable pattern set automatically when an asset's tier changes, because a Medium-to-Critical promotion that does not change the pattern obligations has changed nothing that matters.

B) Scale autonomy and oversight controls with capability tier

Within each pattern, define how its controls tighten as the asset's capability tier rises. Bound blast radius more tightly, shorten the autonomy budget between human checkpoints, and require a human gate on a new data class flowing to a vendor at higher capability tiers where lower tiers need only logging. Specify each gate numerically rather than in principle: who holds the authority to refuse, what information they receive, and how long they have. A gate specified as a principle is compressed under delivery pressure until scrutiny is impossible, and because nothing in the specification objects, the erosion is invisible. Publish a reviewer-load ceiling per tier above which review capacity must be added rather than reviewers exhorted, since a gate held by an overloaded reviewer is a gate in name only.

C) Run the incident-to-pattern learning loop

Establish a standing review that takes every incident reaching a root cause and asks two questions: was there a pattern that should have prevented this, and if so why was it not followed, or if not what pattern should now exist. Record the answer for every incident, including the answer that no pattern change is warranted, because the discipline of recording the negative case is what keeps the loop honest rather than performative. Where a pattern existed and was not followed, the finding belongs to the review and adoption practices rather than to the library. Where no pattern existed, author one and publish it within 60 days. Track the share of incidents attributable to a pattern that existed and was not followed, which separates a library problem from an adoption problem and is the single most useful number this practice produces.

Outcome Metrics (L2)

Metric	Baseline	L2 Target	Source
Patterns carrying a declared tier applicability	L1 pattern library	100% of published patterns	Pattern library metadata
Critical-tier assets following a reference pattern or carrying a full-lane deviation review	first tier conformance pass	≥95%, with no third category	Pattern adoption manifest joined to inventory tier
Pattern deviations carrying a named approver, recorded rationale and expiry	first deviation review	100%, with none past expiry	Deviation register
Incidents checked against the pattern library for a preventing pattern	first quarter of the loop	100% of incidents reaching root cause, including negative findings	Incident review record joined to the pattern library
Critical-tier assets carrying no unbounded autonomy budget	first autonomy audit	100%	Pattern conformance audit

Process Metrics (leading)

• Applicable pattern set re-derived automatically whenever an asset's tier changes.
• Incident-to-pattern review runs on every incident reaching root cause, with negative findings recorded.
• New patterns published within 60 days of an incident establishing the need.
• Reviewer load monitored against the published per-tier ceiling.

Effectiveness Metrics (business value)

• Pattern reuse rises relative to bespoke design, reported per tier.
• Incidents attributable to a pattern that existed and was not followed fall, separating library quality from adoption.
• Design review duration falls for assets adopting patterns unchanged.
• Deviation volume falls as patterns are refined to fit real delivery needs.

Oversight Metrics (the HAI control, measured)

Metric	Oversight failure it detects	Source
Reviewer override rate on pattern deviation requests, paired with sustained-override rate	deviation approval becoming automatic under delivery pressure, where pairing with sustained rate counters the gaming that follows once the rate becomes a target	Deviation decision log per reviewer
Design reviews per reviewer per week against the published ceiling	reviewer overload, where architectural scrutiny cannot survive the volume regardless of reviewer skill, which is a capacity defect rather than a personnel one	Design review assignment log
Critical-tier designs where the human gate on a new data class flowing to a vendor specifies authority, information and a time budget numerically	oversight specified as a principle rather than a number, which is compressed under delivery pressure until scrutiny is impossible and nothing objects	Pattern conformance audit of gate specifications

Level of Effort (incremental over the level below)

• Stand-up: 160 hours · Ongoing: 130 hours/quarter
• Security Architect — primary, 30 days/year
• AppSec / SecEng — regular, 16 days/year
• AI/ML Engineer — regular, 12 days/year
• DevOps / Platform Engineer — low, 8 days/year

Success Criteria

• Every pattern declares its tier applicability and whether it is mandatory or recommended at each tier.
• Controls within each pattern scale with capability tier, with every human gate specified numerically in authority, information and time.
• At least 95% of Critical-tier assets either follow a reference pattern or carry a full-lane deviation review, with no third category.
• Every incident reaching root cause is checked against the library, with negative findings recorded.
• A per-tier reviewer-load ceiling is published and monitored, and breaching it adds capacity rather than exhortation.

---

Maturity Level 3, Industry-Leading

Objective: Publish vendors 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-Vendors-L2, IR-Vendors-L2, ML-Vendors-L2
• Alignment (not blocking): Platform engineering ownership, since executable patterns ship through their scaffolding and tooling
• Supports / unblocks: Every other Vendors practice at L3, which inherits continuously verified architecture; Required by: DR-Vendors-L3, EH-Vendors-L3, IR-Vendors-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 a broker or gateway configuration that routes vendor access, filters the payload and applies limits, so using the vendor correctly is easier than integrating directly.

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 integration path and payload schema against the pattern, which catches the direct integration added for latency beside the sanctioned broker.

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. Vendor patterns contribute well as broker configurations and payload-filtering rules, which peers can adopt against the same small set of major providers.

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 vendors 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 declares its tier applicability and whether it is mandatory or recommended at each tier.
• Controls within each pattern scale with capability tier, with every human gate specified numerically in authority, information and time.
• At least 95% of Critical-tier assets either follow a reference pattern or carry a full-lane deviation review, with no third category.
• Every incident reaching root cause is checked against the library, with negative findings recorded.
• A per-tier reviewer-load ceiling is published and monitored, and breaching it adds capacity rather than exhortation.

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:

• ❌ Publishing patterns without tier applicability, which leaves adoption scope to resolve in favour of whatever is quickest to build.
• ❌ Specifying human gates as principles rather than numbers, so they compress invisibly under delivery pressure until scrutiny is impossible.
• ❌ Recording only the incidents that produced a pattern change, which makes the learning loop performative rather than honest.
• ❌ Conflating a pattern that was missing with a pattern that was ignored, which sends improvement effort to the wrong practice.
• ❌ Responding to reviewer overload with exhortation rather than capacity, which converts the gate into a formality.

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 vendors 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 Vendors, the assessor should be shown the brokered-access pattern and the data-minimisation filter.
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 Vendors, ask to see the brokered-access pattern and the data-minimisation filter.

Level 2:

1. Does every pattern declare its tier applicability and mandatory-versus-recommended status, with the applicable set re-derived automatically when an asset's tier changes? Evidence this in the Vendors domain against the brokered-access pattern and the data-minimisation filter.
2. Do the controls inside each pattern tighten as capability rises, with the human gate on a new data class flowing to a vendor specified numerically in authority, information and time budget rather than as a principle, and is a per-tier reviewer-load ceiling published?
3. Is every incident reaching a root cause checked against the library for a preventing pattern with negative findings recorded, and is the share attributable to an existing pattern not followed tracked separately from gaps in the library? In Vendors, ask to see the brokered-access pattern and the data-minimisation filter.

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 Vendors domain against the brokered-access pattern and the data-minimisation filter.
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 Vendors, the assessor should be shown the brokered-access pattern and the data-minimisation filter.
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 Vendors, ask to see the brokered-access pattern and the data-minimisation filter.

---

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 vendors 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 a high-risk AI asset have to follow a reference architecture?
• Does your architecture demand more of AI that acts than AI that advises?
• After an incident, does anyone ask whether a pattern should have prevented it?

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-vendors-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/vendors/, 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-vendors-l2, haiamm-building

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

Level 3 — Jira Epic, labels haiamm-sa-vendors-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	AML.T0010	LLM03	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	AML.T0010	LLM03	EU AI Act Art. 15; EU AI Act Art. 14; NIST AI RMF MANAGE 1.3; ISO/IEC 42001 8.1; ISO/IEC 27001 A.8.27
L3	EA	AML.T0010	LLM03	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: Vendors