Academy
4. Anchors: Scoping What Missions Can See
Create, modify, and remove anchors — the exposed folders that define the exact perimeter missions may read and write on the device.
An anchor is a folder on your Nexus One device that you explicitly expose to OUPI. Missions can only read and write inside anchored folders — every other directory on the device remains completely invisible to the platform. This is the core scoping mechanism: no anchor, no access. You decide exactly which parts of your local file system are in play, and you can add or remove anchors from the device console at any time without repairing or restarting anything. Think of anchors as whitelisted perimeters: they define the precise surface area a mission is allowed to touch on your hardware.
Anchors work hand-in-hand with grants. Exposing a folder (anchor) makes it visible, but a mission still needs the right capability granted to @oupi — per device or per group — before it can actually read from or write to that folder. The default posture is "entire fleet, sovereign": nothing is granted until you explicitly allow it. This two-layer model (anchor + grant) means you control both what is visible and what can be done with it. Group your devices (e.g., Workshop, Site A) to manage grants in bulk instead of device by device.
Creating an anchor is done from the device console in My connections. Open the console for the target device, navigate to its anchors section, and select the local folder you want to expose. The folder immediately becomes available to any mission that holds the matching grant. To modify scope, add a subfolder as a separate anchor or remove the parent — anchors are independent of each other. Removing an anchor instantly revokes mission access to that folder; in-flight work targeting it will fail gracefully. No data leaves the device unless you have also allowed artifacts or answers to travel back.
Start narrow: anchor only the specific project folder a mission needs, not a broad parent directory. You can always add more anchors later. Removing an anchor is instant and non-destructive — the folder and its files stay untouched on the device; only OUPI's visibility is revoked.
Use device groups to streamline anchor management across multiple Nexus One units. If every device on "Site A" should expose the same shared data directory, group them first, then grant capabilities to @oupi at the group level instead of repeating the operation per device.
Open My connections, select one of your Nexus One devices, and enter its console. Add a test anchor pointing to a non-sensitive folder. Verify it appears in the anchors list, then remove it and confirm the folder disappears from the mission-visible scope. This round-trip proves you control the perimeter end to end.
Anchors define the exact folders a mission may touch on your Nexus One — everything else stays invisible. They pair with grants (per device or group) to form a two-layer access model whose default is fully sovereign: nothing exposed, nothing granted. You create, modify, and remove anchors from the device console in My connections at any time, with immediate effect. Start with the narrowest scope you need, expand deliberately, and revoke instantly when access is no longer required.