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

# Rules as data

> A rule is an inspectable, serializable value — when X, do Y — not a compiled callback. You can list it, diff it, edit it mid-run, and ship it in a scenario.

In most engines, game logic is code: a callback compiled into the binary that you cannot
read back at runtime. In Euca, a **rule is data**. A rule is a plain value — a condition
plus an effect — that lives in the world alongside entities and components. You can list
the rules currently in force, add new ones while the simulation is running, and serialize
the whole rule set into a scenario document.

<Note>
  Every byte of a rule is data. A rule is **`when` a condition holds, `do` an effect** —
  no closures, nothing hidden in the binary. That is what makes the world's logic as
  legible to an agent as its state.
</Note>

## The shape of a rule

A rule carries a condition, an effect bundle, a firing policy, and — for stochastic rules
— a named random variable and an explicit outcome distribution. A deterministic rule simply
omits the variable. Because all of that is data, an agent can read a rule as easily as it
reads an entity.

## Adding a rule

The compact way is `POST /rule/create`, which takes a small string DSL:

```bash theme={null}
# When any entity drops below 50 health, heal it back up by 20.
curl -s -X POST http://localhost:3917/rule/create \
  -H 'content-type: application/json' \
  -d '{"when":"health-below:50","filter":"any","actions":["heal this 20"]}'
```

* **`when`** — `death`, `timer:N`, `health-below:N`, `score:N`, or `phase:NAME`.
* **`filter`** — which entities it applies to: `any`, `entity:N`, or `team:N`.
* **`actions`** — space-separated, each with a target prefix: `damage entity:1 10`,
  `heal this 30`, `score source 1`. The target is `this`, `source`, or `entity:N`.

Read the rules currently in force at any time:

```bash theme={null}
curl -s http://localhost:3917/rule/list
```

## Rules as a scenario document

The DSL is a shorthand. The full data form is the rule list inside a
[scenario](/concepts/determinism#replaying-through-the-api) — a declarative document you
export, edit, and re-apply. Here the condition and each action are fully typed values:

```json theme={null}
{
  "rules": [
    {
      "when": { "kind": "health_below", "threshold": 50 },
      "filter": "any",
      "actions": [
        { "action": "heal", "target": "this", "amount": 20 }
      ]
    }
  ]
}
```

Because rules are values, you can do things that compiled callbacks make impossible: list
them, diff two rule sets, generate them programmatically, change them mid-run, and ship a
world's entire logic as a file.

## Two kinds of rule: deterministic vs. the stochastic answer key

The rules above — created over HTTP via `/rule/create`'s string DSL or the typed form in a
[scenario](/guides/deterministic-replay) — are **deterministic**: a condition fires a fixed
effect. They drive gameplay, and they're what an agent authors at runtime.

The [world-engine](/evaluation/overview) layer adds a second, richer rule type: a **stochastic
rule** that names a random variable and attaches an **explicit probability distribution** over
outcomes. Because that distribution is *data* — not a hidden `rand()` call — the engine reads
the exact probability of every next outcome analytically. That declared distribution *is* the
true next-step distribution, which is what makes Euca an exact
[answer key](/evaluation/overview) for grading world models.

<Note>
  Stochastic, distribution-bearing rules are authored in **Rust** (`euca_rule::Rule` carrying a
  variable + an outcome distribution, via the online world) and hosted as pre-built evaluation
  sub-worlds. An agent **cannot** create a distribution-bearing rule over the HTTP or CLI
  surface — the agent-facing rules (`/rule/create`, scenarios) are the deterministic kind.
</Note>