Where business rules usually live

Most businesses keep rules in one of three places.

In code. A developer writes checks such as "if the product is from this vendor and the customer is in this group, use this price." It works until the rule changes. Each change needs a developer, and the rule sits apart from the products and customers it is about, so nobody can see it by looking at the catalog.

In a chatbot. Newer tools send the details to an AI model and ask, "Does this order qualify?" That is flexible, but the same question can get different answers on different runs, and nobody can see how the answer was reached.

In a separate rules engine. A dedicated system holds the rules outside the code. That separates rules from code, but it also separates them from the data. Someone has to keep the two in step, and every new product or customer has to be copied or mapped across.

In all three, the rule lives somewhere other than the things it governs.

Illustration titled Where should a business rule live? Four cards compare the options. In code: Changes need a developer. In a chatbot: Answers can vary. In a rules engine: Kept apart from the data. In the data model, highlighted in green: Set once, applied everywhere. A bar at the bottom reads: Put the rule next to the things it governs.
Figure 1. The three usual places for business rules, compared with keeping the rule in the data model.

Put the rule on a branch, not on every item

A data model already groups things into branches. Products belong to product lines, product lines belong to vendors, and customers belong to groups. A rule can be attached to a branch once. Everything under that branch inherits it, including items added next year.

The rule becomes part of what the item is. A product does not carry a copy of the rule or appear on a separate list. It follows the rule because of where it sits in the model. What an ontology is, explained for business owners explains the kind of model this needs.

A published example: chronic-condition codes

The Ontology Does the Reasoning, published on the Buffaly blog, shows this with medical billing. Some care programs are open only to patients with chronic conditions, and diagnoses are recorded as codes arranged in branches. A traditional system keeps a list of every code that counts as chronic and must update it whenever codes are added.

In the published example, the chronic-condition type is added once to a few branches, such as E11 for type 2 diabetes. The detailed code E11.65 is then treated as chronic because it sits under E11, and a new code added under E11 is treated the same way without anyone updating a list.

The example builds on that:

  • Patients are counted by branches, not by codes. A patient with two codes under the diabetes branch has one chronic condition, not two.
  • Program eligibility combines rules. A patient becomes eligible for a program when the condition rule and the insurer's support for that program are both met.
  • Actions accept only eligible patients. The action that enrolls a patient in a program accepts only a patient the model has already found eligible. The AI passes a reference to the patient, and the system decides whether that patient qualifies. A prompt cannot talk it into a different answer.
  • New rules wait for a person. The system can propose a new rule by comparing approved and rejected cases. The article says such a rule should stay "discovered, pending human verification" until a person decides to enforce it.

A flooring example: a vendor program on a product line

The same structure fits a distributor. Suppose, as an example, a vendor runs a program on one of its product lines: program pricing for dealers enrolled with that vendor, and samples supplied to enrolled dealers only.

In code, that program becomes checks repeated wherever prices or samples are handled. In the data model, it is set in one place:

  1. Mark the product line as part of the vendor's program. Every style and color in the line is now in the program, including styles the vendor adds later.
  2. Mark the customer as enrolled with that vendor.
  3. Let the pricing and sample actions accept only matching pairs: an enrolled dealer and a product in the program. Everyone else gets the standard price and the standard sample rules.

When the vendor ends the program or moves it to another line, someone changes one mark on the product line. Nothing else has to be found and edited.

Illustration titled Set the rule once on the product line. A tag labeled Vendor program is attached to a card labeled Product line. Lines lead down to three cards labeled Style, each showing a rug or carpet swatch and a green check, and a dashed card labeled New style with a green check and the note Applies automatically. A pencil beside the tag is labeled Change it once. A bar at the bottom reads: One change on the line updates every style beneath it.
Figure 2. A vendor program set once on a product line applies to every style in it, including new ones. An example for a flooring wholesaler.

What you get

  • The same answer every time. The answer comes from where the item sits in the model, not from a model's judgment on a given day.
  • An explanation for every answer. "This style gets program pricing because it is in this line, and this line is in the vendor's program." Staff and auditors can follow the same path the system did.
  • One place to change. A rule changed on the branch changes for everything under it.
  • Limits the AI cannot argue with. When actions accept only qualifying records, an AI agent can ask but cannot override. Can you trust an AI agent with orders, prices and invoices? covers this in more detail.

Find the rules that should move

Start with the rules that cause the most mistakes or the most questions:

  • List the rules that exist in more than one place, such as a price list, a spreadsheet, the order screen and someone's memory.
  • For each rule, write down what it applies to: a vendor, a product line, a customer group, a region.
  • Note who changes the rule, how often, and what goes wrong when a change is missed.

Rules that apply to a whole group are the best candidates to move into the model. Design the data model first explains why the model comes before the software.

If you are evaluating a system, ask the vendor:

  • Where does a rule like a vendor program live, and who can change it?
  • When a new product is added to a line, does it follow the line's rules automatically?
  • Can the system show why it gave a particular price or answer?
  • Can an AI feature change a price or approve an order on its own judgment?

Send us one rule that keeps causing mistakes

Tell us about one rule your team applies by hand or keeps getting wrong, such as a vendor program, a customer price agreement or an approval limit. We will show you where it would sit in your data model and what would follow from it. Tell us about your current system, or read how full service works.