A host or a service reports what a machine is doing. A business process reports what that means: "checkout" is not a check, it is a rule over the checks that keep checkout up. jaque computes it the same way it computes everything else -- a pure rule evaluated against current hard state, with no separate runtime and no separate notification path.

1. Declaring one

A business process lives in a processes block, keyed by name the same way a sink or a datasource is. Each one has an impact score and a rule: a structured tree of and/or/not/quorum nodes over references to hosts, services, label selectors, and other business processes.

processes: {
	frontend: {
		impact: 3
		rule: {
			op:   "quorum"
			need: 2
			warn: 1
			of: [
				{select: "tier=web"},
				{ref: "db"},
			]
		}
	}
	checkout: {
		impact:       5
		notification: "page"
		rule: {
			op: "and"
			of: [
				{process: "frontend"},
				{ref: "db/replica"},
			]
		}
	}
}

A rule leaf is one of:

• ref: "host" or ref: "host/service" -- names one monitored object.
• process: "name" -- names another business process, letting one process depend on another.
• select: "label=value" -- expands to every object a label selector matches, resolved once when the config loads. A selector matching nothing fails the load rather than silently evaluating an empty group.

A rule branch is and, or, not or quorum, each taking a list of child rules (not takes exactly one).

2. Semantics

Only hard states feed a business process. A member currently in a soft state -- still retrying, not yet confirmed -- contributes its last hard status rather than the unconfirmed one, the same way a flapping check's last confirmed state is what a dependency check reasons about.

Statuses have a severity order, from least to most severe: OK, WARNING, UNKNOWN, CRITICAL.

• and takes the worst status among its children.
• or takes the best status among its children.
• not inverts: OK when its child has a problem, CRITICAL otherwise.
• quorum counts how many children are OK. At need or more, the result is OK; below need but at or above the optional warn threshold, the result is WARNING; otherwise CRITICAL. warn must stay below need.

A business process's own status is itself a hard status, so one process can feed into another's rule (process: "frontend" above), and a chain of processes settles in one evaluation pass.

A process's status is recomputed whenever a member it depends on changes state, whenever the configuration is reloaded, and whenever an engine starts up or takes over responsibility for the process. On a brand-new installation a process stays PENDING until the first member it depends on has reported.

3. Impact and notifications

impact is a score from 0 to 5, carried alongside the process's status for anyone triaging which of several simultaneous problems to look at first. It is descriptive only -- jaque does not change scheduling or escalation based on it.

A business process notifies through the same notification policy field a host or a service uses, resolved against the same notifications block. There is no separate business-process notification path: escalation levels, thresholds and re-notify intervals all apply exactly as they do for a host or a service.

4. Root cause: the trace view

A business process's status alone answers "is checkout down". The trace view answers "why": it renders the evaluated rule tree, every node annotated with the status it resolved to, down to the individual host and service references at the leaves.

The trace offers two ways to read that tree, switchable at any time. The diagram lays the tree out top to bottom, root at the top: each operator is a circle carrying its symbol (and, or, not, or a need/count ratio for quorum), colored by the status it resolved to, with a line down to each child. A node's shape says what kind of thing it is: a circle is a condition (and, or, not, quorum), a sharp-cornered rectangle is a host, a rounded rectangle is a service, and a diamond is a nested business process. A nested process arrives fully expanded, its own complete tree drawn inside the parent's diagram, recursively, so a chain of processes is visible in one diagram rather than one hop at a time. Clicking an operator circle folds its branch down to just the circle; clicking a folded circle unfolds it again, so a large tree can be collapsed to the handful of members worth looking at. A process diamond folds and unfolds the same way, collapsing its whole nested tree behind the diamond. Shapes do not navigate anywhere on click: every host or service node instead carries a small button with an outward arrow that opens that host or service's own detail view. Any node can be dragged to a new position to untangle a crowded layout, and dragging never triggers anything else. A reset control snaps the tree back to its computed layout when a rearranged view stops being useful. The table lists the same tree flattened row by row, indented by depth, for scanning or copying as text. Reading top to bottom from the first non-OK node down to its non-OK children, in either view, is the fastest path to the member actually causing the problem, rather than the process wrapping it.