The techlog entry: what it has to contain

The technical log is often treated as an attendance sheet: write the hours, sign, close. In reality it is the only document where the technical state of the aircraft meets the fact that a flight took place — and the only source from which the rest of the continuing airworthiness system draws its numbers. If the entry is incomplete, so is the due list, so is the AD status, and so is the decision to release the aircraft for the next flight.

This is one entry taken apart: what has to be in it, why that and not something else, and what the typical failure looks like when a field is missing.

Where the scope of an entry comes from

ML.A.305(b)(1) states that continuing airworthiness records include the aircraft logbook with a record of each flight: time, landings or cycles, counter readings, and the reporting and rectification of defects. That is all it says. The rule does not prescribe a form layout or field names — it prescribes functions the entry has to perform.

There are four:

1. prove the flight happened, and to what extent (accounting for utilisation),
2. advance the counters of the aircraft and its installed components by the correct amount,
3. hand over the technical state to the next crew and to maintenance (defects, observations),
4. name the person responsible for the content of the record.

Every field on the form should map to one of those four. If it does not, it is decoration. If one of the four has no field behind it, the entry is incomplete — however good it looks on paper.

Anatomy of one entry

Group	Fields	Why
Identification	registration, flight date, commander, route	ties the record to an aircraft and a person
Times	block off, block on, flight time	the basis for utilisation and hour limits
Counters	reading before and after the flight, for every counter	drives life limits on airframe and components
Events	landings, cycles, starts	limits counted in cycles, not hours
Consumption	fuel, oil	oil consumption is the earliest engine signal there is
Airworthiness	pre-flight check confirmation	ML.A.301 — a condition for release
Technical state	NIL or at least one defect	handing the aircraft on
Accountability	commander’s signature, time of signature	who owns the content

Three of those groups deserve their own section, because that is where most real-world divergence is born.

Times: block time is not flight time

Block time (chocks off to chocks on) and flight time are two different quantities and both can be the basis for a limit. An entry that records only one of them forces mental arithmetic every time a task is counted on the other basis.

What follows in practice:

• Record clock times, not a difference. Block off 17:40, block on 18:25 can be verified and corrected. A bare 0:45 carries no control information at all.
• A flight across midnight must be handled directly. An entry of 23:50 → 00:20 is valid and should never require a workaround from the pilot.
• The format has to be unambiguous. HH:MM or decimal hours — but never 1.5 next to 1:30 in the same register. The single biggest source of error when transcribing from paper is 1.30, which means one hour eighteen in one row and one hour thirty in the next.

Counters: a reading, not a calculation

This is the most important rule of the whole entry, and the one most often broken: the “counter after flight” field takes what the instrument shows, not what you get by adding flight time to the previous state.

The difference matters. An instrument reading is an independent measurement — compared against block time it exposes a skipped flight, a replaced counter, or an error made by the previous crew. A calculated value exposes nothing, because by construction it agrees with itself.

From which follows the second rule: the “before flight” reading must exactly match the last posted state. Not approximately, not within rounding — exactly. A discrepancy means one of three things: a missed flight, a counter that was reset or replaced, or a misread. All three have to be resolved before the entry is filed, not at month end. An electronic system can run that check automatically at the moment of signature; on paper it is done by a human being, or by nobody.

Third: a helicopter usually has more than one counter (block time, tachometer, sometimes a separate engine counter with an offset), and the maintenance programme names a specific counter for each limit. The entry has to record all of them, because a missing utilisation basis cannot be reconstructed after the fact. The same mechanism is covered in more depth in the write-up on maintenance tracking and tolerances.

NIL or a defect — there is no third option

An empty “remarks” box is ambiguous: it means either “no defects” or “I did not get round to writing it”. A document that allows that ambiguity in the field describing technical state has stopped being a handover.

So the entry should force an explicit choice: NIL or at least one report. One click of difference, with a large consequence — after a year of operation the register answers the question “did the aircraft come back serviceable from every flight” without anyone having to interpret blank boxes.

The content of a defect report has its own rule, worth writing into the procedures: describe the symptom, not the diagnosis. “Vibration in the 80–90 % NR range, increasing” is an airmanship observation. “Bearing needs replacing” is a conclusion the pilot rarely has grounds for, which can point maintenance down the wrong path — and which stays in the documentation for good.

Then three states a defect must be able to hold: open, deferred (with a deadline and a basis for the deferral, such as an MEL item) and closed (with the rectification and a reference to the certificate of release to service). A defect without a state is a note, not part of a record system.

The pre-flight check and the signature

Confirmation that the pre-flight check was carried out (ML.A.301) belongs in the entry, not on a separate sheet. In an electronic system the cleanest arrangement is to make it a condition of the signature: no confirmation, no entry. That is not obstructing the pilot — it is the only way to demonstrate, a year later, that the check preceded every flight rather than only the flights where somebody remembered the box.

The signature closes the entry. From that moment the content is no longer editable and the counter increments are posted. What an electronic signature has to cover — identity, confirmation of intent, server time and a closed list of fields inside the hash — is covered in the write-up on what a Part-ML record system must do.

Four errors you only see in the data

1. “Counter after” equal to the previous reading. The classic omission on a rushed entry. Without a continuity check it passes unnoticed, the airframe total stalls by one flight — and every task in the due list quietly gains the same amount.
2. The same flight entered twice. Usually born when the first entry “would not save”. The effect is the mirror image: the counter jumps one flight too far and the inspection falls due earlier than it should. The worse variant: the two entries differ by a few minutes and nobody can establish which is true.
3. A blank box instead of NIL. Six months later nobody can reconstruct whether the aircraft came back serviceable. During an airworthiness review this is exactly the point at which the conversation moves from engineering to record quality.
4. Rounded times. A run of 1:00, 1:30, 2:00 means somebody is reporting an estimate rather than a reading. Over a year this adds up to a double-digit hour difference — always adverse, because estimates run low.

What to do with a mistake

In a paper log you correct by striking through and initialling — because an obliterated record stops being evidence. The same principle applies electronically, in a different form: a signed entry is not edited. The correction is a void: a reversing record that posts compensating increments and requires a stated reason, after which the correct entry is filed. Both remain in the register, exactly like the struck-through line and the one written beside it.

If an application lets you “just fix” a signed entry, that single fact tells you more about the system than its entire feature list. It is worth testing during a demo, before an inspector tests it for you.