> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lmrp.uk/llms.txt
> Use this file to discover all available pages before exploring further.

# CAD and Control

> The two sides of dispatch in Argus: Control, which runs incidents, and the MDT, which belongs to each crew.

Computer-aided dispatch in Argus has two audiences, and the API is split the same way.

| | Control | MDT |
| - | - | - |
| Who | Dispatchers | The people crewing a unit |
| Paths | `/api/cad/incidents`, `/units`, `/calls`, `/events` | `/api/cad/me/unit` and `/api/cad/me/units` |
| Sees | Every incident, unit and call | Their own unit and the incident it is assigned to |
| Permission | `cad.view`, plus one per kind of change | `cad.unit.self` |

## What Control does

Control owns the operational picture.

* **Calls** come in and are recorded by hand. A call is converted into a new incident, attached to an existing one, or resolved with no incident.
* **Incidents** are created, edited, closed and reopened.
* **Units** are dispatched to incidents and released from them.
* Control can also create and edit units, set any unit's status, and change its crew.

Every Control endpoint requires `cad.view`. Each kind of change needs a second permission:

| Permission | Allows |
| - | - |
| `cad.incidents.create` | Creating incidents, and converting calls into them |
| `cad.incidents.manage` | Editing, closing and reopening incidents |
| `cad.dispatch` | Assigning units to incidents and releasing them |
| `cad.units.manage` | Creating and editing units, changing crew, setting status, listing eligible crew |
| `cad.calls.manage` | Recording, attaching, converting and resolving calls |

## What a crew does

A crew member manages their own presence, and nothing else.

* **Book on** to start a unit, or **join** one that is already on duty.
* **Change status** within what the unit's situation allows.
* **Book off** to leave.
* Read their **current unit**, which includes the incident it has been sent to.

A crew cannot see other incidents, cannot assign itself to one, and cannot clear itself from one. Those are Control's decisions. See [Units and crew](/concepts/units-and-crew).

## How a dispatch reaches a crew

There is no push channel. A dispatch is a change of state that both sides read.

<Steps>
  <Step title="Control assigns">
    `POST /api/cad/incidents/{id}/assign` with the unit's ID and version. The unit becomes `ASSIGNED`.
  </Step>

  <Step title="The crew sees it">
    The crew's client polls `GET /api/cad/me/unit`. The unit now has `status: "ASSIGNED"` and `incident` filled in.
  </Step>

  <Step title="The crew responds">
    `POST /api/cad/me/unit/status` with `EN_ROUTE`, then `ON_SCENE`.
  </Step>

  <Step title="Control releases">
    `POST /api/cad/incidents/{id}/remove`, or the incident is closed. The unit returns to `AVAILABLE`.
  </Step>
</Steps>

Clients poll. The web application refreshes Control every ten seconds and the MDT every five.

## History

Every CAD change writes an event to an append-only history, together with an audit entry, in the same transaction as the change. `GET /api/cad/events` reads it, for one incident, one unit, or everything. Events are immutable: the database rejects updates and deletes.

Nothing in CAD is deleted. Incidents are closed, units go off duty, and crew memberships end.

## What CAD does not do yet

* It does not ingest calls from ER:LC. Calls are typed in.
* It has no map, locations are free text, and it does not suggest the nearest unit.
* It does not link incidents to PNC people or vehicles.

These are listed, with everything else that is missing, under [API status](/api-status).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.