> ## 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.
# Core concepts
> The vocabulary the product is built on: assets, requests, work orders, plans, requirements, entitlements, readiness, sites and scope.
Everything in the system hangs off a small number of ideas. Learn these and the screens explain
themselves.
## The chain
```text theme={null}
Asset
→ something goes wrong, or a plan comes due
→ Work request (somebody reports it)
→ Work order (the job)
→ Requirements (parts, tools, skills, vendors)
→ Entitlement (who pays)
→ Readiness (can it actually be done)
→ Execution (at the machine)
→ Failure, downtime, cost
→ Reliability (what the machine is teaching you)
→ Root cause (why it keeps happening)
→ Actions (and whether they worked)
```
## The records
A physical thing you maintain — a pump, a compressor, a generator. Assets form a **hierarchy**:
a bearing belongs to a pump, which sits on a production line, in a building, at a site. Work,
cost, downtime and failures all roll up that tree.
An asset carries meters, cover, a criticality, a health score and a full history.
See [the asset register](/assets/register).
Somebody reporting that something needs attention. A request is *not* a job — it is a claim
that there might be one. Triage decides: convert it to a work order, or reject it.
Requests keep the reporter's own words, which is why they exist as a separate record rather than
as a draft job. See [work requests](/work/requests).
The job itself, and the most important record in the product. It carries the asset, the type
(preventive, corrective, breakdown, inspection), the priority and its service level, who it is
assigned to, what it needs, what it cost, and every state change it has been through.
See [inside a work order](/work/work-order-detail).
A rule that raises work orders on its own. A plan names the assets it covers and one or more
**triggers** — a calendar interval, a meter threshold, an event, or a measured condition —
combined with ANY or ALL.
A plan can also raise an **inspection round** alongside the work order.
See [the plan builder](/maintenance/plan-builder).
What a job needs before it can be done: a **part**, a **tool**, a **skill**, or a **vendor**.
Requirements come from the maintenance plan, or are added to the job directly.
All four are one thing to the system, which is why the readiness check can answer "can this be
done" in a single question rather than four.
Whether a job can actually be executed right now. Readiness reads the requirements and reports
what is missing — a part not in stock, a tool out on another job or overdue for calibration, a
skill or certification nobody available holds.
Readiness is a fact about the job, not a status. A job can be Assigned and not ready.
Who pays. When work is raised against an asset, the system evaluates the contracts and
warranties covering it and records the decision — covered or not, by which agreement, with the
evidence it used.
The decision is recorded rather than recomputed, so a repair billed internally on a machine the
manufacturer would have covered is visible instead of silent.
See [entitlements and claims](/commercial/entitlements).
What actually broke, recorded against the asset. Failures drive downtime, MTBF and the bad-actor
ranking on [Reliability](/assets/reliability). A failure is raised from the job that fixed it, or
from a failed inspection check.
Classifying one means saying what kind of failure it was, what caused it, and by what mechanism
— three separate lists, because collapsing them tells you nothing about what to change.
Why the same thing keeps happening. An investigation is opened against an asset, works down to
findings you can evidence, and concludes on a root cause — which it will not do until one is
marked.
What comes out of it is **actions**, corrective or preventive, each followed until somebody has
confirmed it was done and then reviewed whether the problem actually stopped.
See [root cause](/assets/root-cause).
## Sites and scope
An organisation has **sites** — plants, depots, buildings. Inside a site is a **location tree**:
building, floor, line, room. Assets live at locations.
Two separate things control what you can see:
| Control | What it does |
| -------------------------- | ------------------------------------------------------------------ |
| **Site switcher** (header) | A view filter. Narrows the screens you are looking at to one site. |
| **Site access** (per user) | A permission. Decides which sites you may reach at all. |
A user with **no** site grants can reach **every** site — no grants means unrestricted. Adding
somebody's first site therefore narrows them from everything to one, and removing their last
widens them back to everything. See [people and access](/setup/access).
## Statuses are yours, not ours
Every lifecycle in the product — work orders, requests, assets, vendors — is a **state model** your
organisation owns. You can rename states, add them, and change which moves are allowed.
What a status *means* is carried by flags rather than by its name: whether it counts as open,
whether it stops the service-level clock, whether parts may be consumed against it, whether a
technician may still edit the job. That is why renaming `WAITING_PARTS` to "Awaiting spares"
changes the label everywhere and breaks nothing.
See [statuses and transitions](/config/statuses).
## Custom fields
What the product tracks is not all your plant tracks. Custom fields add your own — a batch number, a
torque figure, a compliance flag — to any record type, in fifteen types from a line of text to a
multi-select list.
A field's **type is chosen once**, at creation. Changing it later would not convert the answers
already stored, so the product does not offer it. See [custom fields](/config/custom-fields).
## Working offline
Technicians use a separate [field app](/field/overview) built for a plant room with no signal. It
holds its own encrypted copy of the work assigned to the device, applies changes immediately, and
queues them for the server. When two people change the same job, the collision is surfaced for a
person to decide rather than silently resolved. See [offline and sync](/field/offline-and-sync).
## Related topics
- [Your first hour](/quickstart.md)