Business Rules as Code: Stop AI From Making Things Up

Here is a pattern that plays out in every organization deploying AI agents: a customer-facing bot quotes a discount the company has never offered. An internal copilot approves a vendor spend that violates procurement policy. A support agent promises a refund window that expired two quarters ago.

The AI wasn't hallucinating in the traditional sense. It wasn't confusing one fact with another. It was filling a vacuum. The model had no structured representation of the business rule, so it did what language models do — it generated a plausible-sounding answer based on pattern matching across its training data.

The fix is not better prompts. Prompts are natural language, and natural language is ambiguous by design. The fix is encoding your business rules in machine-readable formats that sit alongside the model at inference time, constraining its outputs against verified organizational logic.

Every company runs on thousands of rules that nobody has written down in a structured format. Pricing tiers, approval thresholds, regional compliance variations, contractual obligations, escalation procedures, SLA definitions — these live in employee heads, scattered Confluence pages, PDF policy manuals, and tribal knowledge passed down during onboarding.

Humans navigate this fine. A senior account manager knows that enterprise clients in the EU get net-60 terms but APAC clients get net-30. A compliance officer knows that transactions above $10,000 need a second signature. This knowledge is implicit, contextual, and usually correct because humans have years of reinforcement learning from organizational feedback.

AI systems have none of that. They get a prompt, maybe some retrieved context from a vector store, and they generate. If the vector store contains a two-year-old pricing PDF, the model will quote two-year-old prices with complete confidence.

The gap between what humans know implicitly and what AI needs explicitly is the single largest source of business-logic errors in deployed AI systems. RAG helps with factual recall, but it does not help with conditional logic. Knowing that "the refund policy is 30 days" is not the same as knowing that "the refund policy is 30 days for consumer accounts, 90 days for enterprise with an active support contract, and 0 days for custom-built integrations after acceptance testing completes."

That kind of branching, conditional, exception-laden logic requires structure. Not paragraphs — structure.

Not every business rule needs the same level of formalization. A simple lookup table works for pricing tiers. A full policy engine is warranted for multi-jurisdiction compliance checks. Here are the four patterns, ordered by complexity and when each one earns its overhead.

Decision tables map input conditions to output actions. They are the oldest formalization of business rules — insurance companies have used them since the 1960s — and they remain the most practical starting point for AI-accessible business logic^[3].

The idea is straightforward: define your conditions as columns, define your outputs as columns, and each row is a rule. At inference time, the AI system (or a middleware layer) evaluates the input against the table and returns the matching output. No ambiguity, no generation, no guessing.

The key advantage of decision tables for AI systems: they can be injected directly into an agent's context window or called as a tool. An LLM does not need to understand the table — it needs to look up the correct row based on the customer's attributes and return the result. This is a retrieval task, not a generation task, and retrieval is where LLMs are reliable.

Decision tables break down when rules depend on each other. If the discount depends on the payment terms, which depend on the credit score, which depends on the account age — you need forward chaining or backward chaining through a dependency graph. That is what rule engines do.

The Decision Model and Notation (DMN) standard, maintained by the Object Management Group, provides a vendor-neutral way to express these chained decisions^[3]. DMN uses a graphical notation for decision dependencies and FEEL (Friendly Enough Expression Language) for the actual rule logic. Think of it as SQL for business rules — constrained enough to be deterministic, expressive enough for real-world conditions.

When an AI agent needs to answer "Can this customer get a refund?", it does not generate an answer. It calls the rule engine with the customer's attributes, gets a deterministic result, and then uses the LLM only to communicate that result in natural language. The reasoning is offloaded to verified logic; the model handles tone and phrasing.

This is the hybrid pattern that works: rules for reasoning, LLMs for communication. According to IBM's research on combining rule-based engines with LLMs, this separation yields both higher accuracy and better explainability^[5] — the system can cite exactly which rule produced the decision. Specific accuracy gains depend on the complexity of the rule set and the LLM used.

