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.

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. Clicking an operator folds its branch into the circle, so a large tree can be collapsed down to the handful of members worth looking at; clicking a member jumps straight to that host or service's own detail view. 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.