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

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

Asset

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.

Work request

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 order

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.

Maintenance plan

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.

Requirement

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.

Readiness

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.

Entitlement

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.

Failure

What actually broke, recorded against the asset. Failures drive downtime, MTBF and the bad-actor ranking on 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.

Investigation

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.

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.

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.

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.

Working offline

Technicians use a separate field app 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.