How the platform fits together

Five ideas explain most of the platform. Once these make sense, the rest of the guide is just detail.

Tenant

Your organization. Every device, dashboard, alert and user belongs to exactly one tenant, and nothing crosses the boundary. Sign-in through Auth0 puts you in yours. Device traffic is separated the same way — MQTT topics are prefixed per tenant.

Device

A physical thing on your floor — most often an NVIDIA Jetson running cameras and AI inference locally. Devices announce themselves over MQTT when they come online, which is why they can show up as discovered before anyone registers them.

Devices report status, telemetry (CPU, memory, temperature), detection events, and the cameras they can see.

Device group

Configuration attaches to groups, not to individual devices. This is the single most important thing to internalise, and it trips people up.

When you set a detection threshold, choose text prompts, or pick an inspection profile, you are setting it for a group — and every device in that group picks it up over MQTT, immediately. A group is normally “the cameras on line 3”.

That is also why Captures and Inspection both start with a device group picker.

Location

Where things physically are, as a tree following the ISA-95 standard:

Site
└── Area
    └── Line
        └── Unit

Each level can only contain the level below it — a site holds areas, an area holds lines, a line holds units. Devices are assigned at line or unit level, not to sites or areas.

Locations are what let you say “show me the defect rate for the Aarhus plant” rather than reciting device IDs. See Locations.

Inspection profile

A named, revisioned bundle of what “correct” looks like for a given job — reference images, the comparison settings, and the classification schema results get sorted into. Profiles belong to a device group, and every save creates a new revision, so you can see exactly which version was running when a batch was inspected.

The picker in Inspection shows profiles as name (revision) for this reason.

How a detection actually travels

Useful when something looks wrong and you are working out where to look:

Camera → Jetson runs inference locally → publishes over MQTT
       → backend writes to the time-series database
       → Monitoring / Explore read it
       → Alerts evaluate it → Incidents track the response

Two consequences worth knowing:

• Inference happens on the device, not in the cloud. Video does not have to leave your network for detection to work. Live viewing uses a direct peer-to-peer WebRTC connection.
• Config changes apply immediately. Adjusting a threshold publishes over MQTT; the device applies it without a restart.

Where next

• Use case index — the complete list of what you can do
• Devices — put the above into practice