// audit plane

The spine under every move.

Every change Magistry makes is recorded with its trigger, its evidence and who applied it: catalog writes, ad network changes, helpdesk replies and Brain actions. Approvals, rate limits and a kill switch you own sit in front of the writes.

Install on Shopify

See decision rows

Live A reason on every change Store changes reversible A kill switch you own

audit plane · today, example

catalog changes      : 61
  ├─ optimize_loser    38
  ├─ discount_test     14
  └─ draft              9

google ads changes   : 12
  ├─ shared negatives   5
  ├─ adjust_budget      4
  ├─ pause_campaign     3
  └─ read back          9 confirmed

helpdesk replies     : 40 sent
  ├─ judge passed      36
  └─ held for review    4

kill_switch          : off
rate limits          : 0 ceilings hit
store locks          : 1 active

// why it exists

Autonomy you can read.

If you can't read what an agent did and why, you can't trust it. The audit plane exists so every operator, from engineer to finance lead to CEO, can answer one question fast: what moved, and on what basis.

An agent without an audit is just a leak.

Autonomy without a paper trail means you find out about a bad write in a dashboard, days later. The audit plane turns 'the agent did something' into a row you can read, evaluate and, for a change to your store, reverse.

Every agent keeps the same kind of record.

Catalog changes, ad network changes, helpdesk replies and Brain actions are each recorded with the trigger, the evidence, who applied it and when. A change a person makes is recorded the same way.

The value before the change is kept.

Before a change is written, the value it replaces is captured from the live system. Reverting puts back what was really there, and the revert is recorded against the original change.

// what it stores

What each record holds.

Each agent keeps its own record with the same parts: what changed, why, the evidence behind it, and who applied it. The Marketing Brain's actions are recorded the same way.

Catalog changes

Catalog Specialist

Every lifecycle change for a product: from-state, to-state, trigger, evidence, whether it reached Shopify and when. Last 30 days, measured 17 Oct 2026: 1,785 catalog writes applied to Shopify.

// schema

productfrom stateto statetriggerevidenceapplied atapproved by

Ad network changes

Campaign Specialist

Every change written to an ad network, such as shared negative lists, budget moves, pauses and campaign settings. After a write, Magistry reads the account back to check it landed. Last 30 days, measured 17 Oct 2026: 194 changes applied; 116 confirmed on read-back, 71 could not be read back, 1 contradicted.

// schema

campaignactiontriggerreasoningevidenceapplied atread-back

Helpdesk replies

Helpdesk

Every reply the helpdesk drafts is judged for policy and factual grounding before it can be sent, and the score, verdict and any block reason are kept with it. Last 30 days, measured 17 Oct 2026: 658 replies sent, 104 of them by people.

// schema

threadactionjudge scoreverdictblock reasonapproved byapplied at

// phase model

Two phases. One executor.

Each module that writes to your systems runs in a mode you choose. In dry-run it reasons in full and writes nothing on its own. In live mode the same proposals are applied, inside the same rules.

// phase 1

Dry-run: plan, judge, log, do not write.

The Brain and the agents run their full loop with the final write held back. You read what they would have done, and you decide when to switch a store to live.

✓Evidence captured on every proposal.
✓Nothing is written to your systems on its own.
✓In the Brain's dry-run, a change you approve yourself still goes through.
✓You switch the mode; nothing switches it for you.

// phase 2

Live: changes apply inside your rules.

Once you switch a store to live, the executor applies changes inside the limits you set. Rate limits hold, the kill switch overrides, and a per-store lock stops two runs writing to the same store at once.

✓Per-action rate limits checked before each write.
✓Kill switch read on every run, not only at startup.
✓Irreversible Brain actions always wait for you.
✓The value before each change is kept, so it can be reverted.

// earned autonomy

Autonomy is earned per lever, not granted per plan.

Above the phase model sits the Marketing Brain's trust ramp: each lever, such as a budget move, a negative keyword list or a feed repair, earns its own autonomy from its own measured record. Fast down, slow up.

Trust ramp

Promotion to auto-apply needs a real record on that lever: at least 6 measured outcomes, a win rate of 70% or more, a recent win and no loss in the last 14 days. A win rate under 40%, or 3 losses in 14 days without a win, sends the lever back to your review. Irreversible actions are never auto-approved, at any trust level.

Verdict engine

Every applied action is scored win, loss or neutral once its full measurement window has passed, against your store's break-even ROAS and adjusted for how the whole store moved. Those verdicts are what the trust ramp promotes and demotes on.

Budget envelope

Per-domain soft daily spend caps. A budget increase that would breach the envelope is blocked before it reaches the executor; decreases and pauses are always allowed. A budget move is clamped to ±20% of the current budget.

// safety integration

Where the rails live.

These checks run when a change is about to be written, not when the configuration is loaded, so turning the kill switch on stops the next run without a restart.

Kill Switch

store-wide, in settings

When it is on, the executors stop before they write and pending changes wait. It is read at the start of every run, so turning it on stops the next run without a restart. Feed pushes have their own pause.

Rate Limiter

per action, per store

Each kind of action has its own ceiling, for example 35 product drafts a week or 50 Google Ads budget changes a day by default. When a ceiling is reached, the action is skipped and waits; it never goes past the ceiling.

Advisory Locks

one writer per store

Prevents concurrent executors stomping each other. Two runs can plan in parallel; only one can write to the same store at a time, and a revert takes the same lock.

Trademark Filter

before generated copy is written

Generated product and ad copy is checked against a trademark blocklist before it is written. A hit stops the write; it is never pushed silently.

// reversal model

Rollback, by design.

Before a change is written, the value it replaces is captured from the live system. Revert the change from the dashboard and the executor writes that value back, under the same lock and the same kill switch as the original write, and records the revert against the original.

One owner per change, and store changes can be reverted: a change to your store has one owner at a time, so two agents cannot write over each other. A helpdesk reply cannot be unsent, which is why replies are judged before they leave.

rollback · example

change      : discount_test   reversible
  product     : SKU-LIN-228
  delta       : -15%
  before      : 89.00 (kept before the write)
  status      : applied

revert
  action      : restore price to 89.00
  status      : applied
  reverted_by : operator (jane@store.com)

original stays on record, marked reverted

// works with