Skip to content
BMO

Differentiated local body

Every BMO instance needs a single, clear answer to four questions: what kind of actor is this, what state is it in, what is it allowed to do, and why do transitions matter? BMO keeps these answers in one composable read loop rather than scattering them across configured kinds, running workers, and substrate rows. Internally this capability is called the differentiated local body (DLB).

Operator-visible surfaces

Section titled “Operator-visible surfaces”
  • Lifecycle inspector — TUI command lifecycle_inspector (aliases lifecycle, dlb-lifecycle) or the get_lifecycle_inspector tool: a read-only composed view of class, lifecycle, and related advisory fields. Payloads are versioned; treat fields as evolving with the product.
  • Autonomic posture — Explore vs consolidate precedence where posture is wired. See Adaptive Orchestration.
  • Workspace drill-ins — Spatial / trail context complements DLB but does not replace class/state/authority; see Workspace trail and Workflow map.

Fleet and external metrics

Section titled “Fleet and external metrics”

Cross-session push health signals are opt-in and scoped to individual instances — they do not aggregate into fleet-wide shared metabolism. Read Fleet and external metrics before product copy or integrations that mention fleet-scale inputs.

Optional supporting capabilities

Section titled “Optional supporting capabilities”

Beyond the foundational contract, BMO may expose optional mechanisms (for example signed transfer bundles, arena-linked promotion flows, inspector advisory fields, or habitability-style aggregates). What is on by default and what is experimental can vary by configuration and build; prefer the inspector and Configuration over memorizing milestone IDs.

For contributors: See the differentiated local body maintainer topic and the lifecycle inspector maintainer topic.

Where to go deeper

Section titled “Where to go deeper”

Use this guide as the field orientation for DLB-shaped behavior: what to inspect, which surfaces matter, and where the boundaries are. For day-to-day use, start with the lifecycle inspector and configuration reference. For implementation sequencing and edge-case matrices, use the contributor references in the maintainer reference profile.