> Section: [2. The model](https://jaque.sh/docs/concepts/architecture.md)
> Next: checks/native-checks
> Index: https://jaque.sh/llms.txt


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.

```cue
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.