MainsKeeper · Round 3 / Round notesFictional demonstration data — not real equipment

Round 3 · notes · nonfinal

MainsKeeper, round three

Three more directions, built to broaden the range rather than refine what exists. These notes cover what the round set out to do, how 7–9 differ, how the five corrections are applied, issues inherited by concepts 1–6, invented fixture values, state coverage and the questions we need you to answer. No direction is selected.

Fictional demonstration data — not real equipment

What this round set out to do

  • Broaden the range considerably. You were not sold on any of 1–6, so 7–9 avoid everything already explored (editorial report, dark control board, nightclub, friendly site workspace, blue timeline, graphic inbox) — no variation of an existing dashboard and no palette swap.
  • Cover three different home models: an equipment grid (7 Datum), a relationship map (8 Lattice) and a station chart (9 Synoptic), with one deliberately risky visual idea (Synoptic’s weather framing).
  • Make marks judgeable on their own: the round 3 comparison shows all nine marks in a logo-only section, with a mark-only view.
  • Apply five corrections to the shared scenario (below) and record — without fixing — where 1–6 conflict with them.
  • Each new concept ships an identity board with editable SVGs and an outlined wordmark, self-hosted SIL OFL fonts (WOFF2), a working desktop dashboard with a calm / incident switch, a 390px mobile view and a mainskeeper status CLI preview with a NO_COLOR rendition.

The three ideas

7 · Datum

lettering-led equipment workspace

A light-first working instrument. A datum is the fixed level you measure from; one level line runs through the drawn wordmark. The home is a fleet line, an incident strip and a sortable 13-column grid of all six UPSs, with an overlay inspector and a compare dock.

Answers “which piece of equipment, and how does it compare?” Restrained: greys, graphite and a single copper accent for “you are here”.

Detailed review of Datum · Dashboard — Datum

8 · Lattice

relationship and coverage map

A dark-first map of who watches what: collectors → UPSs → equipment in four site clusters, with reads, powers and checks links. Selecting anything lights its path; a coverage toggle shows what nobody watches.

Answers “what depends on what, and where are the blind spots?” Symbol-led: mint for live, sodium for selection.

Detailed review of Lattice · Dashboard — Lattice

9 · Synoptic

power weather service

A power weather service: sites as stations, readings as observations, UPS runtime as a labelled forecast, late records as late reports and incidents as plain-headline bulletins, on a station chart that says it is not a map.

Answers “what are conditions, and what has been reported late?” The visual risk: sage paper, weather-chart colours, a wind-barb mark.

Detailed review of Synoptic · Dashboard — Synoptic

How they differ

Between 7, 8 and 9

  • Home: a table of equipment · a map of relationships · a chart of stations with bulletins.
  • Finding a problem: incident strip and counted condition chips · incident rail and node shapes · headline bulletins and red pennants.
  • Investigating: inspector and compare · path highlighting and upstream/downstream traversal · station report with observed vs forecast and late reports.
  • Ground and colour: light and nearly colourless · dark with two signal hues · light with a full weather-chart palette.
  • Mark: a letter (the Datum K) · a woven symbol · a pictogram from a 15-symbol system.

Full comparison table

Relative to 1–6

  • Datum is the first concept led by drawn lettering and the first equipment-grid home; earlier light concepts (Vigil, Porchlight, Meridian, Docket) are prose-, site-, time- or queue-led.
  • Lattice is dark-first like Feeder Board and Brownout, but cool and symbolic rather than industrial or theatrical; it is the only concept that makes coverage (what is not watched) a first-class view.
  • Synoptic is the only concept built on an extended metaphor with its own pictogram grammar; Brownout was theatrical in styling, not in model.
  • All three self-host OFL fonts, as 4–6 did.

How the corrections are applied in 7–9

Five corrections to the shared scenario apply this round: recovery is independent of the history upload; open incidents include acknowledged ones, and severity, acknowledgment, recovery and sync are separate attributes; site summaries show mixed states; the first observation after a gap does not establish when power returned; completed episodes show when the start and the end were each received. Pointers are to the incident state of each dashboard (file:line in the concept folder; “fixture” means the line holds the concept’s data object).

