Academy
6. Device Skills: Build, Version, Share, Propose
Produce reusable know-how on the device — with code, manual, and instructions — then enrich it, save new versions, share with your team, or propose it to OUPI.
A device skill is reusable know-how produced directly on your Nexus One. It bundles three elements: the code that performs the task, a manual describing what the skill does and how to use it, and instructions that guide execution step by step. Because the skill is built and tested locally — on your own sovereign device — it carries a tested status showing where it was validated. This local-first approach means the procedure is proven against real data and real conditions before it ever leaves the device.
Skills are versioned. After you create a skill, you can enrich it — refine the code, expand the manual, adjust instructions — and then save the result as a new version. Each version is preserved, so you can compare iterations or roll back if needed. Versioning is handled from the device console, the same place you monitor telemetry, anchors, and artifacts. This keeps your entire device workflow — data, results, and know-how — in one view.
Once a skill is solid, you have two distribution paths.
• Share with your team — colleagues with access to the same device or device group can use the skill immediately. Grouping devices (e.g., "Workshop", "Site A") lets you manage sharing and grants in bulk.
• Propose to OUPI — submit the skill for potential inclusion in the broader OUPI ecosystem. Proposed skills carry their tested status so reviewers know where and how they were validated.
Both actions are available from the device console alongside the skill's version history.
Skills operate within the same security model as everything else on the device. Only anchored folders are visible to missions, and capabilities must be explicitly granted to @oupi per device or group. The default posture is "entire fleet sovereign" — nothing is granted until you decide. This means a shared skill can only act on data you have deliberately exposed, and you can revoke access from the console at any time.
Before proposing a skill to OUPI, enrich it with a clear manual and detailed instructions. The tested status travels with the proposal, but a well-documented skill is far more likely to be adopted. Save a clean version specifically for the proposal so your working drafts stay separate.
Group related devices (e.g., all machines on a production line) so you can share skills and manage grants in bulk instead of configuring each device individually. Groups are created and edited from the console under "My connections".
Open "My connections", select a paired Nexus One, and navigate to its skills section in the console. Create or open an existing skill, enrich it (update code, manual, or instructions), then save a new version. Finally, use the share option to make it available to your team or propose it to OUPI.
Device skills turn local, tested procedures into reusable assets. Build them with code, a manual, and instructions; enrich and version them as they mature; share with your team via device groups or propose them to OUPI. Everything stays governed by anchors and grants — your data never leaves the device unless you allow it. Master this cycle and your Nexus One becomes not just a sovereign compute node but a knowledge factory.