Tacho-continuity conflict

What it is

A tacho-continuity conflict means a flight’s start meter reading does not match the expected reading. A booking starts at the higher of the previous genuine flight’s end meter reading and the aircraft’s applicable opening reading. Every later leg is checked against the previous leg’s end. A first flight with no earlier eligible booking is checked against the opening reading when one is set.

Without an admin baseline correction or an intervening flight, consecutive readings should be identical. When they are not, something is off: a missed log, a typo, an undocumented ground run, or a genuine data error. Syndik8 flags the booking rather than guessing.

The term “tacho” here is a general stand-in; the same check applies to whichever engine meter the asset is configured to read (Hobbs, tacho, or another label set on the asset billing config). Backward comparisons name the configured meter, such as “Starts at 1234.5 h on the Hobbs; the previous end or opening reading is 1234.2 h.” The default label is Tacho.

Who can use it

Admin: see the flag on the unfinalised bookings queue and decide what to do about it.
Treasurer (admin): same.
Member: sees the booking as “not yet finalised”. A member who tries to close the booking is told their start reading doesn’t follow the previous flight’s end. If their own log is wrong, they can correct it while the booking is still open and close the booking again. Otherwise an admin will review it and finalise the booking.

Where to find it

On the Unfinalised bookings queue at /syndicates/:syndicateId/unfinalised-bookings, a booking with a meter conflict shows Meter mismatch, or counts it in +N more when a higher-priority finding is present. Opening the booking lists the recorded values and links to the related booking.

Fields / options

The queue shows Meter mismatch when readings disagree beyond 0.01. Open the booking for Needs attention, which lists every established finding and links to the related booking. The reading and route fields show factual hints when editing. A disagreement does not establish which log is wrong.

Behaviour rules

A booking starts at the higher of the previous genuine flight’s end and the applicable opening reading. An admin correction that raises the opening reading establishes a new minimum; there is no need to log flights to bridge that jump. Once a logged end exceeds the opening reading, that end is used. Later legs within the booking start where the previous genuine leg ended. Repeated logs are filtered consistently; ground runs still contribute meter movement.
Empty intervening bookings are passed over when the current start matches the higher of the last genuine end and applicable opening reading. A lower start is Meter mismatch, even across an empty booking. A higher start is Missing previous log if an unlogged booking intervenes, otherwise Meter mismatch. Internal leg gaps and overlaps remain mismatches.
For example, two flights on 3 October end at 100 at EGMC, 7 October has no logs, and 10 October starts at 100 at EGMC. The 10 October booking can finalise; 7 October keeps its own No flight logged review. A 10 October start of 101 waits for the missing log; 99 is a mismatch. A start of 101 with no empty booking between is also a mismatch.
If the 7 October flight arrives later ending at 101, the changed 7 October booking receives the diagnosis and a link to 10 October: “Ends at 101; the later booking starts at 100.” The check looks past empty bookings to the next genuine logged booking, including a finalised one. Correcting an existing earlier log can produce the same finding. Route disagreements follow the same rule.
The accepted later booking is never reopened, rewritten or rebilled by this diagnosis. Correct either log only after checking the evidence. Financial corrections remain separate deliberate admin actions.
New between-booking alerts wait for ten minutes without a relevant server receipt or change on the aircraft. The half-hourly sweep therefore normally delivers them within 10–40 minutes. Standing alerts refresh or withdraw immediately; internal-leg and opening-reading conflicts retain their immediate checks. Relevant reading, route and date changes and deletions refresh the diagnosis. Device timestamps cannot shorten the quiet period.
There is one alert per booking while it stands, addressed to the pilot and active admins. A late change does not send a second pair alert on the unchanged later booking. Deleting a notification does not replay it.
An admin can finalise an open booking individually after review. The accepted facts are remembered, so unchanged warnings do not return. For a completed booking, Mark reviewed acknowledges exactly the displayed findings without changing logs or charges. A further relevant change can require review again.
Bulk finalisation, automatic finalisation and the pilot’s close hold unresolved meter or route conflicts. The ordinary single-admin finalisation override remains available. A failed check is shown as Check failed, not as a passed check. Ambiguous earlier repeats and missing baseline readings have separate factual labels.

Why Syndik8 checks this

A disagreement can come from either reading, a ground run, or flying that has not yet been logged. The linked facts help the pilot and admin compare the records before finalising. They are not a claim that the current field is wrong.