Mind map of the Reference Taxonomy for Governed AI Systems
A conceptual view of the proposed reference taxonomy.

How to read the figure. The domains are different views of one governed system, not a sequence of implementation steps. The relationships are intentionally many-to-many: a capability may have several implementations; a risk may affect several capabilities; evidence may support several controls and decisions. Lifecycle and change cut across the map because a previously valid decision can become stale when an implementation, assumption or external requirement changes.

What the figure does not claim. It does not define mandatory control ownership, prove that every AI system needs every entity, replace a system architecture, or reproduce the terminology of ISO/IEC 42001, NIST AI RMF or the EU AI Act. It is a normalization layer intended to let those views coexist.

The taxonomy problem

An AI agent calling an external service can simultaneously be described as a tool call, API integration, privileged action, data transfer, trust boundary, third-party dependency, risk and auditable event. These descriptions are not contradictory. They answer different questions.

This becomes an operational problem when architecture, security, privacy and compliance maintain separate models. The architect sees components and dependencies. Security sees identities, privileges and trust boundaries. Privacy sees purposes, data flows and recipients. GRC sees risks, controls and evidence. Engineering sees APIs, models and failure modes. Management sees capabilities, costs and outcomes.

NIST AI RMF 1.0 already treats AI risk management as a lifecycle activity organised around GOVERN, MAP, MEASURE and MANAGE. ISO/IEC 42001:2023 establishes an AI management system with continual improvement. The EU AI Act adds legal obligations that, depending on role and risk classification, include risk management, technical documentation, record-keeping, transparency and human oversight. These sources support the need for connected governance views. They do not prescribe the taxonomy proposed here.

Start with capabilities, not products

I separate what the system needs to do from which implementation currently does it. A model provider, orchestration framework, vector store or protocol can be important, but it is a replaceable implementation choice. Reasoning, orchestration, retrieval, memory, tool execution, identity, policy enforcement, evaluation, observability, evidence collection and human approval are more stable capability concepts.

This is a design hypothesis rather than a regulatory requirement. Its value is testable: if replacing a vendor forces the conceptual architecture and governance model to be redrawn, the model probably mixed capability and implementation too early.

Five knowledge objects

These are research terms in this taxonomy, not canonical categories from ISO or NIST. The distinction is useful because a repository, paper or product can contribute more than a tool: it can expose a reusable pattern, a control mechanism or knowledge that changes an architectural decision.

Governance is part of the architecture

If an agent can execute code, a component diagram is insufficient for governance. I also need to know the risk introduced by that capability, the decision that allowed it, the controls that bound it, the evidence used to assess those controls, the responsible roles, and the assumptions under which the decision remains valid.

This is consistent with the direction of authoritative sources without being equivalent to them. NIST AI RMF connects governance with mapping, measurement and risk treatment. ISO/IEC 42001 connects policy, objectives, risk management and continual improvement. For high-risk systems within its scope, the EU AI Act requires lifecycle risk management and logging, and requires human oversight measures proportionate to risk, autonomy and context. My additional claim is that these governance objects should be addressable in the architecture model itself rather than stored only as parallel documents.

Decisions have a lifecycle

A model can be approved because data remains in an accepted region, contractual training terms are acceptable, a certification is current, technical limits meet the use case and cost is within tolerance. The approval is therefore conditional on assumptions. A change to one assumption is a reason to reassess the decision, not proof that the system has become unsafe.

I model candidate, qualification, adoption, monitoring, change, review, deprecation and replacement as lifecycle states. The exact states are proposed. The underlying need for ongoing monitoring and reassessment is better established: NIST AI RMF is lifecycle-oriented, ISO/IEC 42001 requires continual improvement, and the EU AI Act contains post-market monitoring obligations for relevant regulated systems.

Three relationships that became explicit

Recent work on governed agent systems makes three relationships important enough to model directly without turning them into additional top-level domains.

  • Authority: a capability connects to an action through an authority relationship. Possessing or discovering a capability does not mean that the current actor is eligible, authorized, or permitted to execute it. A useful chain is Capability → Eligibility → Authority → Action.
  • State and commitment: an action can create a durable state transition or commitment. That transition can carry recovery cost, evidence obligations and limits on what the system may do next. Transport-session state, application state and governed durable state should remain distinguishable.
  • Qualified operating envelope: approval should attach to the evaluated system tuple and conditions under which it was shown to work, rather than to a product name alone. The envelope connects implementation, model/runtime, controls, task class, evidence, reliability, cost and timing constraints.

These relationships make several otherwise hidden questions queryable: who may convert an assessment into an effect, which commitments become hard to reverse, and whether a fallback is actually qualified for the same operating conditions.

Evidence became part of the model

The taxonomy now treats evidence as a graph relationship rather than a bibliography attached after an architecture decision. A material publication claim should be traceable through source → exact evidence → claim → architecture decision → qualification → publication wording. This matters because different source classes answer different questions. Regulation can establish an obligation, a benchmark can test an outcome, a research paper can support a mechanism, and an implementation can demonstrate feasibility.

