📖What it means

A block (building block) is a first-class, named cluster within a service — a coherent grouping of the work or processes that make that service up, with its own owner agent and team. A service's blocks are organised into TRACKS (a track is a line of work within a service, CAROL-INI-3188); a block belongs to exactly one parent service. Membership is resolved one of three ways: (1) building_block — the droids explicitly assigned to the block (used by the 12 build-pipeline stages file→…→support, and by the Infrastructure & Backup blocks); (2) process_type — the droids of a given process type OWNED by the parent service's agents (CAROL-INI-3022, Ninad 2026-07-19: one process belongs to exactly ONE service — the fleet a monitoring service observes is its watch-list, never its membership; used by the Process Monitoring blocks: Scheduled & Ongoing, Triggered & On-Demand, Embedded); (3) category — the shared services in a System-Services category. Blocks are registry-driven: a row in the registry blocks (key, name, owner_agent, parent_service, membership_kind, membership_value) renders automatically as a page in Carolopedia and a card in Midas's Services Catalogue, with no per-block code. Distinct from a service (a block is a part of one) and from an agent/droid (a block is a grouping, not an actor).

⚖️What it is NOT

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

🧭The nuance

Carol: the 12 build-pipeline blocks (CAROL-INI-1857, owner Elrond/Merlin/Albus, parent_service initiatives) plus, from CAROL-INI-1879, the Process Monitoring blocks (owner Hermione: mon_scheduled, mon_triggered, mon_embedded — by process type) and the Infrastructure & Backup blocks (owner Hagrid: infra_backups, infra_cleanup, infra_runtime). Block identity and team live in the registry; shared machinery is the data layer.

🗣️Also called

🔗Related ideas