1. Read the grading before you design UI/UX carries the most weight. The winning move is not the most features — it's a dashboard where a plant manager finds the answer to "is my alarm system healthy, and what do I fix first?" in under 10 seconds. Every design decision below serves that. The judges grade on their test system with their alarms. So: Never hardcode source paths, priorities, areas, or display paths. Derive everything from queried data. Handle empty states gracefully (no data in range → clean "no events" message, not a broken chart). Assume a potentially large journal — paginate, limit, and bound every query by date range. 2. Core concept: "From triage to root cause" One view named Dashboard, structured as a story in three horizontal layers plus tabs: ┌─────────────────────────────────────────────────────────────┐ │ HEADER: Alarm Health Score (A–F) │ KPI ribbon │ Date range │ ├─────────────────────────────────────────────────────────────┤ │ FILTER BAR: priority ▾ area/path ▾ state ▾ search │ ├─────────────────────────────────────────────────────────────┤ │ TABS: Overview │ Analysis │ Bad Actors │ Journal │ │ │ │ (tab content = embedded sub-views, full remaining height) │ └─────────────────────────────────────────────────────────────┘ Header + filter bar are part of the main view (not docked — that's prohibited). Filters live in session props under the PrimeControls object so every sub-view binds to the same state. Signature feature: the Alarm Health Score A single composite A–F grade in the header, computed from ISA-18.2 benchmarks: alarm rate vs. target (<6/hr/operator), % time in flood, chattering alarm count, standing alarm count, priority distribution vs. the 80/15/5 rule. Clicking it opens a popup showing the sub-scores and why the grade is what it is. This gives judges an instant "wow, this tells me something" moment and anchors the whole dashboard around ISA-18.2 — which 8.3 now explicitly supports with alarm metrics. Second signature feature: the Insights panel A small "What changed" card on Overview generating plain-English findings via scripting: "Alarm rate up 34% vs. prior period — 61% driven by 3 sources," "2 alarms are chattering (>10 re-triggers/hr)," "Flood condition 2:10–2:40 AM Tuesday." Cheap to build (it's just threshold logic over data you already computed), huge perceived sophistication, and it's built for the operator. 3. Tab contents Overview (the 10-second answer) Active alarm counts by priority (big number cards, color by priority) Alarm rate timeline (XY chart, 10-min bins, shaded ISA target band, flood periods highlighted) Unacked / shelved / standing counts Insights panel Compact top-5 most-active-sources list → click drills into Bad Actors tab pre-filtered Analysis (trends & patterns) Heatmap: alarm count by hour-of-day × day-of-week (flex repeater of colored cells — reveals shift patterns, judges love it) Priority distribution donut vs. ISA 80/15/5 recommendation, side by side MTTA (time to ack) and MTTR (active→clear) trend lines Flood analysis: table of flood episodes (>10 alarms/10 min) with duration and top contributor Bad Actors (what to fix) Pareto chart: top 10 sources by event count with cumulative % line ("these 5 alarms are 60% of your problem") Chattering detection: sources re-triggering within short intervals Standing/stale alarms: active longer than 24h Fleeting alarms: active <10s (likely nuisance/deadband issues) Row click → detail popup: that alarm's event history, sparkline of daily counts, avg time-to-ack, top acking operators Journal (the raw truth) Paginated, searchable event table with state-transition coloring Per-event detail popup (full event properties, associated data) CSV export button (system.dataset.toCSV + system.perspective.download) 4. Standout ideas ranked (build vs. skip) Build — high impact per hour: Health Score A–F with drill-down popup Plain-English Insights panel Hour×day heatmap Pareto with cumulative line Chattering/fleeting/standing detection (simple interval math, very "alarm-management-literate") Consistent design system via style classes: one accent color, priority color scale used identically everywhere, generous whitespace Build if time allows: 7. Native Drawing Editor (new in 8.3) for the Health Score gauge — shows 8.3 fluency with zero rule risk (it's native) 8. "Compare to prior period" deltas on every KPI (▲/▼ chips) 9. Shift report popup: pre-formatted summary for shift handover Skip — poor ROI or risky: Event Streams / Kafka (gateway config won't travel with the submission; graded on their system) Alarm shelving controls (drifts toward alarm operations; brief says analysis) Live-updating everything (poll on refresh/interval is fine; don't burn hours on subscriptions) Elaborate animations, multi-theme switchers 5. Technical architecture Data access — prefer system.alarm.queryJournal / queryStatus over SQL. This sidesteps the entire database-agnostic problem: no dialect issues, no table-prefix coupling, works against whatever journal the judges configured. Wrap them in project script functions (PrimeControls.alarms.getJournalEvents(start, end, filters)) that return datasets. If you need SQL for heavy aggregation, keep queries dumb (SELECT with time-range params only) and do bucketing/grouping in Jython — that stays agnostic. If you must write dialect-specific SQL, provide all three variants and note it in the submission. Computation layer: one script module computes everything (rate bins, floods, chattering, MTTA/MTTR, Pareto, health score) from a single journal fetch per refresh. Store results on view custom props; sub-views receive them via view params. One fetch, many consumers — fast and consistent. Structure per the requirements: All resources under a PrimeControls folder: views, style classes, named queries, scripts Main view: PrimeControls/Dashboard Session custom props inside one object: session.custom.PrimeControls.{dateRange, filters, theme...} Journal table prefix PrimeControls_ if using SQL directly (note it in submission); default DB set on project Sub-views + Embedded View / Flex Repeater / Tab Container — all allowed. No docked views anywhere. Style classes: define the priority color scale, card style, chip styles once. Bind colors through classes, not inline — judges opening the Designer will notice discipline. 6. 8-hour plan HourWork0:00–0:30Fresh install ritual: project, folder structure, session prop object, style classes, priority color scale, page layout skeleton (header/filter/tabs). Configure local test alarms + a chaos script that generates realistic journal data (floods, chatterers, stales) — you can't demo analytics on 10 clean events.0:30–1:30Data layer: script module with journal fetch + all computations (bins, floods, chattering, MTTA/MTTR, health score). Test in script console before touching UI.1:30–2:30Header + KPI ribbon + filter bar, wired to session props. Health Score displayed.2:30–4:00Overview tab complete: rate chart, priority cards, insights panel, top-5 list.4:00–5:00Bad Actors tab: Pareto, chattering/standing/fleeting tables, detail popup.5:00–6:00Analysis tab: heatmap, donut vs. 80/15/5, MTTA/MTTR.6:00–6:45Journal tab: paginated table, event popup, CSV export.6:45–7:30Polish pass: spacing, empty states, loading states, responsive check, consistent number formatting, tooltips. This pass is where UI/UX points are won — protect this time.7:30–8:00Submission hardening: export project, import into a clean gateway, verify nothing references resources outside the PrimeControls folder, write submission notes (DB assumptions, prefix), submit with margin. Cut order if behind: Journal export → MTTA/MTTR trends → heatmap → shift report. Never cut the polish pass or the clean-gateway test. 7. Pitfalls checklist View is named exactly Dashboard, inside company folder Zero docked views (check page config) All session props inside the PrimeControls object No custom fonts/icons/themes/third-party modules — Material icons and built-in themes only Nothing hardcoded to your local tag paths or alarm names Empty date range / no data → graceful, not broken Large journal → queries bounded and paginated Default database set on the project Tested via export → import on a fresh gateway Submission note covers DB choice, prefix, any assumptions Post-event: upload to Ignition Exchange tagged Build-a-Thon 2026