Recent evidence also sharpened two boundaries. EG-VQA shows in a multimodal benchmark that answer correctness and evidence grounding can diverge, which supports the more general qualification rule correct output ≠ evidence-grounded qualified outcome. Mitchell, Ghosh and Passi argue that the presence of a human does not itself establish meaningful oversight, reinforcing human present ≠ meaningful human oversight. These findings do not replace standards; they support architecture claims that standards alone do not empirically validate.

Normalize controls without losing their sources

Integrated governance also needs a distinction between an external requirement and the internal control model used to implement it. Malcolm Shore's TACO proposal is useful here: overlapping requirements from ISO/IEC 42001, NIST AI RMF, the EU AI Act and ISACA guidance can be normalized into common control objectives while retaining mappings back to the originating sources. The practitioner model also separates process maturity from control effectiveness.

I treat this as architecture evidence, not as a new standard. The compact rule is normalized control ≠ originating obligation. A common control model can reduce duplication, but it must preserve provenance, applicability and source-specific compliance testing.

Why the model is a graph

A strict tree breaks when one capability uses several tools, one control mitigates several risks, one piece of evidence supports several controls, or one regulatory requirement affects several decisions. The graph representation is therefore a modelling choice based on relationship cardinality, not a claim that a graph database is required.

The practical query becomes: which capabilities do we depend on, how are they implemented, which decisions selected them, which risks and controls follow, who has authority to turn them into consequential actions, what state those actions create, and what evidence tells us whether the assumptions and qualification envelope are still valid?

Claim boundaries

  • Established: AI governance needs lifecycle risk management, accountability, documentation and evidence appropriate to context. Current NIST, ISO and EU sources support these concerns.
  • Supported synthesis: separating capability from implementation improves portability and impact analysis. This follows established architecture practice, but the exact entity set and relationship model here have not been standardized.
  • Supported refinement: evidence grounding and effective human oversight should be qualified separately from answer correctness and nominal reviewer presence. Current research supports these distinctions, but the exact Harness mechanisms remain architecture synthesis.
  • Hypothesis: a common graph of capabilities, implementations, decisions, risks, controls, evidence, responsibilities, authority, state transitions and qualification relationships can reduce translation loss between engineering and GRC.
  • Not claimed: regulatory compliance, completeness, universal applicability, or superiority to every enterprise architecture or ontology method.

Limitations and falsification

This version has not been validated against a statistically representative set of organisations or AI architectures. The vocabulary is biased toward systems where AI components interact with tools, data, external services and governance processes. Small embedded models and highly specialised safety-critical systems may require different entities. Legal applicability is jurisdiction- and role-dependent. NIST AI RMF 1.0 is also under revision as of 2026, so mappings must be rechecked when NIST publishes a successor.

The model should be narrowed or rejected if an existing enterprise architecture, knowledge graph or governance ontology preserves the same decision-relevant relationships with less conceptual overhead. A useful next validation step is to map several materially different systems and measure whether the taxonomy reduces unresolved ownership, duplicate controls or time needed for change-impact analysis.

Evidence notes

  • E1, lifecycle risk management: NIST AI RMF 1.0, January 2023. Supports lifecycle-oriented AI risk management; does not prescribe this taxonomy. NIST states that AI RMF 1.0 is being revised.
  • E2, management system: ISO/IEC 42001:2023. Supports organisational AI governance and continual improvement; does not define the proposed graph.
  • E3, legal requirements: Regulation (EU) 2024/1689, especially Articles 9, 11-14 and 72 where applicable. Supports risk management, documentation, logging, transparency, human oversight and post-market monitoring for systems/actors in scope; it does not require this reference model.
  • E4, evidence-grounded qualification: EG-VQA (Huang et al., 2026) reports a material gap between answer correctness and temporal evidence grounding in VideoQA. The generalization to governed agent outcomes is an architecture inference and must use modality-appropriate evidence contracts.
  • E5, effective human oversight: Mitchell, Ghosh and Passi (2026) argue that human presence and approval are insufficient proxies for meaningful oversight and propose cognitive-scaffolding interventions. It is a position paper, not an end-to-end validation of the Harness gate.
  • E6, control normalization: TACO (Shore, 2025) is a practitioner architecture that normalizes overlapping AI control requirements while retaining source mappings. It is not a normative crosswalk issued by the source standards bodies.
  • Reassessment trigger: material revisions to NIST AI RMF, ISO AI governance standards, EU implementing guidance, standardized agent identity/authorization models, or evidence that the entity model fails on a materially different AI architecture.

Evidence base

Standards and regulation

Research and benchmarks

Architecture and engineering

Where this goes next

The next question is what belongs inside each layer, especially the distinction between a framework and an architecture. They are often treated as the same thing in agentic AI systems. They are not. That is the next part of this series.