Your AI Doesn't Know Your Discount Tiers. It's Inventing Them.

A customer-facing bot quotes a discount the company has never offered. An internal copilot signs off on vendor spend that breaks procurement policy. A support agent promises a refund window that closed two quarters ago.

The model is not hallucinating in the textbook sense. It is filling a vacuum. There is no structured representation of the rule anywhere the agent can reach, so the model does what language models do — pattern-matches across training data and produces something that sounds plausible.

Better prompts will not fix this. Prompts are natural language, and natural language is ambiguous on purpose. The fix is encoding business rules in machine-readable formats that sit next to the model at inference time and constrain its outputs against logic the company has actually agreed to.

The second-order effect is uncomfortable: the more capable the model, the more confidently it invents business logic. A smarter model produces more convincing wrong answers. Model upgrades do not close this gap. They widen it.

Every company runs on thousands of rules nobody has written down in structured form. Pricing tiers, approval thresholds, regional compliance variants, contractual carve-outs, escalation paths, SLA definitions. They live in employee heads, scattered Confluence pages, PDF policy manuals, and the onboarding conversations that never made it to a doc.

Humans navigate this fine. A senior account manager knows enterprise EU clients get net-60 and APAC clients get net-30. A compliance officer knows transactions above $10,000 need a second signature. The knowledge is implicit, contextual, and usually correct because humans have been running their own reinforcement loop against organizational feedback for years.

AI systems get a prompt, maybe some retrieved context from a vector store, and a generation step. If the vector store contains a two-year-old pricing PDF, the model quotes two-year-old prices with full confidence. There is no internal voice telling it the document is stale. There is no senior coworker shaking their head.

The gap between what humans carry implicitly and what the agent needs explicitly is the single largest failure mode in deployed AI systems. RAG handles factual recall. It does not handle conditional logic. "The refund policy is 30 days" is not the same fact as "the refund policy is 30 days for consumer accounts, 90 days for enterprise with an active support contract, and 0 days for custom integrations after acceptance testing completes."

Branching, conditional, exception-laden logic needs structure. Not paragraphs. Structure.

Formalization has a cost. Pay it where it buys you something. A pricing tier needs a lookup table. Multi-jurisdiction compliance needs a policy engine. Treating both as the same problem is how rules-as-code projects collapse under their own ceremony. Below: the four patterns, ordered by complexity and the failure class each one is built to absorb.

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

The mechanism is plain. Conditions are columns. Outputs are columns. Each row is a rule. At inference time the agent (or a middleware layer) evaluates the input against the table and returns the matching output. No ambiguity. No generation. No guessing.

The leverage point: tables can be injected into the agent's context window or called as a tool. The model does not need to understand the table. It needs to look up the right row given customer attributes and return the result. That is retrieval, not generation. Retrieval is the part LLMs are reliable at.

Decision tables break 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 a rule engine does.

The Decision Model and Notation (DMN) standard, maintained by the Object Management Group, encodes those chains in a vendor-neutral way.^[3] DMN uses a graphical notation for decision dependencies and FEEL (Friendly Enough Expression Language) for the rule logic itself. Treat it as SQL for business rules — constrained enough to be deterministic, expressive enough for real conditions.

When the agent has to answer "can this customer get a refund", it does not generate the answer. It calls the rule engine with the customer's attributes, gets a deterministic result, and uses the LLM only to communicate the result in natural language. Reasoning offloads to verified logic. The model handles tone.

This is the split that holds: rules for reasoning, LLMs for communication. IBM's work on combining rule-based engines with LLMs reports both higher accuracy and better explainability under this separation^[5] — the system can cite the exact rule that produced the decision. The size of the accuracy gain depends on rule-set complexity and the model in use, but the direction is consistent.

Policy-as-code inverts the framing. Instead of encoding what the agent should do, it encodes what the agent must not do. It is a constraint system — allow/deny rules evaluated against every action the agent attempts.

Open Policy Agent (OPA) and its Rego language are the de facto standard for this layer.^[2] OPA was built for Kubernetes admission control and API authorization. The architecture maps cleanly onto agent guardrails: evaluate a structured request against a policy bundle, return allow or deny, log the decision for audit. The runtime is sub-millisecond. The semantics are deterministic. The prompt cannot override it.

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

The runtime topology is simple: the agent generates a proposed action, the policy engine evaluates it against the current rule set, only approved actions reach the user. Denied actions route to a fallback — human escalation, a safe default, or a re-generation under tighter constraints. The bypass surface is zero by construction.

Encoding format is a tractable problem. Extraction is the structural one. Most companies 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 carried by people who might leave next quarter.

The first time we ran this extraction, we interviewed the compliance team and got back a clean list of about 40 rules. We encoded them, deployed, and watched the system fail on roughly 30% of edge cases. The missing rules were not in any document. They were in the billing team's institutional memory — eight years of enterprise exceptions that had never been written down. The lesson is structural, not motivational: plan for at least two extraction passes. The first captures documented rules. The second captures the undocumented rules that surface as production errors.

Four steps that hold up across industries.

A production rules-as-code setup runs three layers in series. The decision layer resolves lookups — pricing, eligibility, categorization. The logic layer handles chained reasoning — multi-step approval workflows, eligibility with dependencies. The policy layer is the final guardrail — blocking actions that violate hard constraints regardless of what the layers above returned. Skip any one of them and a specific failure class walks straight through to production.

When a customer disputes a charge or a regulator asks why an application was denied, "the AI decided" is not a defense. The trail has to be explicit: input data, the rule version that was active, the specific rule that matched, the output it produced.

This is where rules-as-code pays for itself past accuracy. Every evaluation produces an audit record a human can read, verify, and stand behind. The rule engine does not have a mood. It applied rule version 2026.03.15, row 7, which maps enterprise accounts above $500K annual spend in the NA region to a 25% discount with net-60 terms. That sentence is the artifact. It is also the deposition exhibit.

Store rules in Git. Treat every rule change like a code change — pull request, domain-owner review, automated tests, deployment through CI/CD. Rules that live in a database or a UI without version control destroy your ability to answer the question "what were the rules on March 3rd, when this decision was made." That question is the entire point of the audit trail.

The stronger implementations tag every agent response with the rule-version hash that was active during evaluation. If the rules have moved since, the system can flag the response as potentially stale — a pattern that becomes load-bearing for long-running conversations where a pricing update lands mid-session.

The rigor you apply to application code applies to rules. Every decision table needs a test suite verifying outputs for known inputs, including the boundary rows. Every policy needs negative tests confirming that denied actions are actually denied. Spot checks miss the exact place rules fail — the boundaries.

OPA ships test tooling (opa test) that makes this straightforward. For decision tables in JSON, write a thin harness that evaluates every row against sample inputs and asserts the expected output. The cost is low. The signal is high.

Encoding a rule is a point-in-time activity. The rules are correct on the day you encode them. Six months later the pricing has shifted, a compliance threshold has moved, two new product tiers exist — and nobody updated the table.

Drift is the silent failure mode of rules-as-code. The agent is enforcing rules that are no longer accurate, and because enforcement is deterministic, nobody notices until a customer complains or an audit catches it. Three mechanisms keep drift from becoming the default.

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

The live architectural call: should the agent call rules proactively, or should middleware intercept the agent's output and validate it. Both patterns have trade-offs. The trade-offs decide what failure mode you accept.

Four metrics tell you whether rules-as-code is doing its job. Track them from day one. They are both the justification for the investment and the early-warning system for drift. If you cannot read these four numbers off a dashboard, the system is enforcing rules nobody is auditing.