📖What it means

A track is a coherent line of work inside a service, with its own owning agent — the layer between a service and its blocks. The full hierarchy is Department -> Service -> Track -> Block -> Droid: a service is divided into one or more tracks, and each track groups the blocks that pursue the same KIND of goal. Where a block is a single cluster of work, a track groups several blocks under one lead, so one service can run distinct kinds of work side by side (e.g. technical delivery and creative storytelling) without conflating them. A track has one owning agent (accountable for the whole line of work); the blocks inside keep their own block owners who do the work (owner-as-accountable, not owner-as-doer). Tracks are registry-driven: a row in the registry service_tracks (key, service, name, owner_agent, description) plus blocks.track render automatically as grouped sections in Carolopedia and Midas's Services Catalogue. Distinct from a block (a track contains blocks) and unrelated to the roadmap 'track' (tech/business/legal) field.

⚖️What it is NOT

The neighbours this word is most often confused with, and the line between them.

🧭The nuance

Carol (CAROL-INI-3188; split by CAROL-INI-3277): the initiatives service runs three lane-aligned technical tracks — Planner (owner Merlin, the autonomous build-pipeline blocks, planner daily budget), Orion Bypass CLI (owner Orion, the operator lane, budget-exempt) and Albus Bypass (owner Albus, the abandoned-work rescue lane, albus daily budget) — plus a Creative track (owner Scriber, the storytelling blocks); every other service runs a single Core track owned by its service owner. See the Carolopedia guide /wiki/guide/tracks.

🗣️Also called

🔗Related ideas