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

# Domains and triggers

> How base decides what is relevant to the thing you just asked for, why triggers live in a config file while the content lives in the graph, and how to see a match before you rely on it.

A domain is a named subject with triggers attached to it. When your prompt or the file you are editing matches one of those triggers, everything attached to that domain becomes eligible to arrive. That is the whole mechanism, and it is deliberately plain.

## Triggers are in a file, content is in the graph

`domains.toml` holds triggers only: the keywords that match against prompts and the paths that match against files. The rules, decisions and notes attached to a domain live in the graph.

Two commands rather than one, for a reason. Triggers are policy you write and read as text, so they belong in a file you can put under version control and copy to another machine. Content accumulates as you work, gets edges to projects and entities, and needs to be queryable. Keeping them apart means you can retune what fires without touching what is said, and add what is said without editing config.

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
base domain create --name billing --keyword "invoice"
base domain add-trigger --domain billing --path "src/billing"
base rule add --domain billing --text "Money amounts are integer cents, never floats"
```

## How a match is decided

Matching is substring matching on the text and path matching on files. Nothing is fuzzy, nothing is semantic, and nothing is scored. A trigger either appears in what you sent or it does not.

That is a real constraint and it is worth planning around. A domain triggered on `invoice` does not fire on `billing`, and one triggered on `auth` fires on `author` too. Pick trigger words the way you would pick a grep pattern, then check.

## Check before you rely on it

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
base context "adding a discount to the invoice total"
base context --list
```

`base context` runs the same matching that runs during a turn, without sending anything. Paste in the prompt you actually mean to send. Either a domain matched or it did not, and you find out in a second rather than after a session where nothing arrived.

`base domain get <name>` shows one domain's full configuration, so you can confirm a trigger landed where you meant it to.

## Three sources, merged by name

Domains come from three places, loaded in this order:

1. The global `~/.base-gbl/domains.toml`, which applies everywhere.
2. The workspace's own `.base/domains.toml`, which overlays the global set by name.
3. Any installed extensions, which merge in at the lowest priority.

Overlaying by name means a workspace can redefine a global domain for that workspace alone, and everything else stays as it was.

<Warning>
  **The domain write commands do not all target the same tier.** `create`, `remove-trigger` and `remove` only ever touch the global file. `add-trigger` writes the workspace file. So a domain you create and then add a trigger to ends up split across two files, and a trigger added inside a workspace cannot be removed from the command line.

  `list` and `get` read both tiers merged, which is exactly why this is easy to miss: the domain keeps looking right. Established from source at `4866996`, the commit the shipped 0.13.2 binary was built from. Until it changes, edit the workspace `.base/domains.toml` by hand when you need to take a workspace trigger back off.
</Warning>

## Rules carry their reasoning

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
base rule add --domain billing --text "Money amounts are integer cents" --rationale "Floats lose pennies on repeated conversion, and the ledger has to reconcile"
```

A rule with `--rationale` is injected as the rule followed by its reason. Write the reason. A bare instruction gets argued with when it collides with something the agent thinks is more sensible; an instruction with a reason attached usually survives the collision.

## Next

<CardGroup cols={2}>
  <Card title="Tiers and scoping" icon="layer-group" href="/how-it-works/tiers-and-scoping">
    Global and workspace, how they merge, and what stays out of the other project.
  </Card>

  <Card title="Context reference" icon="sliders" href="/reference/context">
    Every domain, rule, standard and star-command command, with its flags.
  </Card>
</CardGroup>
