Pilot runbook
Four weeks, scheduled and scoped in writing.
This is the page a delivery PM can schedule from: what happens on which day, who owns what, and the criteria that decide go or no-go at the end. It is deliberately boring — read-only first, one governed change last, rollback exercised in between.
Scope, in writing
The pilot is Observe + Report + one governed PR. Autopilot (autonomous tuning) and DCIM/BMS integration are explicitly out of scope — facility topology comes from node labels or a topology.yaml your facilities team fills in. Nothing in the pilot writes to your cluster; the one change ships as a pull request you review, merge, and roll back yourself.
Start Day 0
Email hello@iversoncloud.com with the subject Pilot Day 0. Response SLAs, stated so you can hold us to them: the Day 0 walkthrough is scheduled within 2 business days, and topology-worksheet validation turns around in 1 business day.
One piece of lead-time advice: request the one-line diagram from your facilities team in week 0, before Day 0 — facilities calendars are the long pole in every pilot we have scoped.
Contingency, in writing: if topology coverage stalls under 80% by the end of week 2, the pilot re-scopes to zone-level findings and the coverage gate is waived in writing — never silently ignored. The go/no-go table stays honest either way.
The four weeks
Each phase has a deliverable you can put on a calendar. If a phase slips, the topology conversation with facilities is almost always why — schedule it first.
Install, collect, first report — same day
- One Helm command installs a read-only collector Job. Its ClusterRole grants get/list only — no secrets, no ConfigMap bodies, no write verbs; the full YAML is printed verbatim on /methodology and your platform team can review it in one sitting.
- The collector writes a single estate.json to your side. You render it at /report/live in your own browser — nothing is uploaded, nothing leaves the cluster.
- Same day, we walk the report together — starting with its provenance caveats, so everyone knows what the snapshot could and could not see before anyone argues with a finding.
Facility topology authoring
- The cross-org dependency, named out loud: the transformer/UPS/PDU map is not a Kubernetes object. It lives with your facilities team — usually as a rack elevation doc or a DCIM export — not with the K8s team that granted cluster access. Booking that conversation in week one is the strongest predictor of pilot velocity we know.
- We provide the topology worksheet and the validator; you provide the one-line diagram. The validator treats cycles and orphan feeds as hard errors, not warnings — a broken chain would silently understate every blast-radius number, so it refuses to. Dual-corded racks are declared with feeds: [a, b] redundancy; what is not declared is labeled worst-credible-case, never assumed.
- NetBox shops have a shortcut: tools/netbox_to_topology.py in the repo converts a NetBox export straight into a validated topology.yaml — start from it and hand facilities a diff to correct, not a blank worksheet.
- Two optional week-2 enrichments, once the basic chain is mapped: ratedKw on a feed lets the engine demote paper-redundancy that cannot electrically carry the surviving load, and rideThroughMinutes on a cooling domain prices the checkpoint race a cooling failure runs. Neither gates the coverage stamp.
- Every re-collect stamps a facility-coverage percentage on the report, so topology progress is a number you can put in a status update, not a feeling.
One governed PR, exercised end to end
- One accepted, non-critical finding becomes a pull request: the finding it resolves, the expected delta, its cost as well as its benefit, and a paired apply + rollback script.
- The rollback is exercised, not just written. Merged, effect observed, rolled back cleanly — that sequence is the exit bar, because a rollback nobody has run is a rollback nobody has.
- Stated plainly: we have demonstrated this loop on our own production estate — a governed draft PR with an apply/rollback pair — not yet as a repeated production loop at a third party. The pilot is scoped to one governed PR end to end; it is not an autopilot trial.
Go / no-go criteria
Agreed before Day 0, judged at the end of week 4. A pilot that fails these criteria cleanly is a useful result — it means the product did not earn the next conversation.
| Criterion | Measured by |
|---|---|
| The report surfaced at least one finding your existing dashboards missed — and the workload's owner accepted it as real in the findings review. | written disposition per finding: accepted / disputed / known — plus whether the operator was AWARE of it beforehand |
| Facility topology covers ≥ 80% of nodes by the end of week 2. | the coverage stamp printed on the report |
| One governed PR merged and rolled back cleanly, with its measured effect compared against the predicted delta. | PR history + the week-4 re-collect diff |
| You can state whether you would pay for Govern. Either answer is a valid pilot outcome. | your call, on your numbers |
Who owns what
The pilot has exactly one cross-org handoff on your side (facilities → platform) and one approval gate (the PR). Everything else is listed so nobody discovers an ownership question in week 3.
| Workstream | You | Us |
|---|---|---|
| ClusterRole review + install | Platform reviews the RBAC (one sitting) and runs the Helm command | Ship the chart; keep the verbatim ClusterRole printed on /methodology |
| Collection | Run the collector; estate.json stays on your side | Same-day report walkthrough, provenance caveats first |
| Facility topology | Facilities team supplies the one-line diagram (rack → PDU → UPS → transformer) | Worksheet, validator (cycles/orphans are errors), coverage stamp |
| $/GPU-hour price | Finance supplies the blended figure | Mark every dollar as estimated until it arrives |
| Findings review | Owners disposition each finding: accepted / disputed / known, and record whether they knew beforehand — unaware-then-confirmed is the discovery metric | Re-derive any disputed number from /methodology, together |
| The governed PR | Review, merge, roll back | Draft the PR with expected delta, cost, and the apply/rollback pair |
| Go/no-go | Make the call | Put the numbers in front of you — both directions |
Rollback
The whole pilot uninstalls in two commands, and the data was never anywhere but your side.
helm uninstall iverson-collector -n iverson # removes Job, SA, ClusterRole, binding kubectl delete namespace iverson
Nothing else was installed and nothing was written to any workload. estate.json lives on your side — delete it and no trace of the pilot remains anywhere.
Before you schedule it
Every number the pilot's reports will show is defined on /methodology, and the procurement questions — what is collected, where data lives, security posture stated honestly — are answered on /trust.