Evidence & compliance
Elevator Inspection Records: Tracking Deficiencies Across Cars, Controllers, and Years
Elevator inspection produces a long-running record against equipment that outlives contracts, ownership, and software. Organising it around jobs loses the part that matters.
An elevator is inspected for decades. It outlasts the maintenance contractor, the building owner, the inspection firm's software, and usually the inspector. What accumulates over that time — the deficiencies, the corrections, the tests, the certificate history — is the actual record of whether the equipment is safe.
Most inspection software is not designed to hold that. It is designed to produce a report for a visit and close the file.
The equipment hierarchy is the hard part
Elevator inspection does not fit a flat asset list. A site contains multiple conveyances; each conveyance has a car, a controller, a machine, a hoistway, and door equipment; deficiencies attach at different levels of that structure.
A controller fault belongs to the controller, not to the building. A door restrictor deficiency belongs to that car. A machine room housekeeping issue belongs to the machine room, which may serve several units. Flattening this loses the ability to answer basic questions.
| Question | Requires | Flat-list result |
|---|---|---|
| Which car had the restrictor deficiency? | Deficiency attached to the car | Recorded in free text, unsearchable |
| Has this controller failed the same test before? | History at controller level | Requires reading prior reports |
| What is outstanding across this site? | Rollup from components to site | Assembled manually |
| Which units are due within thirty days? | Due dates per conveyance | A spreadsheet, if anyone maintains it |
Statutory dates are properties of the equipment
Certificate expiry, annual inspection, and periodic full-load testing are all obligations attached to the conveyance and derived from rules — frequently with no grace period, and with consequences that include removal from service.
The consequential detail is what the date is anchored to. Some intervals run from the last completed inspection; others run from a fixed certificate expiry regardless of when the last inspection happened. A system that assumes every recurrence is "twelve months from last completion" will produce wrong dates for the second category — and the error is invisible until something has expired.
Test results are data, not prose
Elevator inspection generates measurements: governor trip speed, buffer condition, safety operation, leveling accuracy, door force and timing. Recording these as sentences in a report body makes them impossible to compare across years.
Captured as structured values with units, the same data becomes a trend: a governor trip speed drifting across three inspections is a finding that no single inspection could produce. This is the argument for capturing measurements as measurements at the point of test.
Reproducibility across code editions
Elevator safety codes are revised. An inspection performed in 2024 was performed under the requirements in force in 2024, and a report reproduced later must reflect that — not the current edition.
This means the version of the protocol in force must be recorded with the job and pinned, so that regenerating or reviewing an old report shows what was actually required at the time. Systems that always apply the current checklist quietly rewrite history, which is a problem in exactly the situations where old records get examined.
Recurring deficiencies and the safety record
A deficiency corrected between inspections is routine maintenance. The same deficiency recorded across consecutive inspections is a pattern — and in conveyance work, where consequences of failure are severe, that pattern is significant.
Surfacing recurrence during the inspection, at the specific test item, does two things: it prompts the inspector to consider whether the correction was inadequate, and it produces a defensible record that the condition was raised each time.
Certificates as an output type
Elevator inspection often produces a certificate rather than a narrative report — a determination, a validity period, an identifying number, and sometimes a filing with the authority. That is a genuinely different document shape from a condition report, and software that assumes narrative output will make it awkward.
Where the determination is computed from the findings — any deficiency of a defined severity produces a fail — that logic belongs in controlled configuration rather than inspector judgement, so it applies identically every time.
What to require from a system
- Nested assets: site, conveyance, and component, with findings at the appropriate level
- Due dates derived per rule, with correct anchoring for both completion-based and expiry-based intervals
- Structured measurement capture with units and expected ranges
- The protocol version pinned to each job for reproducibility
- Prior open deficiencies surfaced at the relevant test item during inspection
- Certificate output as a first-class document type, not a narrative report with the sections removed
These equipment-record requirements should be tested alongside the wider criteria for choosing inspection report software.
Frequently asked questions
How should elevator inspection records be organised?
Around the equipment, in a hierarchy: site, conveyance, and component. Deficiencies attach at the level they belong to — a controller fault to the controller, a restrictor issue to the specific car — so history and rollups remain accurate over years.
Why do due dates need different anchoring rules?
Some intervals run from the last completed inspection; others run from a fixed certificate expiry regardless of when the inspection occurred. A system that assumes all recurrence is twelve months from last completion will silently produce wrong dates for the second type.
Should test measurements be recorded as text?
No. Values like governor trip speed or door timing should be captured as structured measurements with units so they can be compared across inspections. A drift across three years is a finding that no single inspection reveals.
How do you reproduce a report under an older code edition?
The protocol version in force at the time must be recorded with the job and pinned, so regenerating the report reflects what was actually required then rather than the current edition.
Is a certificate different from an inspection report?
Structurally, yes. A certificate carries a determination, validity period, and identifying details, and is often filed with an authority. Software that only produces narrative reports tends to handle it poorly.