Tacho-continuity conflict

What it is

A tacho-continuity conflict is a disagreement between two consecutive usage logs on the same asset: one log’s start meter reading does not equal the end meter reading of the log immediately before it.

If nobody has flown the aircraft 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. 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).

Who can use it

Admin: see the flag on the unfinalised bookings queue and decide what to do about it.
Treasurer (admin): same.
Member: does not see this explicitly; they just see the booking as “not yet finalised”.

Where to find it

On the Unfinalised bookings queue at /syndicates/:syndicateId/unfinalised-bookings, a booking with a tacho-continuity conflict is tagged as a Junction conflict. Opening the booking shows the two logs that disagree.

Fields / options

There are no fields to edit here. The check is computed from the usage-log history; it is not stored on the booking.

Behaviour rules

The check compares the start meter reading of the current log with the end meter reading of the preceding log on the same asset. The preceding log is the most recent log older than the current one.
A logged ground run or ferry flight counts as the preceding log. These are recorded as usage logs against a maintenance booking, and they move the meter, so they sit in the continuity chain like any other flight. The next flight’s start must line up with the ground run or ferry’s end reading, not with the last member flight before it. (The ferry itself is still excluded from member billing; continuity and billing are separate concerns.)
A booking with no usage logged is transparent when the meter is continuous. A maintenance grounding where nothing was flown or run (a routine annual or 50-hour check), or a personal booking that was never flown (a no-show that wasn’t cancelled), has no reading of its own. If the next flight’s start still matches the last real reading, nothing moved the tacho across the gap, so the empty booking is treated as a genuine no-show and the next flight finalises normally. Only if the meter has jumped across the gap (real flying went unlogged) does the next flight wait. This stops a scheduled grounding or a forgotten booking from silently holding up finalisation while everyone waits for a log that is never coming.
The check fires only on assets that capture the engine meter. On assets that don’t capture it, there is no meter to compare.
A booking with at least one failing log is marked as a Junction conflict and is skipped by auto-finalisation. It stays in the unfinalised queue until an admin resolves it.
The detection runs server-side. When the conflict is detected, the server sends a Tacho discrepancy notification to the submitter and to every active admin in the syndicate. That notification is critical-tier: at least one channel (push or email) is enforced on; the recipient can choose which channels to keep active but cannot silence the notification entirely.
An hourly retry runner re-evaluates queued conflicts. Once the underlying data is corrected (an earlier log is edited to truth, or an out-of-order arrival eventually lands), the next retry auto-finalises the booking without admin intervention. The retry runs on a regular schedule against every syndicate with auto-finalise enabled.
Manual finalisation from the booking detail screen always succeeds; the admin has already decided. The continuity check does not block the manual flow.
Resolving the underlying data (usually by editing or adding a usage log) is done outside the discrepancy screen, using the normal usage-log editor. Once the logs line up, the hourly runner will finalise the booking on the next tick, or the admin can finalise it manually at any time.
The check is scoped to one asset at a time. A missing log on aircraft A never blocks a booking on aircraft B.

Why Syndik8 checks this

Meter continuity is the cheapest possible integrity check on flight-time data. If the meter read at the end of flight 1 does not equal the meter read at the start of flight 2, then either flight 1 under-reported, flight 2 over-reported, or an undocumented ground run or ferry hop happened in between. Any of those is worth an admin’s attention before a charge is posted.

Previous-tacho pre-fill prevents most of these conflicts at the point of data entry: the start meter is pre-populated with the prior log’s end meter, so the member only has to type an end value.