Domain Intelligence: Why Context Matters

A $5,000 payment is routine. A $5,000 payment is also a potential fraud vector. It depends entirely on context. Is this a recurring vendor payment processed during business hours by an agent that handles dozens of similar transactions daily? Or is this a first-time payment to an unknown recipient initiated at midnight by an agent that normally handles customer support?

Same action. Same amount. Completely different risk. Any governance system that treats them identically is either too permissive or too restrictive. Probably both, depending on which case it was calibrated for.

This is the problem domain intelligence solves.

The Context Problem

Most authorization systems evaluate actions in isolation. The input is an action and a principal. The output is allow or deny. There is no concept of "this action in this domain with this history at this time."

Consider these pairs of identical actions with wildly different risk profiles:

**"Delete database table"** in a development sandbox versus in production. The action is identical. The SQL is the same. The risk difference is the difference between "oops, let me recreate the test data" and "we just lost customer records and need to invoke the disaster recovery plan."

**"Send email to customer list"** with 10 recipients versus 100,000 recipients. Same API call. Same permission required. One is a targeted follow-up. The other is a mass communication that could violate CAN-SPAM if the content is wrong.

**"Approve refund"** for $50 on an order placed yesterday versus $5,000 on an order placed six months ago. Both are refund approvals. The first is routine customer service. The second is a potential fraud pattern that should trigger manual review.

**"Deploy service"** during a scheduled maintenance window versus during peak traffic hours. Both deployments use the same pipeline. The risk of customer impact is orders of magnitude different.

Authorization systems that ignore context force organizations into a painful choice: set policies based on the worst case and block legitimate operations constantly, or set policies based on the average case and miss the dangerous outliers.

What Domain Intelligence Is

Domain intelligence is the layer that provides context to authority decisions. It encodes domain-specific knowledge about what is normal, what is risky, and what is anomalous for a given operational domain.

In Intended, domain intelligence is delivered through domain packs. A domain pack is a configuration package that contains four things:

**Intent mappings** that translate raw actions into domain-specific intent categories. In a FinTech domain pack, a "POST /transfers" API call maps to "financial.transfer.initiate." In an infrastructure domain pack, a "kubectl apply" command maps to "infrastructure.kubernetes.deployment.apply." The intent mapping provides the semantic layer that raw action data lacks.

**Risk models** that define how to score risk for each intent category within the domain. The FinTech risk model weights financial impact heavily and considers factors like recipient history, transaction velocity, and time-of-day patterns. The infrastructure risk model weights blast radius and reversibility, considering factors like the number of affected services, the environment tier, and whether a rollback plan exists.

**Baseline profiles** that establish what normal behavior looks like for agents operating in the domain. A procurement agent that typically processes 20-30 purchase orders per day has a baseline. When it processes 200 in an hour, the domain intelligence layer flags the deviation. Baselines are computed from historical data and updated continuously.

**Threshold configurations** that define the boundaries between automatic approval, escalation, and denial for each risk level. In a FinTech domain, transactions under $1,000 might auto-approve, transactions between $1,000 and $50,000 might require single-party approval, and transactions over $50,000 might require multi-party approval. In a DevOps domain, staging deployments might auto-approve while production deployments during business hours require approval.

Domain Packs in Practice

Intended ships with domain packs for common operational domains: SaaS operations, financial technology, healthcare, infrastructure and DevOps, software development lifecycle, security operations, and others. Each pack encodes the domain expertise that would otherwise live in the heads of experienced operators.

Consider the SaaS operations domain pack. It knows that customer data access patterns follow business hours. It knows that bulk operations on customer records are unusual and should be flagged. It knows that changes to billing configurations are high-risk because billing errors directly affect revenue. It knows that tenant isolation boundaries should never be crossed by automated systems.

This knowledge is not magic. It is the codification of operational experience into machine-evaluable rules and models. Every risk weight, every threshold, every baseline was informed by real operational patterns from real organizations.

Organizations can customize the built-in domain packs or create entirely custom packs. A healthcare organization might start with the healthcare domain pack and add custom rules for their specific EHR system, their specific compliance requirements, and their specific operational patterns.

The Sandbox vs. Production Problem

One of the most common failure modes in AI governance is treating sandbox and production identically. Agents that are being tested should be able to do things that would be catastrophic in production. An agent being tested in a development environment should be able to delete databases, send test emails, and make test payments without triggering production-grade governance.

Domain intelligence solves this with environment-aware evaluation. The same agent, calling the same tool, with the same parameters, gets a different risk score depending on the environment context. The domain pack defines which environments are sandbox-tier, staging-tier, and production-tier, and adjusts risk scores accordingly.

A "deploy to production" command in a staging environment (deploying to the staging cluster) might score a 0.2 risk. The same command targeting the production cluster scores a 0.8. The risk model knows the difference because the domain pack encodes it.

Why Generic Governance Fails

Generic governance systems apply the same rules everywhere. They do not know that $5,000 is a routine amount in procurement but an unusual amount in customer refunds. They do not know that deploying at 3 AM is fine during a scheduled maintenance window but concerning otherwise. They do not know that accessing 100 customer records is normal for a reporting agent but anomalous for a support agent.

Without domain intelligence, governance is either a blunt instrument that blocks too much or a rubber stamp that catches too little. Domain packs provide the specificity that makes governance accurate.

The goal is not to build the most restrictive system. The goal is to build the most accurate system: one that allows what should be allowed, blocks what should be blocked, and escalates what should be reviewed. Accuracy requires context. Context requires domain intelligence. Domain intelligence is what turns a generic policy engine into an authority runtime that actually understands what your agents are doing.