Skip to main content
A policy is the second way to author rules in GoRules. Where a decision graph wires nodes into an explicit flow, a policy reads like a document: text and rule blocks mixed together, in whatever order tells the story best. The engine works out execution order itself, from what each block reads and writes. Use a graph when the flow is the logic - branching, routing, staged processing. Use a policy when you’re defining the facts and vocabulary the rest of your rules build on.

​
The mental model

Think of a policy as a pure function over your data: an object goes in, and comes back enriched with everything the policy’s blocks computed. Each block declares what it produces; any block can use what another block produced. If one block computes applicant.debtToIncome and a decision table reads it, the engine runs them in the right order - you never sequence anything by hand. Because order doesn’t matter, you can organise the document for readers: headings, explanatory paragraphs, and the rules they describe, side by side. The documentation and the executable logic are the same artifact.

​
Block types

Type / in the editor to insert a block: Text blocks - headings, paragraphs, lists - carry no logic. Use them generously; a policy that explains itself is the point.

​
Dictionaries: shared vocabulary

A dictionary turns a set of magic strings into a named, labelled type: Type a data model property as employmentStatus and only those values are valid - a typo like "EMPLYED" is flagged as you type, not discovered in production. Decision table columns typed with a dictionary offer a labelled dropdown instead of free text, and natural language mode renders the labels in rules: “employment is one of Employed, Self-employed”.

​
Data models: typed entities

A data model declares an entity and its properties - string, number, boolean, date, or any dictionary; properties can be optional or arrays. Once an entity is declared, every rule that touches it is type-checked, and the entity browser shows each property’s type, who writes it, and where it’s used.

​
Rules that build on each other

Expressions, tables, and match blocks write properties; other blocks read them:
Two constraints keep this sound, both enforced by static analysis: only one block may write a given property (DUPLICATE_WRITER), and dependencies can’t form a cycle (CYCLIC_DEPENDENCY). Within those rules, compose freely.

​
Imports

Policies import other policies, and graphs import policies. An import pulls in the whole chain - importing a policy also brings everything it imports - and the group evaluates together in one shared namespace. That’s how a single lending-policy can define the dictionaries, entities, and derived facts that every graph in a project relies on.

​
Evaluating a policy

A policy is directly executable: evaluate it with an input object and it returns the object plus everything computed. In the BRMS every policy is also an HTTP endpoint, exactly like a graph - see Developer Tools.

​
Where to go next

Policies in the BRMS

The policy editor, entity browser, and import workflow.

Natural language

How rules render as readable sentences.