One flight, four links: entry, counter, due date, status

The chain

One flight in four links

The same flight seen from four places: 0:54 of block time, 6 landings, no defects. The “before” and “after” values sit next to each other, so you can see exactly what one signature changes.

Step by step

What each link actually does

The same four links again, slower: where every number comes from and what closes it.

1. 01

   Techlog entry

   Pilot · tablet in the hangar

   The pilot closes the flight next to the aircraft: times, counter readings taken from the instrument, landings and either NIL or a defect. The signature is a password confirmation, a cryptographic digest of the entry and server time – never the device clock.

   Until it is signed, the entry is a draft: it sits on the device, it can be corrected and it moves no counter. Signing does three things at once – it verifies the password server-side, computes a SHA-256 digest over a closed list of entry fields and stamps server time. The tablet clock is irrelevant, because a device in a hangar can be set to anything. Continuity is checked too: the “before” reading must match the last posted state to the minute, so a flight nobody entered surfaces immediately rather than at the next inspection.

   Entry fields, the signature, immutability, reversals and work with no signal have a page of their own: Electronic techlog

2. 02

   Counters

   Database · append-only record

   The signature posts the increment on the aircraft counters and on those of every installed component. A counter is a stream you append to – never a number you overwrite.

   Block and tach run separately, because they measure different things: time from moving off to coming to rest, and running time of the powerplant. Nobody keeps a component counter by hand – it is its time at installation plus the airframe increment since. Hours are held as whole minutes; decimal hours are the simplest way to be a quarter of an hour short after a year. A mistake cannot be “fixed”: the state is corrected by a compensating entry, and both records stay in the register together with the reason.

3. 03

   Due dates

   Tracking engine · no drift

   From the new counter state every limit is recomputed at once – hours, calendar and cycles, each with its own tolerance. The forecast says when the aircraft will stop at the current rate of flying.

   The recomputation happens in the same transaction as the signature, so there is no “it will recompute overnight” state. The calendar axis did not move on this flight: the ARC is valid until a fixed date and flight time changes nothing there – it is the only axis that keeps running while the aircraft sits in the hangar. The forecast takes the utilisation rate from two windows, 30 and 90 days, and uses the more conservative one, because it must fall earlier than reality, never later.

   Limit types, tolerances, statuses, forecasting and components have a page of their own: Maintenance tracking

4. 04

   Airworthiness

   Pilot · before the next flight

   Before anyone takes off, the same chain answers one question: can this aircraft and this pilot fly today? The status is visible before the flight, not after the fact.

   The pre-flight screen reads exactly the same data as the CAMO due list – there is no separate “pilot view” with its own copy of the truth. There are five statuses and they mean the same thing everywhere in the system: serviceable, due soon, in tolerance, exceeded, no data. An exceeded task means the aircraft does not fly until it is done, and an item without history is shown as “no data” rather than as a green tick.

Rules

Four things that hold this chain together

Without them it is a pretty diagram. Every one of these rules is enforced in code or in the database, not written down in a user manual.

• No retyping

  Flight time is entered once and the same number travels on: to the aircraft counters, to the component counters, to the margin before an inspection and to the pilot screen. There is no second register where it could look different, so there is nothing to reconcile.

• A signature closes the entry

  Once signed, an entry cannot be changed or deleted – the lock is in the database, not in the interface. A mistake is corrected by a reversal with a mandatory reason, which posts compensating increments, after which the correct entry is made. Both stay in the register.

• No signal, no problem

  The entry is created on the device and waits in a queue until connectivity returns; it is sent on its own, in the order it was saved. The server never quietly overwrites the pilot entry – a conflict is shown as “your entry / server state” and requires a new signature.

• Tolerance without drift

  Work done inside the tolerance window does not push the next due point. The anchor is the earlier of two values: the actual compliance or the planned due point – without that rule the “100 h” inspection would really happen every 115 hours after a few years.

FAQ

Frequently asked questions