01
Proposed, with evidence
A proposal carries the campaign or segment IDs, spend and results over 7 and 28 days, the metric that tripped it, the exact change he wants to make, and the rollback. No evidence, no proposal.
How Misha ships
Misha can pause campaigns, build segments, create discounts and draft flows — because every one of those actions stops and asks first. This page is the operating contract: what gets proposed, who says yes, what gets written down, and what we still owe you.
The loop
The same four steps, every time, on every action that changes something. There is no fast lane.
01
A proposal carries the campaign or segment IDs, spend and results over 7 and 28 days, the metric that tripped it, the exact change he wants to make, and the rollback. No evidence, no proposal.
02
One button, where you already are. The audit is automated; only the decision is human. Nothing writes to your store, ad accounts, email or billing before the yes.
03
After you approve, the action runs and returns a reference: what ran, when, with what payload, and who approved it. The reference chain is the record — it answers 'why did this change?' months later.
04
Proposals you declined sit in the same record as the ones you approved. So do the approved calls that turned out to be wrong. The log is the product, not a side effect.
Scope
Misha ships with a published list of write actions — pause a campaign, move a budget, build a segment, create a discount, draft and send a flow, pause a subscription. Anything not on that list defaults to human-required, and new actions join the list deliberately and announced, never silently.
He starts read-only, on your data, before he ever holds write access: the same daily audits and proposals run with the write side switched off, and the approval log earns the yes before it uses it.
Shown, not hidden
A proposal you rejected is kept next to the ones you approved. An approved call that turned out to be wrong — the campaign that recovered anyway, the segment that did not move repeat rate — keeps its reference chain: the evidence he proposed on, your yes, the execution. When he is wrong, the record shows it.
That is the point of an audit trail. An operator that never sleeps needs a log you can argue with, and a log that only remembers the wins is a marketing asset, not an audit.
Coming next
The missing half of this page is the outcome: for every executed action, what happened next to the metric it targeted — including when the honest answer is “nothing”. We will show that here, from real executed actions, once the receipts module ships.
Until then: the approval record tells you what he did; the outcomes are the part we owe you. We are not publishing a mockup of numbers we do not have.
Questions
Not on anything that changes something. He reads your data and posts briefs on a schedule without asking, because reading changes nothing. Pausing a campaign, building a segment, creating a discount, sending a flow — every write stops for an explicit yes.
The proposal is recorded as declined and nothing changes. Declining costs nothing and requires no justification. He either comes back with better evidence or drops it — the log will show which.
Every executed action carries an audit reference: what ran, when, the payload, and who approved it. That record exists today. What happened after the action — the outcome receipts — is the part still being built, and this page will say so plainly when it arrives.
Because a governance page that only shows hits is a brochure. The approval record is how you audit an operator that never sleeps, and a record that hides misses is not an audit. Showing the wrong calls is the mechanism that makes the right ones believable.
Thirty minutes. We run the read-only audit live, and you see a real proposal with its evidence before anyone approves anything.