Verify accounts recovered after an incident
The after-the-fire sweep: statuses restored, delivery resumed, what the incident cost, what stayed paused on purpose.
IntentProof that everything restarted, nothing forgotten, learning acknowledged.
- 3
- Steps
- 6
- Tools
- 1
- Rules
- 1
- Failure modes
When to use it
Use it when
- After un-freezing.
- After platform outages.
- After billing failures resolve.
Do not use it when
- No specific contraindication beyond the preconditions below.
What it needs first
No single source is required: this one reads across whatever you have connected.
Preconditions
- The account is ticked in the dashboard, confirmed via list_accounts.
Inputs
window- Analysis window.Default: last 30 days.
Procedure
In order. Every tool named is one the gateway ships, and links to its reference.
Compare current statuses to the pre-incident record.
Confirm delivery actually resumed, not just statuses.
Date the gap and estimate the undelivered spend.
Decision rules
The observable condition, what it lets you conclude, and what takes the conclusion back.
When
Statuses restored but delivery has not returned
Conclude
Learning reset in progress: expected, dated, said out loud before anyone re-breaks things to 'fix' it.
Evidence every conclusion must carry
- Every figure carries its account, metric and window.
- Anything below a readable sample size is reported as unjudged, not as zero.
Where the agent stops
- The readout changes nothing. Any change it motivates goes through Safe Writes: preview, human confirmation, then apply.
How it goes wrong quietly
The cases where the analysis is wrong and still looks right. Read them before trusting a number.
- Restart spikes: platforms can overspend briefly on resume, and the first day misleads both directions.
What the answer contains
- 01Readout
- The figures, with windows and accounts named.
- 02Flags
- What deserves a deeper skill or a human decision.