Correction7 Datum8 Lattice9 Synoptic
Recovery stands on its own; the upload backlog is a separate sync attributeDuplex reads “Recovered 15:02 · uploading backlog, 1,248 pending” in the fleet line; the incident strip has separate Recovery and Sync fields.g/dashboard.html:482–493Duplex cluster: “Recovered 15:02” with “Sync (separate) 382 of 1,630 uploaded · 1,248 pending”; detail panel repeats the split.h/dashboard.html:350 (fixture)Duplex plate: “Recovered 15:02 · history still uploading”; the bulletin lists Recovery and Sync as separate attributes.i/dashboard.html:664–668, 735
Open includes acknowledged; severity, acknowledgment, recovery and sync are separate“Open incidents 3 · incl. 1 acknowledged”; each incident shows severity, state, ack, recovery, sync and notifications as separate fields.g/dashboard.html:493 · incident stripIncident rail entries and the detail panel carry each attribute separately; Duplex stays open while acknowledged.h/dashboard.html:350 (fixture: “3 open · 1 critical · 1 acknowledged”)Bulletin attribute list: Severity, State, Acknowledged (jp 13:52), Recovery, Sync, Notifications.i/dashboard.html:735
Mixed site states (Broadwater)Fleet line: “1 of 2 UPSs on battery · 1 on utility (separate circuit)”; both UPS rows in the grid.g/dashboard.html:478Broadwater cluster summary uses the same wording; the two UPS nodes carry their own states.h/dashboard.html:350 (fixture)Broadwater station plate with two station plots in different states.i/dashboard.html:541
First observation after a gap does not establish return timeDuplex timeline: “Utility first observed 14:52, return time unknown between 14:30 and 14:52.”g/dashboard.html:544Duplex evidence timeline: “Utility first observed present at 14:52 (first record after the gap). Return time unknown — sometime between 14:30 and 14:52.”h/dashboard.html:350 (fixture)Duplex report (“The Duplex story”) and gaps list state the same, with the 14:52 timestamp marked uncertain ±90 s.i/dashboard.html · station report
Completed episodes show start receipt and end receipt separatelyInspector “Recent episodes”: yesterday 21:14–21:31 with start record received 21:14:03 and end record received 21:31:05; Home 06:42 likewise.g/dashboard.html:603, 611Duplex and Home evidence: “Start record received 21:14:03; end record received 21:31:05.”h/dashboard.html:350 (fixture)Late reports table lists event time, received time and lag for start and end of each episode (06:42:49, 21:14:03, 21:31:05).i/dashboard.html:603–608, 712–715, 834

Inherited issues in concepts 1–6 (recorded, not fixed)

Concepts 1–6 are locked and were not rebuilt. Reading their sources against the corrections and the round-two inventory found the following. Paths are under concepts/; 1–3 use the round-one scenario.

  1. Recovery tied to the backlog. Duplex is described as staying open, or not fully recovered, “until backlog verified” — the recovery and the upload are fused rather than shown as separate attributes. Found in all six concepts. a/dashboard.html:512, 516, 877 · a/mobile.html:292 · b/dashboard.html:816 · b/mobile.html:581 · c/dashboard.html:509, 1052 · c/mobile.html:289, 423 · d/dashboard.html:770 · d/mobile.html:805 · d/cli.html:330, 345, 360 · e/dashboard.html:320, 467 · e/mobile.html:348 · f/dashboard.html:463, 466, 553 (filter “Recovered — awaiting backlog”) · f/mobile.html:436, 439, 526 · f/cli.html:296, 336
  2. “Recovering” used as a severity or status bucket. Duplex’s severity (Warning) is replaced by “Recovering”, merging severity with recovery and upload progress. a/dashboard.html:510, 771, 873 (“Severity ◐ Recovering”) · b/dashboard.html:407, 807 · c/dashboard.html:509 · d/dashboard.html:387 and d/mobile.html:422 (“1 critical · 1 warning · 1 recovering”) · e/dashboard.html:318 · f/dashboard.html:460 and f/mobile.html:433 (sev: "recovering")
  3. Acknowledged incidents treated as not open (Docket only). The State filter derives state as acknowledged or open, so the “Open” chip excludes the acknowledged Duplex docket. (Open-incident counts elsewhere read 3 and do include Duplex.) f/dashboard.html:553, 557 · f/mobile.html:526, 530
  4. A single site power state that hides Broadwater’s mix. No concept uses “1 of 2 UPSs on battery”; these summaries give Broadwater one state although BW Office UPS is on utility on a separate circuit. a/dashboard.html:578 (watch-line row “▲ on battery”) · b/dashboard.html:438 (“◆ ON BATTERY · CRITICAL”) · b/mobile.html:347 · d/dashboard.html:365 (Places tab “On battery · 13 min”), 392 · d/mobile.html:427 · e/dashboard.html:425–430 (one “UPS operation” lane per site, already noted as a round-two tradeoff) Borderline: c/dashboard.html:543 names the UPS (“On battery — BW Rack UPS since 15:09”) but does not state the mix in the booth line.
  5. 14:52 treated as the time power returned. The first record after the gap is presented as the start of utility. d/dashboard.html:529 and d/mobile.html:564 (“On utility · since 14:52 (±90 s)”) · b/dashboard.html:825 (chart description “on utility from 14:52 plus or minus 90 seconds”) Handled correctly: c/dashboard.html:1058 and f/dashboard.html:730 (“We don’t know when utility returned inside the gap”).
  6. Completed episodes without separate start and end receipts. Yesterday’s Duplex outage (21:14–21:31) appears with no receipt times in Porchlight and Docket; Meridian shows both receipts for it but gives the Home 06:42 episode only one (06:42:11). Concepts 1–3 do not show yesterday’s episode at all (round-one scenario) — absent, not wrong. d/dashboard.html:561, 793 · d/mobile.html:596, 828 · d/cli.html:281, 312 · f/dashboard.html:497–514 · f/mobile.html:470–487 · f/cli.html:421, 443 · e/dashboard.html:440–441 and e/mobile.html:321–322 (rcv 06:42:11 only)
  7. Collector count errors in 1–3 (already recorded in round two). “3 of 5” collectors in the incident and “5 of 5” in calm, where six collectors are listed; Vigil’s kicker says “five collectors”. a/dashboard.html:392, 422, 428 · a/mobile.html:224, 228 · b/dashboard.html:367, 368 · b/mobile.html:284, 285 · c/dashboard.html:813 · c/mobile.html:299

