A rule in Pathrule is not a note the assistant reads later. It is a guardrail that arrives before the assistant acts. Most documentation tells you what went wrong after it shipped. A guardrail can stop the change before it lands.

This page explains the difference between context that informs a turn and a rule that can block one. For the mechanics of how hooks deliver context, read [How hooks work](/docs/hooks/how-hooks-work) first. This page is about what a high-priority rule does once that context is in place.

## Pull asks. Push arrives.

The old model is pull. The assistant has to remember to ask for your conventions, call a tool, and read the result before it edits anything. If it forgets, it edits blind, and you find the problem in review.

The hook model is push. Context arrives at two moments without the assistant asking for it: when you submit a prompt, and right before the assistant uses a tool. By the time the assistant is about to write a file, the rules attached to that path are already in front of it. The assistant does not have to remember Pathrule exists for Pathrule to do its job.

## Two levels: advisory and blocking

Not every rule should interrupt the assistant. Pathrule treats rules at two levels.

- **Advisory rules** ride along as context. They appear next to the file the assistant is about to touch, with their priority, so the assistant can factor them in. They do not stop anything.
- **High-priority rules marked for enforcement** can block. When the assistant is about to make a change that violates one, the hook stops the tool call before the file is written and returns the rule text as the reason. The assistant reads the reason and tries again, this time inside the constraint. The non-compliant version never reaches disk.

The split is deliberate. Blocking a low-stakes edit wastes the assistant's turn and yours. Blocking is reserved for the rules where a violation is a real regression.

## Before and after

Consider a rule that says secrets never go into committed files, marked high priority for enforcement.

| | Without the guardrail | With the guardrail |
| --- | --- | --- |
| The assistant's intent | Add an API key to a config file to make a feature work | Same |
| What happens | The edit lands | The hook blocks the tool call before the file is written |
| When you find out | Later, in review (or not at all) | Never. The assistant sees the rule text and switches to an environment variable |
| Result on disk | A committed secret | Nothing non-compliant was written |

The same pattern applies to any rule a team has paid for in production: a data-access policy that must filter by user, a migration convention, a file that is generated and must not be hand-edited. The rule stops being a comment someone hopes the assistant read and becomes a wall it cannot walk through.

## Filenames pull the right memory

You do not always have to wait for a tool call. When your prompt names a file that an attached memory is about, the hook can surface that memory's body at prompt time, before the assistant opens anything. Naming the file you are working on is often enough to put the right context in front of the assistant on the first turn. When more than one memory matches the same filename, the hook shows the candidates instead of guessing.

## Fail open by design

A guardrail that breaks your workflow when it breaks is worse than no guardrail. Pathrule fails open. If the supervisor cannot evaluate a rule, errors, or times out, it does not block your work. The change proceeds. Enforcement is a safety net, not a gate you can get stuck behind.

You stay in control. If you ever want hooks off entirely, one file turns them off.

## Verify it yourself

You do not have to take the behavior on faith.

To see which hooks your AI client has registered, read its settings file. For Claude Code:

```bash
cat ~/.claude/settings.json
```

To turn every Pathrule hook off instantly (the kill switch), create one file:

```bash
touch ~/.pathrule/kill-hooks
```

The next tool call passes straight through with no Pathrule involvement. Remove the file to turn hooks back on:

```bash
rm ~/.pathrule/kill-hooks
```

To confirm a rule is actually attached to a path, open the assistant's Pathrule context surface in your editor. A high-priority rule shows up with its priority before the assistant acts on that path.

## What to read next

- [How hooks work](/docs/hooks/how-hooks-work) for the delivery mechanics and the empty-state behavior.
- [Writing rules](/docs/content/rules) for how to author a rule and mark it for enforcement.
- [MCP overview](/docs/mcp/overview) for the deep path the assistant uses when the hook is not enough.