# incidents (/product/modules/incidents)



An **incident** is anything a human must look at before the system can be trusted: a check-in that did not match its shift, a feed that missed its expected arrival, an import that rejected rows, a survey that overran its time limit. One word across every producer and every surface.

## Owns

`incidents`: the module and kind that raised it, a severity, the record it cites, the node and person it concerns, a payload, and the lifecycle `open → assigned → resolved → verified`.

It is core because every solution module raises incidents; an opt-in ledger would let a producer write into a table no tenant could see. An in-database producer raises one through a function no client can call, so an incident cannot be forged.

## The lifecycle

Assigning, resolving and verifying each move the lifecycle in order, within the caller's territory, stamping who and when. The person who resolved an incident cannot verify it.

## Routes

`/incidents`: the queue, filtered to the caller's territory.

## Settings scope

`incidents`.

## Permissions

`incidents.read` and `incidents.manage`.

## Switched off

Never. Every project links it at provisioning.