> ## Documentation Index
> Fetch the complete documentation index at: https://docs.gorules.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Authoring policies

> Model shared definitions and rules as a document - no nodes or wiring, just blocks the engine orders for you.

A policy is the second way to author rules in GoRules. Where a [decision graph](/learn/authoring/decision-graphs) 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:

| Block          | What it does                                             |
| -------------- | -------------------------------------------------------- |
| Dictionary     | Names a set of valid values with display labels.         |
| Data Model     | Declares an entity and its typed properties.             |
| Expression     | Computes a value and writes it to a property.            |
| Decision Table | Spreadsheet-style rules - identical to tables in graphs. |
| Match          | Picks an outcome from ordered conditions.                |
| Assertion      | States a condition that must hold.                       |
| Globals        | Values shared across the whole policy.                   |

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:

| Value           | Label         |
| --------------- | ------------- |
| `EMPLOYED`      | Employed      |
| `SELF_EMPLOYED` | Self-employed |
| `RETIRED`       | Retired       |
| `UNEMPLOYED`    | Unemployed    |

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](/learn/authoring/natural-language) 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:

```
applicant.debtToIncome = round(applicant.monthlyDebt / applicant.monthlyIncome, 2)
```

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](/developers/developer-tools).

## Where to go next

<CardGroup cols={2}>
  <Card title="Policies in the BRMS" href="/brms/build/policies">
    The policy editor, entity browser, and import workflow.
  </Card>

  <Card title="Natural language" href="/learn/authoring/natural-language">
    How rules render as readable sentences.
  </Card>
</CardGroup>