Electronic techlog
A technical logbook that posts the counters for you
It is the same logbook ML.A.305 asks for, with one difference: the pilot signature does not end the work, it starts it. Closing an entry moves the counters of the aircraft and of every installed component, and from there every maintenance task due point is recomputed. There is no step called “someone will retype the hours tonight”.
- One entry per flight, never a daily summary
- Signature: password + SHA-256 + server time
- Once signed, not even a database administrator can change it
- Offline queue: the entry is written with no signal
Anatomy
What one entry holds
The form is short because it is filled in next to the aircraft, one-handed, often with gloves on. Every field is required for the signature — a missing one keeps the entry as a draft.
- Flight date and route
- The date of the actual flight, not the date of typing. Reconstructing an entry after an outage looks exactly like a current entry.
- Block off and block on
- Hour and minute. Time is stored in whole minutes — no decimal hours and no rounding in the convenient direction.
- Counter readings before and after
- Block and tach as separate bases. The “before” reading must match the last posted state exactly, otherwise the entry does not pass.
- Landings and starts
- Whole numbers. They feed the cycle axis for components whose limits are expressed in cycles.
- Fuel and oil
- State before flight, uplift, oil added. Oil top-ups are the first signal that something is happening to the engine.
- Pre-flight check
- Confirmation is a precondition of the signature (ML.A.301). Without it the entry stays a draft.
- NIL or a defect
- There is no third option. A defect gets a status, an optional deferral date and a rectification note; the aircraft gets a visible limitation.
- Pilot in command
- Always the signed-in person. There is no way to indicate “on whose behalf” a signature is made — neither in the app nor in the database.
A saved but unsigned entry is a draft: it is visible in the register, but it moves no counter and affects no due date. Only the signature posts.
- BLOCK przed
- 411:24
- TACH przed
- 388:11
Przegląd 100 h za 37:42 FH · 1 usterka odroczona
Comparison
What actually changes against paper
A paper logbook is not bad — it is simply cut off from the rest of the records. Below are the places where that cut costs you.
| Situation | Paper logbook | CamoBook |
|---|---|---|
| Hours after a flight | Reach the maintenance programme when somebody retypes them — usually in the evening, sometimes several flights later | The signature posts the counters in the same transaction; there is no second register to retype into |
| Continuity of readings | A missed flight surfaces at the next reconciliation, if anyone runs one | Checked at every signature: the “before” reading must match the last posted state exactly |
| A mistake in an entry | Crossed out and initialled; a month later nobody remembers what was there first | A reversal with compensating increments plus a new entry — both stay in the register, with a reason |
| CAMO visibility | Once the logbook comes back to the office | Immediately: the due list and airworthiness status see the flight as soon as it is signed |
| Backup of the record | A photocopy, or nothing | A database dump every day and a copy taken outside the production environment every week |
| An authority audit | Assembling the pack from binders, usually several days | One ZIP: CSV, PDF and a manifest with SHA-256 checksums |
Signature
Electronic signature and immutability
The signature is re-entering your password immediately before confirming the entry. The system computes a SHA-256 digest over a closed list of entry fields — times, counters, landings, fuel, defects, route, remarks, signatory — and stores it together with the server timestamp. The clock on the pilot device has no influence on the signing date.
Once signed, the entry is immutable. The lock lives in the database rather than in the application, so an attempt to change or delete it fails even for the operator database administrator. The same rule covers dependent rows: the counter readings and defect records created by the signature.
Mistakes are corrected in the open. A mechanic or an administrator performs a reversal with a mandatory justification — it posts compensating increments on the counters — and then enters the correct record. Both entries stay in the register: the original one flagged as reversed, and the correcting one. Nothing disappears, and the authority sees the full trail.
- 01
What the signature covers
A closed list of fields. Changing any of them after signing would change the digest — and that is exactly what the integrity check catches, run daily and before every export for the authority.
- 02
Who signs
Only the signed-in person, and only their own entry. A pilot cannot perform a mechanic action — the refusal sits on the server and in the database, not behind a hidden button.
- 03
Guessing protection
The number of failed password attempts is limited: the lockout grows exponentially but is capped, so a typo does not ground the crew for hours.
Hangar
Working with no signal
The application is a PWA with its own service worker, so pilot routes open with no network — even ones the pilot has never visited before. The entry is stored in a queue on the device and is sent automatically once connectivity returns, in the order it was written.
The system never overwrites a pilot entry with server data. If somebody registered another flight of the same aircraft in the meantime, the pilot gets a plain comparison — “your entry / state per server” — and a recomputation proposal that preserves their readings. It has to be accepted deliberately and signed again.
If an earlier flight is missing because another device has not synchronised yet, the entry waits in quarantine and attaches itself once its predecessor arrives. After twenty-four hours without a resolution the case is flagged for CAMO review.
-
Queue on the device
Stored locally, sent in creation order. Closing the tab or restarting the phone does not lose the entry.
-
No “server wins”
Conflict resolution belongs to a human and always ends with a fresh signature.
-
Signing needs the network
The password is verified by the server. An entry made with no signal is complete, but stays a draft until connectivity returns — we say so plainly, because it is a real limitation.
Printouts
Everything exists in a human-readable form
Records are only legible for the whole retention period if they can be read without this application. So every document has an A4 and a PDF form, and exports use open formats.
- A single techlog entry together with its signature, digest and defects.
- The techlog register for a period — one aircraft or the whole fleet, including reversed and correcting entries.
- The aircraft due list with the remaining margin for every task.
- The authority pack: one ZIP with the techlog register (CSV and PDF), the due list, compliance history, AD and SB status, components, defects, aircraft documents and a manifest with SHA-256 checksums.
If the PDF generator is temporarily unavailable the pack is still produced — with the CSV files and an explicit reason for the missing PDF in the manifest. Data is never unavailable because a printing add-on failed.
- rejestr-pdt.csv sha256 2f1c…9ab4
- rejestr-pdt.pdf sha256 8d70…13ec
- due-lista.csv sha256 c4a9…7f21
- wykonania.csv sha256 5be2…0d88
- ad-status.csv sha256 a017…c53f
- komponenty.csv sha256 9e4d…6b02
- usterki.csv sha256 31fa…8e7d
- dokumenty/ sha256 —
- manifest.txt sha256 —
Compliance
Where this sits in ML.A.305
We do not claim the system “is compliant” — compliance is demonstrated by the operator to its own authority. Below are the mechanisms it has to show.
| Requirement (short) | Mechanism in the system |
|---|---|
| ML.A.305(b)(1) — record of every flight | One entry per flight: times, landings and counter readings in whole minutes; flight date independent of the entry date. |
| ML.A.305(b)(1) — defect reporting | A mandatory NIL or at least one defect on every entry; each defect has a status, a deferral date and a rectification note. |
| ML.A.305(c) — accurate and current records | The signature posts counters straight away; continuity of readings is verified at every signature, with no second register to retype. |
| ML.A.305(e) — no editing after certification | Immutability enforced in the database; corrections only through a reversal with compensating increments plus a new entry. |
| ML.A.305(h) — retention periods | The system does not delete records — deletion is technically blocked. A retention report shows what is held and since when. |
| AMC1 ML.A.305 — computerised system | Daily backup on media separate from working data, legibility (A4, PDF, CSV), a SHA-256 hash chain, access control and an outage procedure. |
Requirements are paraphrased and shortened, purely as a pointer to the relevant provision. What binds you is the current consolidated text of Regulation (EU) No 1321/2014 and your own procedures as accepted by the authority.
Plainly
What an electronic techlog will not solve
- It does not issue a CRS. The release to service is produced outside the system; its number and scan go into the task compliance record.
- It does not replace the paper logbook overnight. A rollout runs as a dual-run until the authority accepts the system, and paper prevails in case of divergence.
- It will not sign an entry offline — the password is verified by the server.
- It does not migrate flight history from paper. You enter the starting state through an opening balance, under a mechanic signature and with a note on the source.
FAQ
Frequently asked questions
May an electronic logbook replace the paper one?
The regulation requires a continuing airworthiness record system — it does not require it to be on paper. AMC1 ML.A.305 spells out the conditions for a computerised system: a backup updated within 24 hours and kept separately from working data, legibility for the whole retention period, protection against unauthorised change, access control and a procedure for when the system is unavailable. Acceptance of the system is issued by the operator authority, which is why we run the rollout as a dual-run with the paper logbook.
What happens if a pilot mistypes a counter reading?
If the error is in the “before flight” reading, the entry will not pass the signature: the system requires an exact match with the last posted state and shows the difference. If the error surfaces after signing, the entry is not edited — a mechanic performs a reversal with a justification, which posts compensating increments, and then enters the correct record. A genuine counter discrepancy (after a counter replacement, for instance) is fixed by a separate counter correction, also with a mandatory justification.
Do pilots need accounts and training?
Accounts are individual, because signature attribution demands it — a shared “pilot” login would defeat the whole mechanism. The entry screen has a single path and fits a phone, so training a pilot next to the aircraft takes about fifteen minutes. Mechanics and administrators get wider rights and a longer introduction, because they are the ones doing reversals, counter corrections and the opening balance.
What does the pilot see before a flight?
Current counter readings, the airworthiness state of the aircraft (approaching and exceeded due dates, open defects with their limitations) and the validity of their own qualifications. A warning does not block the flight — the decision belongs to the pilot in command — but their deliberate acknowledgement is written to the event register.
Next
The nearest topics — on the site and in the knowledge base.
On the site
- Maintenance tracking
Hour, calendar and cycle limits, tolerances without drift, due-date forecasting.
- Bulletins and ADs
Automatic ingest of SBs, SLs and ADs, review and sign-off, manual route.
- Security
Backups, the audit chain, roles, retention and what happens in an outage.
In the knowledge base
- The electronic techlog and Part-ML: what a record system must do
What ML.A.305 and AMC1 ML.A.305 expect from a computerised technical logbook, and what you actually have to show an inspector to leave paper behind.
- The techlog entry: what it has to contain
The anatomy of one techlog entry: block times, counter readings, landings, the pre-flight check, NIL-or-defect and the signature — plus the errors that only show up in the data.
- From paper to electronic records without losing history
The opening balance, the dual-run and the list of things to agree with your authority. What actually has to be transcribed, what must never be imported, and how long it takes.
See CamoBook on your own fleet
Thirty minutes, live: a signed techlog entry, the due list for your aircraft type and the audit pack. No sales deck — we talk about your maintenance programme.
or write to pawel@mamcarz.com