Skip to content
Syndik8

Tacho-continuity conflict

A tacho-continuity conflict is a disagreement between two consecutive flights on the same asset: the start meter on the later flight does not equal the end meter on the earlier one. Every leg of a booking is checked: the first against the flight before the booking, each later leg against the leg before it, and the very first flight on an aircraft against its opening reading when one is set. A start above that reading and a start below it are both conflicts. 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.

An admin correction can raise the aircraft’s opening reading above earlier flight logs. At a booking junction, the expected Start is the higher of that applicable opening reading and the previous genuine flight’s End. That jump needs no invented flights to bridge it; later legs within the booking still follow the previous leg’s End.

How a conflict is resolved

Section titled “How a conflict is resolved”

The pilot and every admin are told by one Flight logs don’t follow on alert per booking. A mismatch between legs of the same booking is reported as soon as it is logged. A mismatch with an earlier booking waits until ten minutes have passed with no new or changed log on the aircraft, so legs still uploading do not set it off, and is then sent by the next half-hourly sweep (see alert timing). It is critical-tier: always emailed, and it cannot be muted. It is withdrawn once the logs follow on, or when the booking is finalised, cancelled or rejected. A half-hourly sweep, in every syndicate whether or not auto-finalise is on, sends any alert that was missed and keeps the standing ones up to date.

Every finalisation path except an admin’s single-booking finalise runs the same look-back check at a different moment, and none lets a conflict slip through unnoticed:

  • The pilot’s close runs the check when the pilot closes their own booking. A mismatch refuses the close; the sheet tells the pilot to correct the log if it is wrong and close the booking again, and otherwise that an admin will review it and finalise the booking.
  • Auto-finalise runs the check when its sweep reaches a booking the pilot left open, 24 hours after it ends: the booking’s first leg is compared to the previous booking’s last log end, and each later leg to the leg before it. 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 and leaves the booking in the unfinalised queue. The alert has normally been sent already, shortly after the flight was logged.
  • Admin bulk finalise runs the same look-back check in a batch at reconciliation time, on every leg of each booking. A mismatch tags the row with a Meter mismatch badge in the unfinalised queue and excludes it from the Finalise All batch. The admin investigates the flight whose end reading the start disagrees with: the previous booking’s, or an earlier leg of the same booking.

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

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

A departure conflict is the same kind of hold for routes: a booking with a flight that left from somewhere other than where the aircraft last landed. It is held by the same three paths and resolved the same way.

See also

Section titled “See also”