Where Do Business Rules Belong? A Framework for Atomic Rule Placement

Introduction

The previous article divided ontology intelligence into semantic, decision, and action layers. Business rules are the element that most easily crosses these three layers and gets duplicated during implementation.

A business stakeholder might say: "When a customer is overdue more than 30 days and there is no valid dispute, after risk manager approval, adjust the credit limit to 500,000 and notify the account manager; the same decision must not execute twice."

From a system perspective, that single sentence contains at least six distinct questions: what constitutes overdue, which data proves no valid dispute, under what conditions to adjust the limit, who must approve, whether to adjust before notifying, and how to prevent duplicate execution.

Copying the raw statement into an ontology, rule engine, workflow, prompt, and Java code creates multiple versions of the "same" rule. The guiding principle: where a business rule belongs depends on what it constrains and who is accountable for the runtime result, not on which tool can express an if‑then statement.

Category 1: Semantic Definition Rules → Ontology / Semantic Model

Semantic definition rules answer: what a business concept is, how objects relate, and how a fact is established.

Which customer and contract an accounts receivable belongs to.

What due date, grace period, repayment record, and dispute status represent.

That exceeding the due date, being outside the grace period, and having no valid repayment constitutes the derived fact "overdue".

These rules should stay consistent across systems and serve as the semantic foundation for decisions and explanations. They can be expressed as ontology axioms, derived properties, or semantic computation logic, but must not directly trigger actions with business side‑effects.

Category 2: Fact and Data Constraints → Validation Mechanisms

Constraint rules answer: do current data and business facts satisfy usage requirements?

Accounts receivable must link to a contract and a customer.

Due date cannot be earlier than the receivable creation date.

"No valid dispute" must have a complete dispute query result and time evidence.

Facts used for high‑risk disposal must possess a full evidence chain.

Implementations can use SHACL, JSON Schema, data quality platforms, validation services, or database constraints. The key is producing a clear pass/fail or "evidence insufficient" result that downstream decision or action entry points can block on—not leaving the outcome only in a quality report.

Category 3: Disposition Strategies → Decision Tables, DMN, Rule Engines, or Decision Services

Decision rules answer: given current facts and goals, which handling option should be chosen?

Example: "Overdue >30 days, no valid dispute, customer not in special protection period → recommend credit limit adjustment."

If rules change frequently, involve many condition combinations, or require business‑user configuration, prefer decision tables, DMN, a rule engine, or a standalone decision service. If the rule is simple, stable, and serves a single service with a clear ownership boundary, plain business code is acceptable. Regardless of form, the decision result must retain rule identifier, version, input facts, hit conditions, output conclusion, and any manual confirmation requirement.

Category 4: Sequence, Routing, and Waiting → Workflow

Process rules answer: in what order do tasks flow, who handles them, and what conditions trigger branches, waits, escalations, and termination?

Create a risk review task first; adjust limit only after manager approval.

Auto‑escalate if approval exceeds 24 hours.

Notify the account manager after the limit adjustment succeeds.

On execution failure, route to manual handling and stop subsequent nodes.

Workflows excel at managing process state, tasks, and long‑running waits. They should not redefine "what is overdue" nor bury complex decision logic in a maze of branches.

Category 5: Transaction Invariants → Business Code and Database

Transaction invariants answer: which conditions must never be violated during execution, regardless of upstream decisions or orchestration?

The same decision must not adjust a customer's limit twice.

Updates must verify the customer's current state and data version.

Business state, approval records, and execution receipts must remain consistent.

Concurrency, timeouts, and retries must not produce duplicate side effects.

These rules live closest to the transaction and state authority, implemented via domain code, database unique constraints, optimistic locking, transaction mechanisms, or idempotency handling. Even when ontology, rule engine, and workflow have validated the conditions, the source business system must perform the final guard.

Two Capabilities That Must Not Be Mixed Into Ordinary Business Rules

Permissions/risk control and model‑based judgments are important but belong to separate mechanisms.

Permissions and risk policies. Who can view customer data or initiate a limit adjustment is enforced by IAM, a policy engine, or a dedicated authorization service. Which risk levels require manual confirmation is defined by risk governance policies and executed by decision services, workflows, or action gateways. Ontology can define the semantics of roles, resources, actions, and risk levels, but must not replace runtime authorization, approval, or interception.