Fixture values invented by the 7–9 builders (disclosed)

  • 7 Datum: BW Office UPS input 120 V (the scenario does not give it); several reading ages; calm-state Duplex runtime estimate of 33 min; circuit names; read-method text (NUT usbhid-ups, SNMP via network management card). concepts/g/dashboard.html · concepts/g/mobile.html
  • 8 Lattice: some reading ages; calm-state Duplex charge 100% with est. 36 min; probe-target wording; calm summaries. concepts/h/dashboard.html · concepts/h/mobile.html
  • 9 Synoptic: calm-state Duplex est. 35 min; the 14:52 record shown as received “after 15:02”; a dotted “recorded on probe, still uploading” style. The Home episode end is drawn at 06:42:48 — derived as 06:42:10 + 38 s, not stated in the scenario — and is shown as an observation time distinct from the end-record receipt, 06:42:49, which matches the scenario. concepts/i/dashboard.html:603–608 · concepts/i/mobile.html
  • The three calm-state Duplex runtime estimates differ (33, 36 and 35 min) because the scenario gives none; round two’s Porchlight used 46 min.

State inventory

Demonstrated in 7–9

  • Healthy reporting (calm fleet) with yesterday’s resolved episode visible
  • Mixed site state (Broadwater 1 of 2 UPSs on battery)
  • On battery with live readings and a labelled UPS estimate
  • Contact lost, cause unknown, with last-known readings (Shop)
  • Recovered, with the history upload shown separately (Duplex)
  • Acknowledged but still open
  • History gap with unknown utility return time (14:30–14:52)
  • Uncertain timestamps (14:52 ±90 s)
  • Delayed records with received times (14:03 received 15:17)
  • Completed episodes with start and end receipts
  • Notification delivery failure (Shop push, retrying)
  • Unsupported measurements as “Not reported”
  • Coverage gaps — equipment with no agent (Lattice)
  • Filtered empty state (Datum)

Still to design

  • First use, no devices and initial loading
  • Low estimated runtime
  • UPS communication lost while the collector still reports
  • Suspected versus confirmed connectivity failure
  • Local storage limits on a probe
  • Enrollment states (waiting, approved, expired, rejected, offline)
  • Authentication expiry and revoked credentials
  • Maintenance windows
  • The full resolution flow
  • Notification settings and thresholds

Questions for you

  1. Which marks should stay in contention, regardless of which interface you prefer? (All nine are on one marks section, with a mark-only view.)
  2. Which home model fits how you work: the equipment grid (7), the relationship map (8), the station chart (9), or an earlier one — places (4), timeline (5) or queue (6)?
  3. Light-first or dark-first for everyday use?
  4. How much colour: nearly none with one accent (7), two signal hues on dark (8), or a full palette with fixed meanings (9)?
  5. Is the weather framing welcome, or a step too far for an operational tool?
  6. Should coverage — what nobody is watching — be a first-class view whichever direction continues?

No winner is selected and no concepts are combined this round.