Branch hierarchy

A Branch is Scout’s unit of local responsibility. It combines an administrative scope, a namespace boundary, a local controller, its own Branch Router, and the authority to manage the Clients assigned to it.

Network
└── HQ (root Branch)
    └── Vilnius (child Branch)
        ├── Vilnius Branch Router
        └── Team (child Branch of Vilnius)

Responsibility, not packet flow

The Network screen shows an administrative tree. It answers “who owns this part of the system?” It does not claim to be a live visualization of every router link or application flow.

The selected Branch stays visible in the shell. When you enter a child, pages and actions inherit that context: router inventory, Data Areas, grants, and settings are resolved for the selected Branch.

When an ancestor is looking into a descendant, Scout keeps a context banner visible. It names the acting ancestor, the Branch that actually owns and governs the displayed state, the prefix, depth, and freshness. Ancestor context is not presented as a local child sign-in.

Child authority

When a parent creates a child, it assigns a prefix inside its own boundary and issues bounded authority. The child cannot widen that prefix. Scout validates the same rule at the receiving boundary; a permissive browser form would not be sufficient authorization.

Each Branch also has local identity material. Recursive Branch intermediate CAs allow a child to issue local identities without holding an ancestor’s private key. A controller cannot sign on another Branch’s behalf.

Delegation depth

Delegation is governed by ceilings alone. A parent chooses at creation whether a child may itself onboard children, and every delegated envelope narrows monotonically at every hop — prefix, identity, actions, duration. Depth is emergent: no rule in the authority model reads absolute depth, and a mid-tree Branch operates in the same local frame as the root.

The qualified platform envelope is six subordinate Branch CAs under stock Zenoh’s verifier; creating a level beyond it is refused before any ceremony with an honest message. The UI exposes the delegation choice before creation, and a child’s own children are always created at that child’s controller.

Exercise the recursive path

The product walkthrough creates and activates one direct child through public commands. The full network sequence repeats the same recipe from the child context, so all three Branches are independently operable and every activation is signed by the controller that owns it.