Appearance
Illustrative customers
Dataplicity documentation and screenshots use a small set of demonstration fleets. The operating patterns are real. The company names, sites, and incidents are illustrative - not endorsements of real organisations, and not claims about named customers.
Use this page when a story names Northstar, Harbor, Polar, Solstice, Amber Field, or Meridian. It is the shared cast for business workflows and the Northstar cold-chain incident lab.
In product screenshots, Harbor Retail, Polar Freight, and Solstice Utilities often appear as customer records under an OEM organisation. That mirrors how OEMs map ownership in Dataplicity. The same names stand alone in stories when the narrative needs a vertical that feels familiar.
How to read them
Each organisation below answers four questions:
- What business are they in?
- How does a normal operating week actually run?
- What must someone answer without opening a laptop?
- Which Dataplicity surfaces and stories fit that week?
If you recognise your own fleet in one of these shapes, start from the linked workflow rather than from a feature catalogue.
Northstar Cold Chain
Vertical: Refrigerated logistics OEM. Ships Linux gateways and environmental sensors into reefers, cold boxes, and depot sites for 3PLs and food distributors.
How the business runs: Spoiled loads and SLA credits make “offline” and “warm” expensive when they arrive together. Night NOC watches corridors and depot clusters; day shift handles carrier escalations. End customers only ever need visibility into their containers - never the whole OEM estate.
Monday morning question: Which reefers are offline, warm, or both - and which customer is about to call?
Who uses Dataplicity day to day: OEM ops lead, NOC, support queue, and (read-only) the freight customer’s own ops TV.
Surfaces that matter: Fleet monitors scoped to cold-chain classes and critical sites; organisation logs; incidents and on-call; OEM NOC wallboard; customer-scoped display or status when a shipper needs calm facts.
Start here:
- Diagnose the Northstar cold-chain incident
- Monitor the cohort, not just the device
- Take the incident on the phone without losing the plot
- Tell the customer what is true without the shell
- Design the wallboard for who walks past it
Harbor Retail
Vertical: Digital signage and retail media. Media players, kiosk controllers, and store-edge Linux boxes in malls, QSR, and brand networks.
How the business runs: Pain clusters at open-of-business and after playlist or OS pushes. “The screen is black” tickets mix content faults with device and network faults. Field techs are expensive; remote proof of last check-in, process health, or a live camera avoids unnecessary truck rolls. Franchise or brand partners want a simple wall: their sites only.
Monday morning question: Which stores go dark before open - and is it the player, the playlist, or the site network?
Who uses Dataplicity day to day: Support floor, field ops, firmware/content engineering during rollouts, and brand partners on a paired display.
Surfaces that matter: Customer and site mapping; monitors for player classes; Remote Shell / Wormhole for break/fix; warranty and dispatch evidence; customer Display (not the internal NOC layout).
Start here:
- Decide dispatch vs remote fix on a field support call
- Ship the first customer unit you can still support
- Hand support from engineering to a real queue
- Tell the customer what is true without the shell
- Design the wallboard for who walks past it
- Map devices to customers and sites
Polar Freight
Vertical: Freight, trailer telematics, and roadside cabinets - often Starlink or mixed WAN.
How the business runs: Outages cluster by connectivity cohort and corridor, not by SKU. Support asks “how many trailers on this path?” before anyone opens a shell. Truck rolls for provider outages waste a week. Polar appears in the Northstar lab as the reporting customer when a Bristol depot loses temperature telemetry - the same cohort thinking applies when Polar runs its own telematics estate.
Monday morning question: Is this one bad unit, one site, or every device on Starlink (or another ISP) at once?
Who uses Dataplicity day to day: On-call ops, fleet support, and network-aware NOC during corridor events.
Surfaces that matter: ASN/ISP property tags; tag-scoped fleet monitors; map filters; connection quality on supported plans; incidents with altitude written as ISP vs product.
Start here:
- Blame Starlink (or not) before you blame your product
- Separate one bad unit from the network died
- Monitor the cohort, not just the device
- Diagnose the Northstar cold-chain incident
- Take the incident on the phone without losing the plot
Solstice Utilities
Vertical: HVAC, BMS, and utilities equipment. Building controllers, plant gateways, tanks and level sensors - often installed and serviced by contractors.
How the business runs: Shared SSH keys and customer-IT VPN theatre do not survive audits. Access must be scoped to a building or customer, with a trail of who did what. Install-base reporting and warranty context sit beside uptime. Regional contractors need enough access to fix a site without owning the OEM estate. Customer views stay calm and read-only.
Monday morning question: Which critical sites are dark before the shift - and can a contractor fix this without a truck and without the master keys?
Who uses Dataplicity day to day: Regional ops, contractor techs with scoped roles, OEM support, building owner on a customer surface.
Surfaces that matter: Site heartbeats and critical-site monitors; Remote Shell / Wormhole on an agent-initiated route; roles and audit; contractor-safe access; regional wallboard with site labels rather than raw device spam.
Start here:
- Fix a remote site without a truck roll
- Get the first site device into a known state
- Know which assets are dark before the shift starts
- Let contractors help without handing them the keys
- Prove what changed after a maintenance window
- Support team access
- Design the wallboard for who walks past it
- Keep your runtime; add the operations layer
Amber Field Systems
Vertical: Agtech and remote energy. Farm and field gateways on cellular, sparse power, scheduled sampling and upload windows.
How the business runs: Devices sleep, sample, and check in on a schedule. “Offline” is often expected; a missed window is the real signal. Geography is large and density is low. Firmware alignment across sparse fleets matters more than one-second charts. Customers care whether yesterday’s samples arrived, not whether a NOC saw a green tile at 02:00.
Monday morning question: Which regions missed their upload window - and is that modem health, power, or a scheduled job that never ran?
Who uses Dataplicity day to day: Field ops, firmware/ops during sparse rollouts, and regional managers watching check-in cohorts.
Surfaces that matter: Fleet map with region tags; scheduled tasks and fleet jobs; heartbeats interpreted as windows; mixed-age images under one agent; logs when a unit finally reconnects; resilient file requests when connectivity will not stay up for a live session.
Start here:
- Keep one ops layer across ancient and brand-new images
- Know which assets are dark before the shift starts
- Prove what changed after a maintenance window
- Request the evidence now; let connectivity catch up
- Scheduled tasks
- Fleet jobs
Meridian Autonomy
Vertical: Robotics and autonomy. Linux brains on mobile platforms or fixed cells - sensors, staged OTA, remote console for recovery.
How the business runs: Staged firmware is sacred. Rollouts pause when an incident spike aligns with a pilot cohort. Engineering and NOC share a wall during releases: job progress, incidents, sometimes a camera on a canary cell. The first commercial unit must already be a supportable record - class, customer, site - or engineering becomes permanent tier one. Runtime (containers, custom supervisor, Greengrass, and similar) usually stays; Dataplicity is the ops layer beside it.
Monday morning question: Is the pilot cohort healthy enough to expand - and can support find unit #1 without calling the firmware lead?
Who uses Dataplicity day to day: Firmware eng, OEM ops, support queue after handoff, release war-room during OTA.
Surfaces that matter: Device classes and customer mapping at first ship; fleet jobs and rollout tags; organisation logs correlated to firmware; incidents; Remote Shell / Wormhole for recovery; browser workspace during the war-room.
Start here:
- Ship the first customer unit you can still support
- Carry one device record from factory to field ticket
- Hand support from engineering to a real queue
- Keep your runtime; add the operations layer
- Logging for a fleet, not a terminal
- Run the fleet from one browser workspace
Coverage map
| Organisation | Familiar business | Primary Dataplicity angle |
|---|---|---|
| Northstar Cold Chain | Refrigerated logistics OEM | Critical-site monitors, cold-chain cohorts, NOC + customer altitude |
| Harbor Retail | Signage and retail media | Customer/site mapping, open-of-business health, dispatch vs remote |
| Polar Freight | Freight / roadside / Starlink | ISP cohorts, network-vs-product decisions |
| Solstice Utilities | HVAC / BMS / utilities | Scoped contractor access, remote site fix, audit |
| Amber Field Systems | Agtech / remote energy | Intermittent connectivity, schedules, mixed-age images |
| Meridian Autonomy | Robotics / autonomy | First-ship supportability, OTA evidence, runtime fit |
Dashboard layouts (for screenshots and Displays)
Design each layout for one audience and one daily question. Pair a Display to that layout at 1920×1080. Prefer ops widgets over cloud chrome unless the story is NOC + backend estate. Full method: Design the wallboard for who walks past it. Capture guidance: Dashboards and displays.
Local Docker: python manage.py seed_illustrative_dashboards --replace-widgets creates these layouts on the demonstration orgs, then capture from Display-authenticated output URLs (not the designer chrome).
Northstar corridor NOC
Polar Freight customer Display
Harbor brand partner Display
Polar Starlink incident wall
Solstice regional contractor bay
| Organisation | Audience / room | Daily question | Widget intent (smallest useful set) |
|---|---|---|---|
| Northstar | OEM corridor NOC | Offline, warm, or both - which customer calls? | device_monitors (cold-chain ratio + critical site), active_alerts / active_incidents, fleet_map, user_impact, on_call, clocks |
| Northstar → Polar | Customer Display / status | Are our containers reachable? | Customer-scoped monitors, site impact, big clock - no OEM-wide device spam |
| Harbor | Brand partner Display | Are our stores up for open? | Customer-scoped site health, service_endpoints or player-class monitors, active_alerts, camera_live (flagship only), big_clock |
| Harbor | Support floor | Which stores need us - remote or dispatch? | Customer/site impact, open field incidents - not raw shell history |
| Polar | Incident wall (temporary) | Starlink, other ISP, or us? | fleet_map filtered to location:isp:*, cohort device_monitors, active_incidents, connection-quality context on drill-down |
| Solstice | Regional / contractor bay | Which critical buildings are dark? | Site heartbeats / critical-site any-offline, clear site labels via text, on_call - no PII on a shared TV |
| Amber Field | Field ops wall | Which regions missed the upload window? | Region-tagged map, cron_status / active_scheduled_tasks, active_fleet_jobs, heartbeats as windows |
| Meridian | OTA war-room | Is the pilot healthy enough to expand? | active_fleet_jobs, active_incidents, rollout-tagged monitors, optional camera_live on canary, logs adjacent in the browser workspace |
When capturing for docs or marketing: use Display pairing (not the designer chrome), name the illustrative organisation in alt text, and keep the disclaimer that companies are demonstration fleets.
Related
- Business workflows
- Map devices to customers and sites
- Dashboards and displays
- Customer projects - verified real projects (separate from this illustrative cast)