Chapter 8 · plan without false certainty

Implementation understanding and decisions

A practical sequence for building what the design already specifies — with Open items called out so diagrams do not silently decide them.

Proposed implementation sequence

Proposed Choose backend/runtime, durable schemas, account authorization, API boundaries — preserve entity ids, evidence timestamps, ownership semantics. Prototype localStorage is not the architecture.
Proposed Signed distribution and collector lifecycle for macOS, Windows, Fedora/Linux, Raspberry Pi; validate ESP32 board/UPS matrix and real storage budget; secure local credentials; USB/NUT/SNMP adapters.
Proposed Offline buffer, sequence/dedupe, observation-vs-receipt, clock uncertainty, gaps, aggregates, incident evaluation, notification delivery — replay suppression without suppressing new active evidence.
Port Lattice tokens/components; strip prototype review chrome from production builds.
Visual/browser acceptance remains a separate unverified obligation from the design handoff.

Broadwater as first real site

Recommendation Use Broadwater-like always-on Pi + dual UPS as an early pilot shape because the design already stresses revocation, network identity duplicates, and mixed USB/SNMP sources there. The handoff does not define a commercial pilot program. The review copy of the acceptance pass is the Broadwater pilot acceptance checklist. Passing it does not choose storage, operator login, or a release order for the other platforms. The replay scenario on that list is the Broadwater outage walkthrough: utility, then WAN, then replay, using bw-pi-01 and ups-bw-rack.

Suggested acceptance scenarios (recommendation)

Enroll → first contact → first reading with roles applied
Broadwater outage walkthrough: utility fails, WAN fails later, local collection continues, replay restores history, and a fresh reading recovers the incident
Witness-down while another witness reports (collector failure, not site loss)
Revoke → 401 → re-enroll keeps history/UPS links
Battery replacement creates new installation; prior evidence retained but non-qualifying

Operational concerns

Retention — prototype 7-day UI ≠ production policy (Open)
Upgrades / distribution — signed artifacts per platform (Proposed)
Hardware compatibility — publish validated matrices; keep ESP32 illustrative until proven
Monitoring MainsKeeper itself — collector doctor, backlog stalled alerts, cloud reachability exit 7 in CLI design

Cost drivers (no vendor prices)

Volume scales with collectors × sources × cadence × retention. Buffer disk, ingest bandwidth, notification volume, and Assurance history storage dominate before UI cost. Do not assume free-tier operation.

Figure 1. Multi-site product overview

**Takeaway:** Traceability anchor: sites and collectors in the design fleet map to dashboard mockups and CLI status examples.

Mockups: `product/app/index.html`, `site.html`, `collectors.html`, `ups.html`

Traceability

Requirement theme	Guide	Handoff anchors
Fleet visibility	Ch.1–2	`product/app/index.html`, `site.html`
Collector/source ops	Ch.3,5	`collectors.html`, `sources.html`, `network-source.html`, CLI
Incidents / history	Ch.4–5	`incidents.html`, `history.html`, `sync.html`
Battery Assurance	Ch.7	`CONTRACT.md` §22, `assurance.js`, UPS panel
Open decisions	Register	`implementation.html` §7

Continue to the decision register for items that most need review this round.