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

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.