The MIR Taxonomy: Design Principles

Why a Taxonomy Exists

Before you can govern AI agent actions, you need a way to describe them. "The agent did something to the database" is not governable. "The agent executed a data_management.database.schema.alter action on resource db-prod-01 in the production environment" is governable. You can write policies against it. You can score its risk. You can compare it to historical patterns.

The Intended Intent Reference (MIR) taxonomy is the classification system that transforms the first description into the second. It is the vocabulary of AI agent governance. Every intent that enters Intended is classified according to MIR before any policy evaluation occurs.

Designing this taxonomy was one of the hardest problems we solved. A bad taxonomy makes governance brittle, ambiguous, and unmaintainable. Here are the design principles we followed and why each one matters.

Principle 1: Exhaustive Coverage

The taxonomy must be able to classify every action an AI agent might take. If an action falls outside the taxonomy, it falls outside governance. Ungoverned actions are ungovernable actions.

Achieving exhaustive coverage required extensive research. We analyzed API documentation for 50-plus enterprise platforms. We reviewed hundreds of real-world AI agent implementations. We cataloged thousands of distinct action types across infrastructure, security, development, operations, data management, and business functions.

The result is 14 top-level domains that collectively cover the full scope of enterprise AI agent operations: Infrastructure, SecOps, SDLC, SaaS Operations, Data Management, Compliance, Financial Operations, Customer Operations, HR Operations, Legal Operations, Content Operations, Communication Operations, Supply Chain, and AI/ML Operations.

Each domain contains categories, and each category contains specific action types. The hierarchy has three levels: domain, category, and action. This three-level structure provides enough granularity for precise governance without becoming unwieldy.

The test for exhaustive coverage: take any AI agent action described in natural language, and the taxonomy should have a classification for it. If it does not, the taxonomy has a gap that needs to be filled.

Principle 2: Mutual Exclusivity

Every action should map to exactly one classification. If an action can be classified in two different ways, policy evaluation becomes ambiguous. Which classification do you evaluate against? Both? The more specific one? The one with more restrictive policies?

Mutual exclusivity is enforced through clear domain boundaries and unambiguous category definitions. When we encountered actions that seemed to belong to multiple domains, we established precedence rules. For example, "deploy a security patch to production infrastructure" could be classified as Infrastructure (deployment) or SecOps (security patch). Our precedence rule: classify by the primary intent of the action. The primary intent is patching a security vulnerability, so it is SecOps. The infrastructure deployment is the mechanism, not the intent.

These precedence rules are documented as part of the taxonomy specification. The intent compiler uses them to resolve ambiguous classifications deterministically.

Principle 3: Semantic Precision

Category and action names must precisely describe what they cover. Vague names lead to vague classifications. "Manage resources" is vague. "Compute instance lifecycle management" is precise.

We enforced semantic precision through a naming convention: every action type uses the format `domain.category.resource.verb`. For example, `infrastructure.compute.instance.create`, `data_management.database.schema.alter`, `secops.credentials.api_key.rotate`. The four-part name tells you the domain, the category, the resource type, and the operation.

This naming convention serves two purposes. First, it forces precision during taxonomy design. You cannot create a vague action type because the naming convention requires you to specify the resource and verb. Second, it makes policies readable. A policy that references `infrastructure.compute.instance.create` is self-documenting.

Principle 4: Governance-Relevant Granularity

The taxonomy should distinguish between actions when the governance requirements differ, and should not distinguish between actions when the governance requirements are the same.

For example, `database.table.create` and `database.table.drop` have very different risk profiles. Creating a table is low-risk and reversible. Dropping a table is high-risk and potentially irreversible. The taxonomy must distinguish them.

Conversely, `database.table.add_column` and `database.table.rename_column` have similar risk profiles. Both are schema modifications, both are reversible, and both have similar blast radius. The taxonomy classifies both as `data_management.database.schema.alter` rather than creating separate action types for each specific schema operation.

This principle keeps the taxonomy manageable. Without it, the taxonomy would have thousands of action types, most with identical governance requirements. With it, the taxonomy has just over 300 action types, each with a meaningfully distinct governance profile.

Principle 5: Stability

The taxonomy must be stable over time. Policies reference taxonomy identifiers. If those identifiers change, policies break. If action types are renamed, reclassified, or removed, every organization using those action types needs to update their policies.

We enforce stability through a versioning policy. Action types are never removed from the taxonomy; they can only be deprecated. Deprecated action types continue to work for policy evaluation but are flagged in the console. New action types can be added at any time. Existing action types are never renamed; the identifier is permanent.

The taxonomy version is a semantic version. Minor versions add new action types. Major versions may deprecate action types or restructure categories. Major version upgrades include a migration guide and a compatibility period during which both old and new identifiers are accepted.

Principle 6: Domain Independence

Each domain should be self-contained. The categories and action types within a domain should not depend on or reference categories in other domains. This enables domain packs: self-contained governance packages that can be adopted independently.

Domain independence means an organization that only needs governance for SDLC actions can adopt the SDLC domain pack without understanding the Infrastructure or Data Management domains. The policies, risk models, and compliance mappings in the SDLC pack are complete on their own.

The exception is cross-domain workflows, where an agent's operation spans multiple domains. In these cases, the workflow is decomposed into individual intents, each classified in its own domain. The cross-domain relationship is tracked through correlation IDs, not through taxonomy dependencies.

Principle 7: Extensibility

The taxonomy must support custom extensions for organization-specific action types. No predefined taxonomy can cover every possible action in every organization. Custom internal systems, proprietary APIs, and industry-specific operations may not fit neatly into the predefined categories.

MIR supports custom extensions through a reserved namespace. Organizations can define custom action types under their own namespace (e.g., `custom.acme.billing.invoice.approve`). Custom action types follow the same naming convention and governance model as predefined types. They can be referenced in policies, scored for risk, and recorded in the audit ledger.

Custom extensions do not affect the core taxonomy. They are additive. This means organizations can extend the taxonomy without forking it, and taxonomy updates from Intended do not conflict with custom extensions.

The Design Process

Designing MIR was not a one-time exercise. It was an iterative process that spanned months and involved input from security engineers, platform architects, compliance professionals, and AI agent developers.

The first draft had 8 domains and about 100 action types. It was too coarse. Actions with very different risk profiles were lumped together. We split domains, added categories, and refined action types based on real-world classification exercises: take 1,000 real agent actions and classify them. Where the taxonomy was ambiguous, refine it.

The current taxonomy has 14 domains and over 300 action types. It handles the vast majority of enterprise AI agent actions without custom extensions. Organizations with specialized requirements use the extension mechanism for their unique action types.

MIR is open-source under the Apache 2.0 license. We believe the taxonomy should be a shared standard, not a proprietary lock-in mechanism. The more organizations use MIR, the more interoperable the AI governance ecosystem becomes.