Organizations

Everything else in these docs covers a single repo talking to git directly. The portal adds an org control plane on top: a curated internal registry, org/team baselines, one fleet board, and generated capabilities. All of it comes back to repos as normal pull requests, never a side channel.

Curation & approval

An org's internal registry holds versioned, immutable pack publishes. A maintainer's publish lands as pending until an admin approves or rejects it. An admin's own publish is auto-approved. A rejected version is burned and never reused. See the registry concept.

Baselines

A baseline is an org- or team-scoped floor: a set of {packId, minVersion} pairs, each one naming the lowest version allowed for a pack. Org and team baselines merge, with the higher minVersion winning. Baselines are flag-only: nothing is blocked or auto-installed. A target below the floor shows as below-min or missing on the fleet board.

Fleet

One board is the single place an org sees compliance across everything it owns: installed pack versions against the effective baseline, enrolled machines, capability freshness, and drift status. A "bump all" action opens preview PRs, reviewed and merged like any other PR.

Capabilities

A pack can declare repo-scoped capabilities: system-map, wiki, graph, design, memory, tasks. Three of them are computed centrally by the portal and delivered folded into the repo's rollout PR, never generated ad hoc on the repo's machine. See the pack format reference.

The portal is a hosted product. See baselane.sh for access.

Example flow