Skip to content

Tacho-continuity conflict

A tacho-continuity conflict is a disagreement between two consecutive usage logs on the same asset: the start meter on the later log does not equal the end meter on the earlier log. If nobody flew the asset in between, those two numbers should be identical; when they are not, something is off (a missed log, a typo, an undocumented ground run, or a genuine data error).

The word “tacho” here is generic. The check uses whichever engine meter the asset is configured with. It only fires on assets that capture the engine meter.

The two finalisation paths handle a conflict differently, but neither lets it slip through unnoticed:

  • Auto-finalise on submit uses a look-back check: when a member submits a usage log, the booking’s start meter is compared to the previous booking’s last log end. The previous booking is the most recent one that recorded a reading — a member flight, or a maintenance ground run or ferry flight that moved the meter. A grounding with no usage logged is skipped, so the check looks through it to the flight before. A mismatch skips finalisation, leaves the booking in the unfinalised queue, and fires a meter-continuity notification to the submitter and all syndicate admins. The notification is critical-tier, its delivery toggle is locked on.
  • Admin bulk finalise uses a look-ahead check: at reconciliation time, each booking’s end meter is compared to the next booking’s first log start. A mismatch tags the row with a “Junction conflict” badge in the unfinalised queue and excludes it from the Finalise All batch. The admin investigates with the full chronological context.

Either way, a conflict surfaces in the unfinalised queue with an explicit reason badge, and an admin’s normal recovery move is to edit the historical log to truth + post an adjustment for the financial difference (see correct a finalised booking).

Manual finalisation from the booking detail screen always still works; the admin has already decided.