Uncertainty judgments. Whether a customer's appeal text constitutes a valid dispute or an anomaly needs special handling can be assisted by LLMs or ML models. Model output is a decision input, not a deterministic rule. It must retain evidence, confidence scores, model version, and human‑review boundaries, and must not directly drive high‑risk actions.

A Business Policy Can Be Split but Must Not Fragment Governance

The stakeholder's statement is not a single deployable atomic rule; it is a business policy composed of semantic definitions, evidence constraints, disposition strategies, approval orchestration, permission policies, and transaction invariants. The correct approach is to first decompose it into atomic rules with clear boundaries.

"Atomic" here does not mean infinitely granular; it means each rule carries a single responsibility, has a clear owner, and can be versioned and tested independently.

Decomposition does not imply loss of unified governance. A better practice is to maintain a policy master record that links multiple rule assets. At minimum, manage:

Policy ID, name, business definition, scope, and owner.

Atomic rule IDs, types, responsibility boundaries, input facts, output conclusions, and evidence requirements.

Dependencies, sequence, conflict relations, and priorities among rules.

Implementation locations and corresponding semantic model, decision table, process, policy, or code versions.

Effective/expiry dates, rollback strategy, and test cases.

A simplified policy record structure:

{
  "policy_id": "POL-CREDIT-001",
  "name": "逾期客户信用额度调整政策",
  "version": "3.2",
  "owner": "信用风险管理部",
  "effective_from": "2026-07-01",
  "rule_refs": [
    {
      "rule_id": "SEM-OVERDUE-001",
      "rule_version": "1.4",
      "implementation_ref": "ontology:[email protected]"
    },
    {
      "rule_id": "DEC-CREDIT-001",
      "rule_version": "4.0",
      "implementation_ref": "rules-engine:[email protected]"
    },
    {
      "rule_id": "WF-CREDIT-001",
      "rule_version": "1.7",
      "implementation_ref": "workflow:[email protected]"
    },
    {
      "rule_id": "INV-CREDIT-001",
      "rule_version": "1.2",
      "implementation_ref": "service:[email protected]"
    }
  ]
}

policy_id

ties the same business policy together; rule_id and rule_version identify each atomic rule and its governance version; implementation_ref points to the runtime implementation and its version. The reference format is illustrative, not an industry standard.

This record is a governance catalog, not a runtime payload for agents, and does not replace the ontology platform, rule engine, workflow, or business systems. Every atomic rule has its own ID and version; rules under the same policy share the policy ID. This avoids forcing all rules into one system while enabling traceability from policy to every implementation and runtime result.

Decompose First, Then Use a Decision Guide to Place Each Rule

When facing a natural‑language business policy, first split it into atomic rules, then determine what each rule constrains:

Is it defining meaning? → Semantic definition rule → Core concern: concepts, relationships, fact establishment conditions → Carrier: ontology, semantic model.

Is it validating facts? → Fact and data constraint → Core concern: completeness, consistency, evidence sufficiency → Carrier: SHACL, JSON Schema, validation service, database constraints.

Is it choosing a handling option? → Disposition strategy → Core concern: condition combinations, priorities, output conclusions → Carrier: decision tables, DMN, rule engine, decision service.

Is it managing sequence, routing, and waiting? → Process rule → Core concern: nodes, roles, time limits, exception paths → Carrier: workflow.

Is it an execution‑time condition that must never be broken? → Transaction invariant → Core concern: consistency, concurrency, idempotency, transaction boundaries → Carrier: business code, database constraints and transaction mechanisms.

This guide resolves ownership for deterministic rules. Additionally, check whether the rule belongs to permission policies, contains model‑based uncertainty judgments, or produces side effects that require action contracts.

Summary

Ontology, rule engines, workflows, and code are not four interchangeable rule technologies; they are engineering carriers that serve different responsibility boundaries.

Semantic definitions go into the ontology; fact constraints into validation mechanisms; disposition strategies into decision capabilities; sequence and routing into workflows; transaction invariants stay in business code and databases; permissions and uncertainty judgments are managed by dedicated mechanisms.

True rule governance is not centralizing all rules into a single engine, but first decomposing business policies into atomic rules with clear boundaries, then giving each rule a clear owner, a unified version baseline, a traceable implementation location, and a verifiable runtime result.