The electronic techlog and Part-ML: what a record system must do

The question that comes up first is always the same: “is an electronic technical logbook even allowed?” The rule does not say paper. It says continuing airworthiness record system. Paper is one possible implementation of that system, not the requirement itself.

That does not mean any application will do. Below is what you actually need before the conversation with your authority becomes a conversation about a date rather than about the principle.

What ML.A.305 requires

Continuing airworthiness records cover four groups of information, and all of them have to stay consistent with each other:

• a record of every flight — times, landings and cycles, counter readings,
• a record of maintenance carried out, referenced to the certificate of release to service,
• the current status of the maintenance programme, airworthiness directives and life-limited parts,
• records that are accurate and current, protected against alteration, retained for the required period and handed over with the aircraft when ownership changes.

The usual weakness of a paper-plus-spreadsheet workflow is not in any one of those points. It sits between them: the techlog stays in the cockpit, the maintenance programme lives in a spreadsheet in the office, and a human joins them by retyping hours. Every retype is a fresh opportunity for a divergence that nobody notices until an audit or an overrun.

That is why, in an electronic system, the important part is not that it “lives in a computer”. The important part is that there is one chain of data: flight → counter → life limit → maintenance → release → airworthiness status visible back at the pilot. If the application still expects someone to copy hours from one screen to another, it reproduces exactly the same problem, only faster.

What AMC1 ML.A.305 adds for a computerised system

The acceptable means of compliance describes the conditions for a computerised system explicitly. In practice, an operator has to be able to answer five questions:

Inspector question	What it is about
When was the last backup taken?	A backup updated within 24 hours of a new entry
Where is that backup kept?	Media separate from the working data, with a periodic copy held outside the production environment
Will these records be readable in three years?	Legibility for the whole retention period — A4 printout, PDF, open format (CSV)
Who could have changed this entry?	Protection against unauthorised alteration, plus access control
What do you do when the system is down?	A documented contingency and reconstruction procedure

Notice what those questions are not about. Not whether the interface is pretty or whether there is a mobile app, but whether a record that looks correct today will still be trustworthy in three years, and whether you can demonstrate that nobody quietly fixed it along the way.

Demonstrating immutability instead of declaring it

“Our system does not allow entries to be edited” is worth exactly as much as the mechanism behind it. Three things can be demonstrated, ideally together:

1. Append-only records instead of overwritten fields. A counter state is not a field you overwrite; it is the sum of a stream of readings. The current value is derived from history, so silently “fixing” a counter is impossible by construction.
2. A block in the database layer, not in the application. If immutability lives only in interface code, then the database administrator can change an entry. The block has to hold even when somebody bypasses the application.
3. An event register chained with hashes. Each row carries a digest that covers the digest of the previous row. Deleting, inserting or swapping any row breaks the chain — and that is detectable with a tool you can run in front of an inspector.

There is one more thing operators discover only in practice: corrections have to be designed in from the start. If a signed entry may not be edited, you need a reversal mechanism — an opposite record with compensating increments and a mandatory justification, followed by the correct entry. Both stay in the register. It is the same logic as a struck-through line with initials in a paper logbook, minus the option of reaching for correction fluid.

The electronic signature: what to settle with the authority

The signature is usually the shortest part of the discussion, provided you bring four elements:

• identity — the signatory is always the logged-in person; there is no “on behalf of” field,
• confirmation of intent — re-entering the password immediately before signing,
• time — a server timestamp, never the clock on the pilot device,
• the content covered by the signature — a closed list of fields and its cryptographic digest stored with the entry.

The last point is often skipped and it matters most: without an explicitly defined signature scope you cannot later say what exactly was signed. If a new field is added to the entry one day, someone has to decide consciously whether it enters the digest — adding it silently invalidates the immutability evidence for all earlier entries.

Dual-run, or how this looks in practice

Even a complete set of mechanisms does not remove the procedure. The practical path — set out in more detail in the write-up on moving from paper to electronic records — looks like this:

1. Prepare a system description for the authority: where the data comes from, who approves it, how you demonstrate integrity, what the contingency procedure is.
2. Enter the opening balance — the starting state from the paper logbook, under an engineer signature, with the assumptions listed in the open.
3. Run a dual-run: for an agreed period, keep the paper and the electronic logbook in parallel, with a clear rule about which one prevails in case of a discrepancy.
4. Collect the list of points for the authority to confirm — the retention interpretation, the layout of the printed entry, recognition of the electronic signature, and the scope and end date of the dual-run.

That last item is not a formality. It is the list where “the system meets the requirements” in the marketing sense ends, and what has actually been agreed with your specific authority begins.

Summary

An electronic technical logbook is acceptable as long as it is a record system rather than a prettier spreadsheet. The test is simple and takes fifteen minutes with any application: ask what happens after an entry with a mistake is signed, who detects a row being altered in the database and how, and what exactly lands in the pack for the inspector. Those three answers tell you more about a system than its whole feature list.