📖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 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; (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).

📖Easily confused with

[{"term": "Track", "distinction": "A block is a named cluster of the processes inside a service; a track is a line of work inside a service that carries a budget."}, {"term": "Department", "distinction": "A block groups WORK inside one service; a department groups AGENTS across the org."}]

📖Nuance

Carol: the 12 build-pipeline blocks plus, from, 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

- building block
- service block

📖Filed under

Category: entity.

Service: Governance.