Skip to main content

What is Business Rule as a Service (BRaS)?

Definition​

Business Rule as a Service (BRaS) is an architectural model in which business logic — decision tables, validation rules, and compliance policies — is decoupled from application source code and hosted as a managed cloud service, consumed synchronously or asynchronously via APIs.

Instead of embedding conditional logic in every service that needs it, the application sends data to a rule service and receives a decision back. The rules themselves live outside the application, where they can be changed, versioned, and audited on their own schedule.

The problem it solves​

Hard-coding conditional flows directly in the backend is cheap on day one and expensive forever after. Tax calculations, credit approval thresholds, eligibility checks, and discount matrices tend to start as a handful of if/else branches and grow into a tangle that only the original developers can read.

That coupling has concrete costs:

  • Every rule change is a deploy. Adjusting a tax rate or an approval threshold means a code change, a review, a release, and a regression pass — for logic that the business, not engineering, actually owns.
  • Rules are invisible to the people who define them. Analysts and compliance officers cannot see or verify the logic without asking a developer to read it back to them.
  • There is no reliable decision trail. When someone asks "which rule approved this loan, and what did that rule say on the day it ran?", the answer is buried in a specific commit of a specific service — if it was captured at all.
  • Logic is duplicated. The same eligibility check gets reimplemented, slightly differently, in three services.

How the model works​

The client application sends a data payload to the rule service. The service evaluates the current policy and returns the processed decision — or, for longer-running logic, runs a predefined process and persists its state. The calling code stays thin: it collects inputs, calls the service, and acts on the result.

   ┌─────────────┐    data payload    ┌───────────────┐    processed decision    ┌─────────────────────┐
   │ Client app  │ ─────────────────▶ │  Rule service │ ──────────────────────▶  │  Decision / result  │
   └─────────────┘                    └───────────────┘                          └─────────────────────┘
                                              │
                                              ▼
                                  evaluates the current policy,
                                  or runs a predefined process
                                  and persists its state

Because the rule service holds the authoritative version of every policy, the decision it returns reflects the rules as they exist at call time — and the service can record exactly which version produced which result.

Pillars of the BRaS model​

Independent lifecycle​

Changes to market rules, rates, or eligibility criteria reach production without new deploys or regression tests in the main system. The rule service is the unit of release for business logic, so a rate change is a rule update, not a code change.

Business-user governance​

Visual, low-code/no-code interfaces built on decision tables and diagrams let analysts create and change rules without direct developer involvement. The people who own a policy are the people who edit it.

Auditability and versioning​

Every decision is traceable to the exact rule version that produced it, at a specific point in time. Historical decisions can be explained and reproduced long after the rules have moved on.

Open standards​

The model builds on DMN (Decision Model and Notation) for decision logic and BPMN for process flow — both standardized by the Object Management Group (OMG) — rather than a proprietary rule language.

When BRaS is a good fit​

  • Tax and fiscal calculations that change with legislation, where a late or incorrect update has regulatory consequences.
  • Credit approval and risk scoring with policy that is revised frequently and must be defensible after the fact.
  • Eligibility rules for benefits, discounts, or plan tiers, where product and operations teams need to adjust criteria on their own.
  • Compliance, KYC, and AML policies that need a durable audit trail showing which check ran and what it decided.
  • Dynamic pricing and discount matrices that vary by segment, channel, or campaign and change often.
  • Multi-level process routing and approvals that involve human tasks, where the routing logic and the escalation rules evolve over time.

When it is not the right tool​

Lightweight point-to-point automations — move a row from one SaaS tool to another, post a notification when a form is submitted — that carry no state and need no audit trail are better served by lightweight automation tools. BRaS earns its keep when decisions must be versioned, audited, and governed by people who are not developers. If none of those apply, the extra layer is overhead.

How Stateway implements BRaS​

Stateway is a working BRaS platform. Business logic is expressed as DMN-style decision tables and BPMN processes; every definition is versioned, so a running instance stays pinned to the version it started on while new work picks up the latest. Every decision, variable change, and state transition is written to a native immutable audit log, and the whole platform is driven by a REST API that applications call synchronously or asynchronously.

Next steps​

  • Quickstart — Stand up your first process and call it from an application.
  • Core Concepts — The process model, execution tokens, decision models, and the vocabulary the rest of the docs use.