Policy-as-code takes a different approach from decision tables and rule engines. Instead of encoding what the AI should do, it encodes what the AI must not do. It is a constraint system — a set of allow/deny rules evaluated against every action the AI attempts to take.

Open Policy Agent (OPA) and its Rego language have become the de facto standard for this pattern^[2]. Originally built for Kubernetes admission control and API authorization, OPA's architecture maps perfectly to AI guardrails: evaluate a structured request against a policy bundle, return allow or deny, and log the decision for audit.

AWS Bedrock's Automated Reasoning checks demonstrate this pattern at scale — translating natural language policies into formal logic that validates AI outputs with high verification accuracy for well-defined policy domains (AWS cites up to 99% in specific benchmark settings)^[6]. The approach works because formal logic is complete in a way that prompt engineering cannot be. You can mathematically prove that a policy covers all edge cases. You cannot prove that about a system prompt.

The practical architecture looks like this: the AI agent generates a proposed action, the policy engine evaluates it against the current rule set, and only approved actions reach the user. Denied actions get routed to a fallback — a human escalation, a safe default response, or a re-generation with tighter constraints.

The hardest part of business-rules-as-code is not the encoding format. It is the extraction. Most organizations do not have a clean inventory of their own rules. They have policy documents, employee handbooks, Slack threads where exceptions were negotiated, and institutional memory held by people who might leave next quarter.

Here is a four-step extraction workflow that works across industries.

A production business-rules-as-code setup typically has three layers operating together. The decision layer resolves lookups — pricing, eligibility, categorization. The logic layer handles chained reasoning — multi-step approval workflows, complex eligibility with dependencies. The policy layer acts as the final guardrail — blocking actions that violate hard constraints regardless of what the other layers returned.

When a customer disputes a charge or a regulator asks why an application was denied, "the AI decided" is not an acceptable answer. You need a full trace: the input data, the rule version that was active, the specific rule that matched, and the output it produced.

This is where business-rules-as-code pays for itself beyond accuracy. Every rule evaluation produces an audit record that a human can read, verify, and defend. The rule engine does not have a "mood" — it applied rule version 2026.03.15, row 7, which maps enterprise accounts with annual spend above $500K in the NA region to a 25% discount with net-60 terms.

Store rules in Git. Treat every rule change like a code change — pull request, review by the domain owner, automated tests, and deployment through CI/CD. When rules live in a database or a UI without version control, you lose the ability to answer "what were the rules on March 3rd when this decision was made?"

The best implementations tag each AI response with the rule version hash that was active during evaluation. If the rules have changed since, the system can flag the response as potentially stale — a pattern that becomes critical for long-running conversations where a pricing update might happen mid-session.

The same rigor you apply to application code applies to business rules. Every decision table needs a test suite that verifies correct outputs for known inputs, including edge cases and boundary conditions. Every policy needs negative tests that confirm denied actions are actually denied.

OPA has built-in test tooling (opa test) that makes this straightforward. For decision tables in JSON, write a simple test harness that evaluates every row against sample inputs and asserts expected outputs.

Encoding rules is a point-in-time activity. The rules are correct when you encode them. Six months later, the pricing has changed, the compliance threshold has shifted, and two new product tiers were added — but nobody updated the decision table.

Rules drift is the silent killer of business-rules-as-code systems. The AI is dutifully enforcing rules that are no longer accurate, and because the enforcement is deterministic, nobody notices until a customer complains or an audit flags a discrepancy.

Three mechanisms prevent drift.

Most agent frameworks support tool calling. This is your integration point. Define your rules engine as a tool that the agent can (and must) call before taking actions that involve business logic.

The key architectural decision: should the agent call rules proactively, or should middleware intercept the agent's output and validate it? Both patterns have trade-offs.

You need four metrics to know if your business-rules-as-code system is working. Track them from day one — they are your justification for the investment and your early warning system for drift.