3. Navigating the Device Console
Read live telemetry and health, review capabilities, inspect artifacts pushed back, and organise devices into groups for bulk management.
The Nexus One console is your single pane of glass for every device on your premises. Open it from "My connections" — each paired device displays live telemetry and health status, the capabilities it offers, the anchored folders missions may read and write, the artifacts it has pushed back to the platform, the skills it has produced, and its remote-access settings. Nothing is hidden behind separate screens: one console, one device, full picture.
Telemetry and health tell you whether a device is online, responsive, and performing normally. Capabilities list what the device can do — run skills, process files inside anchors, produce artifacts. Artifacts are the results the device sends back to the platform; your raw data never leaves the device, only the outputs you allowed. This separation is the core of the sovereignty model: data stays on-site, results travel back.
Anchors are the folders you explicitly expose on the device. A mission can only read and write inside anchored folders; everything else on the device remains invisible to OUPI. You add or remove anchors from the console at any time, so the scope of what missions can touch is always under your control. Grants go one step further: you decide which capabilities @oupi may use, per device or per group. The default posture is "entire fleet sovereign" — nothing is granted until you say so.
Device skills are reusable procedures produced and tested locally on the device, bundled with their code, manual, and instructions. From the console you can enrich a skill, save a new version, share it with your team, or propose it to OUPI. Each skill shows whether it has been tested and on which device — giving you traceability before you roll anything out more broadly.
Device groups let you organise devices by location, role, or project — for example "Workshop", "Site A", or "Lab sensors". Once devices are grouped, you grant capabilities to @oupi at the group level instead of repeating the same configuration device by device. This is essential for fleets: one grant change on a group propagates to every member instantly.
Remote access opens a secure tunnel to the device behind your OUPI login, but it is off by default. Enable it only on devices you need to reach remotely, and use "Authorize local login" (six-character code displayed on the device) when someone needs to sign in physically. Both settings are per-device and revocable from the console.
Go to My connections, select a paired Nexus One, and review its console: check telemetry, verify which anchors are exposed, inspect any artifacts pushed back, then create or rename a device group and drag the device into it. Confirm the group's grants reflect your intended access policy.
The device console centralises telemetry, capabilities, anchors, artifacts, skills, and remote-access controls for each Nexus One. Anchors scope what missions can touch; grants control what @oupi may do — both default to nothing. Device groups let you manage rights in bulk across your fleet. Every action is revocable, and data never leaves the device unless you explicitly allow a result to travel back.