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

Owner and 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 discrepancy. 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.
The check fires only on assets whose billing basis reads the engine meter (engine_meter or both). On clock-time-only assets, there is no meter to compare.
A booking with at least one failing log is marked as a discrepancy 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, a database trigger fires the tacho_continuity_detected notification to the submitter and to every active admin in the syndicate. That notification is critical-tier — push and email are forced on regardless of the recipient’s notification preferences, and the toggle on the preferences screen is locked.
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 runner tick auto-finalises the booking without admin intervention. The runner is scheduled by pg_cron and runs 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.