overview / rules / baseline-supervision-tamper

`baseline-supervision-tamper`

This reaches rabadon's own switch or ledger, which is the record that would have shown it happening.

what it refuses, and what it lets through

a session writing rabadon's own switches or records: the machine's $RABADON_DIR (enforce switch, mode marker, ledger) and a project's .rabadon/off, .rabadon/mode, .rabadon/on, .rabadon/net.json, .rabadon/state.json and .rabadon/handoff.md — through a redirect, touch, cp/mv/tee/dd, an in-place editor, rm, or the Write/Edit tools. guard.json and promise.json are judged by content instead (guard-weaken, promise-tamper). Reading them passes, and rabadon off is the one way to pause supervision, because it records the change.

From the floor table in docs/guard.md.

A project's .rabadon/{off,on,mode} silence the gate there, and net.json, state.json and handoff.md are records the gate trusts. guard.json and promise.json are judged by content instead (guard-weaken, promise-tamper).

From the comment in native/baseline.h above the code that decides it.

Moving or overwriting rabadon's own switch or ledger disarms it as surely as rm. Every operand counts: as a source the file is carried away, as a destination it is overwritten.

From the comment in native/baseline.h above the code that decides it.

The edit tools reach rabadon's own switches and records with no shell at all, so baseline-supervision-tamper judges them here too.

From the comment in native/gate_pre.h above the code that decides it.

the refusal, as the agent reads it

rabadon BLOCKED this action.
Rule: baseline-supervision-tamper — this reaches rabadon's own switch or ledger, which is the record that would have shown it happening
<verb> '<operand>' resolves inside $RABADON_DIR or onto a project's .rabadon/ switch or record — those hold the enforce switch, the mode marker, the hash-chained ledger and the verdicts the gate trusts. Turning supervision off is `rabadon off`, which writes the change down. Silence baseline-supervision-tamper by id if this is really what you meant.
Adjust the approach instead of retrying the same action.
(only the user can override this: they may add "baseline-supervision-tamper" to disabled[] in .rabadon/guard.json or run `rabadon off`. If this rule looks wrong for the task, stop and ask the user; do not switch supervision off yourself.)

Rendered from the strings in native/baseline.h and the envelope in native/gate_pre.h (Judge::refuse). A word in <angle brackets> is filled in from the command at the moment it is refused.

in watch mode the same verdict is recorded, and nothing is stopped

rabadon (watch) would have blocked this.
Rule: baseline-supervision-tamper — this reaches rabadon's own switch or ledger, which is the record that would have shown it happening
<verb> '<operand>' resolves inside $RABADON_DIR or onto a project's .rabadon/ switch or record — those hold the enforce switch, the mode marker, the hash-chained ledger and the verdicts the gate trusts. Turning supervision off is `rabadon off`, which writes the change down. Silence baseline-supervision-tamper by id if this is really what you meant.
Nothing was stopped. `rabadon on` makes this a real refusal.

switching it off

Only the user can switch it off, by id, in the project's guard:

{ "disabled": ["baseline-supervision-tamper"] }

or by pausing supervision with rabadon off, which records the change. Every other rule keeps running.

in the field

6 of the 778 records in the published field dataset (field.jsonl, 2026-07-27 to 2026-08-26) carry this id. STOP is a refusal in enforce mode; WOULD_BLOCK is the same verdict recorded in watch mode, where nothing is stopped.

event	records
WOULD_BLOCK	6

Counted from field.jsonl, the file the field page is built from.

rules

guard-weaken · promise-tamper

commands

rabadon on | off | status | toggle

baseline-supervision-tamper