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

# Copilot

> Asking for a classification, a diagnosis or a plan; what leaves your deployment when you do; and how to tell whether the answers are any good.

An assistant you can ask about a work order, an asset, or the plant as a whole — and a record of
every question, every answer, and exactly what was sent.

It is **off** until somebody in your organisation agrees to switch it on. Until then nothing is sent
anywhere.

## Where you use it

There is a **Copilot** tab on every [work order](/work/work-order-detail) and every
[asset](/assets/detail), and that is where it is most useful: the place to ask what is wrong with a
pump is on the pump.

The Copilot screen under Analytics is for the questions that are not about one record, and for
deciding whether to keep the feature at all.

## What you can ask for

| Capability   | What it is for                                                             | Where                    |
| ------------ | -------------------------------------------------------------------------- | ------------------------ |
| **Classify** | Failure mode, cause and priority, proposed from your own lists             | A work order             |
| **Diagnose** | Probable causes ranked by this machine's history, and what would settle it | An asset or a work order |
| **Assist**   | What to check, what to isolate, what to take with you                      | A work order or an asset |
| **Plan**     | What is due, ordered by consequence rather than by date                    | The whole plant          |
| **Analyse**  | What changed in the numbers, and what the rows say about why               | The whole plant          |

Which of these are allowed is set on the **Consent** tab.

## Asking

Pick a capability, type the question, and ask. A counter shows how many questions your organisation
has left today.

The answer comes back through a queue, so there is a gap between asking and being answered — the
screen says so rather than showing a spinner that implies something is happening faster than it is.

A conversation stays on the record it was opened against, so navigating away and coming back does
not lose it.

### Turns that failed or were declined

They appear in the conversation, in place, with the reason. A conversation that quietly dropped the
answers nobody liked would read as a product that works better than it does.

### What was sent

Every question you ask carries a **What was sent** link that opens the record exactly as it stood
when it left. It is one click away on every turn, not buried in a policy document.

### Saying whether it was any good

**Useful**, **Wrong** and **Unsafe** are on every conversation. The last two are the ones worth
reading.

## Suggestions

The copilot proposes; it does not write. A suggestion sits there until somebody decides on it, and
nothing reaches a record on its own.

Each suggestion shows the field, the proposed value, the reasoning, what it rests on, and the
confidence the model gave itself — presented as the model's own number rather than dressed as a
measurement.

Three things you can do with one:

| Choice                                  | What happens                                                |
| --------------------------------------- | ----------------------------------------------------------- |
| **Accept and write it on**              | The judgement is recorded and the record is changed         |
| **Agree, but do not change the record** | The judgement is recorded; the record is untouched          |
| **Reject**                              | Recorded, with your reason — which is the part worth having |

The middle option exists for a real situation: a technician can agree with a diagnosis without being
the person who classifies failures.

Asking and accepting are separate permissions, because sending a record out and writing to one are
different risks. By default technicians may ask and read; supervisors, planners, managers and
administrators may also accept. See [roles](/setup/roles).

The **Waiting** tab on the Copilot screen collects every suggestion across the organisation that
nobody has decided on yet.

## Is it any good

An accept rate per capability, computed over suggestions somebody actually accepted or rejected.

There is no single headline number, on purpose. The capabilities fail differently — a classification
that names the wrong failure mode leaves a bad row in a register; an uninspiring plan costs nothing
— and averaging them produces a figure that is true of no part of the product.

A capability whose suggestions are mostly rejected is flagged. You can switch that one off on the
Consent tab without giving up the others.

## Consent

<Warning>
  Asking the copilot sends the record the question is about — the work order or the asset, its
  recent history, and the lists your organisation has configured — to a model run by Anthropic,
  outside your deployment. Names, e-mail addresses and phone numbers are stripped before it goes.
  The rest is the record.
</Warning>

Turning it on is a decision with a person's name on it: who agreed and when is recorded and stays on
the record even if that person later leaves.

The Consent tab also sets:

* **Which capabilities may be asked for.** Anything not ticked is refused by the server rather than
  merely hidden. Ticking nothing means all five are allowed.
* **How many questions a day**, across the whole organisation.

Switching it off stops it immediately. The record of who agreed stays.

Only somebody who may edit your organisation's configuration can change any of this — the two
administrator roles and Maintenance Manager, by default.


## Related topics

- [Inside a work order](/work/work-order-detail.md)
- [Inside an asset](/assets/detail.md)
- [Role reference](/setup/roles.md)
- [Finding your way around](/get-started/navigating.md)