Skip to content
CamoBook — Home CamoBook

e-techlog · CAMO · Part-ML

Electronic technical logbook and CAMO in one chain of data

The pilot signs the techlog entry and the counters, life limits and airworthiness status recalculate themselves. There is no step where someone retypes hours into a second register — so there is no place where the two registers can quietly drift apart.

Book a demo How it works
  • Signature: password + SHA-256 + server time
  • Entries with no signal, in the hangar
  • Audit pack in one click
  • Block and tach as separate counters

Version 1.0 is being rolled out at the founding operator, dual-running with the paper logbook until the authority accepts it. We have no reference customer list yet and we are not going to invent one.

PDT · Nowy wpis offline · w kolejce 1
SP-GDM Guimbal Cabri G2
BLOCK przed
411:24
TACH przed
388:11

Przegląd 100 h za 37:42 FH · 1 usterka odroczona

Czas blokowy 0:54
Lądowania 3
Uruchomienia 1
Przegląd przedlotowy wykonany
NIL Usterka
Podpisz wpis (wymaga hasła)
Layout mock-up of an application screen — a faithful rendering, not a screenshot. The interface is in Polish.

Starting point

Where the risk in a paper workflow comes from

Not from sloppiness. From the same flight hours living in two places at once, joined by a human — usually in the evening, usually from memory.

  • 01

    The logbook stays in the aircraft

    The techlog sits in the cockpit, the maintenance programme sits in the office. Until someone reconciles them, CAMO is working on data that is several flights old.

  • 02

    Hours are retyped by hand

    The same flight time entered a second time into a spreadsheet is the single most common source of divergence between aircraft hours and maintenance task status.

  • 03

    Deadlines are watched by memory

    The 100 h inspection, ARC, CofA, insurance, an airworthiness directive, a component life limit. A spreadsheet will not call you, and a tolerance used without an anchor pushes the whole cycle forward.

  • 04

    An audit costs a week

    The pack for the inspector is assembled by hand from binders, and every handwritten correction needs an explanation of what was changed and why.

What the system does

Six things CamoBook does end to end

Below is what is implemented and tested, not what is planned. What is still missing is spelled out further down, in plain words.

01

Techlog entry with an electronic signature

Signing means re-entering your password, a SHA-256 digest of a closed list of entry fields and a server timestamp — never the time on the pilot device. After signing, the entry cannot be changed or deleted, not even in the database. A mistake is corrected by a reversal with compensating increments plus a new entry; both stay in the register.

  • Immutability enforced in the database
  • Reversal instead of editing
  • NIL or a defect — there is no third option
02

Works in the hangar with no signal

The application is a PWA with its own service worker: pilot routes open without a network even if the pilot has never visited them before. The entry goes into a queue on the device and is sent automatically once connectivity returns. The server never overwrites the pilot entry — a conflict produces a side-by-side “your entry / server state” view, a re-base proposal that preserves your increment, and a mandatory re-signature.

  • IndexedDB queue, FIFO
  • Quarantine for a missing preceding flight
  • No “server wins”
03

A life-limit engine that does not drift

Hour, calendar and cycle limits, the “whichever occurs first” and “whichever occurs later” rules, tolerances anchored to the planned due point rather than the actual completion date — so inspections do not creep forward with every visit. The remaining-time forecast takes the more conservative of two utilisation rates: the 30-day and the 90-day average.

  • Block and tach as separate hour bases
  • A “no data” status instead of a fictional forecast
  • Engine covered by golden and property tests
04

Defects, components, aircraft documents

Every entry requires either NIL or a defect description; a defect has a status, a deferral deadline and a rectification record. Components carry an installation history — moving an engine moves the whole sub-tree of accessories with it, and removal records the counter state at that moment. ARC, CofA, insurance and AFM have expiry dates with alerts 60 and 30 days ahead.

  • Installation history cannot be deleted
  • Withdrawing a document means archiving it
  • Daily e-mail alerts
05

Manufacturer bulletins and airworthiness directives

A daily job pulls publications from Robinson, Extra and Bell, plus EASA airworthiness directives for the types in your fleet — the search terms follow your fleet, so a new type automatically widens the intake. A new revision automatically supersedes the previous one, files are de-duplicated by SHA-256, and the catalogue has filters, sorting and bulk actions. Applicability assessment stays with CAMO — the system does not fake it.

  • Robinson · Extra · Bell · EASA AD
  • Guimbal: manual upload (no public source)
  • Revision supersedure
06

Audit pack in one click

One ZIP: the techlog register for the period (CSV and PDF, including reversed entries), the due list, the compliance history, AD/SB status, components with installation history, defects, aircraft documents and a manifest with SHA-256 checksums of every file. Generating the pack is recorded in the event register: who, when, what scope.

  • Open formats — readable without this application
  • Manifest with SHA-256 checksums
  • A PDF outage does not block the export

Also inside

  • Pilot logbook with flight-time statistics, CSV export and an A4 printout.
  • Opening balance from the paper logbook: CSV templates generated with the real counter and task codes, a dry run that writes nothing, and approval under the engineer signature.
  • Flight import from the Best Pilot training system — never creating accounts, with person mapping confirmed by hand.
  • An event register chained with hashes: deleting or swapping a row breaks the chain and is detectable.
  • An A4 print view of every document and PDF on demand.
  • Light and dark theme — readable in sunlight on the apron and at dusk in the hangar.
Resursy · due-lista floty 2 statki · 5 zadań
Zadanie Statek Limit Termin Pozostało Postęp Status
100H-PLAT Przegląd 100 h płatowca SP-GDM Nalot (block) przy 450:00 37:42 FH wkrótce
ARC Przegląd zdatności do lotu (ARC) SP-GDM Kalendarz 14.09.2026 50 dni wkrótce
LLP-MR Łopata wirnika nośnego — resurs SP-GDM Nalot (block) przy 2200:00 1787:42 FH dopuszczony
AD-SILNIK Dyrektywa zdatności — zespół napędowy SP-DGM Kalendarz 02.08.2026 7 dni w tolerancji
12M-WYP Przegląd 12-miesięczny wyposażenia SP-DGM — — — brak danych
Layout mock-up of an application screen — a faithful rendering, not a screenshot. The interface is in Polish.

Flow

How it works, in three steps

  1. 01

    The pilot closes the flight

    On a tablet next to the aircraft: block off / block on times, counter readings taken from the instrument, landings and starts, fuel, pre-flight check confirmation and either NIL or a defect. A saved but unsigned entry is a draft and moves no counter.

  2. 02

    The system posts under a lock

    Signing verifies counter continuity (the “before” reading must match the last posted state exactly), moves the aircraft and installed component counters, recalculates the due date of every maintenance programme task and writes the event to the register.

  3. 03

    CAMO sees it and acts

    A fleet due list with statuses, e-mail alerts for approaching and exceeded deadlines, compliance recorded with the CRS reference and the counter state at the time of the work. For an audit — one ZIP instead of a week with binders.

Compliance

Part-ML, concretely: requirement → mechanism

We do not claim the system “is compliant”. Compliance is demonstrated by the operator to its own authority — we supply the mechanisms and the evidence you can put in front of an inspector.

SP-GDM · eksport dla urzędu ZIP · 01.01–26.07.2026
  • 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 —
Layout mock-up of an application screen — a faithful rendering, not a screenshot. The interface is in Polish.
Requirement (abridged) Mechanism in the system
ML.A.305(b)(1) — record of every flight One techlog entry per flight: times, landings and counter readings stored as whole minutes, with no convenient rounding.
ML.A.305(b)(2) — maintenance record with a CRS reference Compliance recorded with the date of the work, counter state at the time of the work, CRS number and who carried it out. Append-only.
ML.A.305(b)(3) — status of AMP, ADs and life-limited parts The engine computes every task due point from the compliance history and current counters; a separate AD/SB status list; components with life limits.
ML.A.305(c) — accurate and current records Signing posts the counters immediately. There is no second register to retype, and counter continuity is checked at every signature.
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 the working data, legible records (A4/PDF/CSV), a SHA-256 hash chain, access control with login throttling and a documented procedure for system downtime.
CAMO.A.220 — records kept by CAMO The event register covers CAMO activities: compliance entries, counter corrections, maintenance programme changes, bulletin assessments and audit-pack generation.

Requirements are quoted in abridged form and in our own words, as a pointer to the regulation. The binding text is the current consolidated version of Regulation (EU) No 1321/2014 together with the operator procedures. Rollouts run in dual-run with the paper logbook until the authority accepts the system.

Audience

Who it is for

  • Flying clubs and ATO/DTO schools

    Many pilots, one tablet in the hangar and accounts with separated roles. A pilot can only sign their own entry; maintenance actions are closed off on the server and in the database, not behind a hidden button.

  • Helicopter operators

    Cabri G2, R44, UH-1: block and tach as separate hour bases, components with life limits and installation history, manufacturer bulletins pulled every day.

  • Single-aircraft owners

    No CAMO department. Deadlines are watched by e-mail alerts and the due list rather than a phone calendar. The opening balance is transcribed from paper once, under an engineer signature.

  • Part-ML operators with their own CAMO

    The whole chain — from the pilot entry to the audit pack — in one system. Today the maintenance shop and the authority get a complete pack rather than an account; multi-organisation access is on the roadmap.

Plainly

What CamoBook does not do yet

This list is in the documentation prepared for the authority, and it belongs here too. An operator who learns about a limitation after the rollout has every right to feel misled.

  • It does not issue a CRS and does not manage work orders. The certificate is issued outside the system; its number and scan go into the compliance record.
  • It does not assess AD and bulletin applicability for CAMO. The catalogue is pulled automatically; the decision and its documentation belong to a human.
  • Version 1.0 supports a single organisation. The maintenance shop and the authority receive the audit pack, not an account.
  • Signing requires connectivity — the password is verified by the server. An entry made offline is complete but stays a draft until the link is back.
  • We publish no price list and no customer list. Rollouts are pilot projects, with a dual-run and pricing agreed individually.

Who is behind it

Written by an operator, not by a software house

CamoBook is a joint project of two companies based at the same airfield. It exists because keeping continuing airworthiness for a Cabri G2, an R44, a UH-1 and an Extra 300L in a spreadsheet and a binder stopped adding up. The first user of the system is its owner — and he carries the consequences of every shortcut in the code.

  • Helicopter pilot training organisation

    Heli Solution

    PPL(H) training, helicopter rental and sightseeing flights at Radom-Piastów airfield. The fleet on which CamoBook keeps a real technical log.

    Lotnicza 25, 26-660 Jedlinsk · ATO/DTO PL/DTO-105

  • Aerobatics and upset training (Warsaw Flight Safety)

    Akrobacja.com

    Aerobatic flights and training on the Extra 300L, run by world champion Maciej Kulaszewski. An aircraft with a demanding maintenance programme — hence the focus on life limits and manufacturer bulletins.

Both companies founded CamoBook and are its reference users — the fleet the system runs on every day.

  • Guimbal Cabri G2
  • Robinson R44
  • Bell UH-1
  • Extra 300L

Knowledge base

Knowledge base: e-techlog, Part-ML and life limits

All write-ups →

FAQ

Frequently asked questions

Is an electronic technical logbook acceptable under Part-ML?

The rule requires a continuing airworthiness record system — it does not require paper. AMC1 ML.A.305 describes the conditions for a computerised system explicitly: a backup updated within 24 hours and held separately from the working data, records legible throughout the retention period, protection against unauthorised alteration, access control and a procedure for periods when the system is unavailable. CamoBook implements each of these points, but acceptance of the system is granted by the operator competent authority — which is why rollouts run as a dual-run with the paper logbook.

Can a pilot record a flight with no signal in the hangar?

Yes. The application is a PWA with its own service worker, so pilot routes open without a network even if the pilot has never visited them before. The entry is stored in a queue on the device and sent automatically once connectivity returns, in the order it was written. Signing requires the network, because the password is verified by the server — until then the entry is a complete draft.

What happens when a pilot makes a mistake in a signed entry?

A signed entry cannot be edited — the block is in the database, not in the application. An engineer or administrator issues a reversal with a mandatory justification, which posts compensating increments to the counters, and then a correct entry is made. Both entries stay in the register: the original marked as reversed and the correcting one. Nothing disappears and the authority sees the full trail.

How do we move data from a paper logbook?

Through the opening balance: three CSV files — counters, the maintenance programme and the latest task compliance. Templates are generated live, with the real counter and task codes of that aircraft. A dry run shows line by line what will happen and writes nothing; approving the counters requires the engineer password and a note about the source, for example “paper techlog no. 3, page 41”. We do not migrate flight history — you enter the starting state.

Where do the bulletins and airworthiness directives come from?

A daily job pulls publications from the Robinson, Extra and Bell sites and airworthiness directives from the EASA database — the search terms are derived from the aircraft types in your fleet, so a new type automatically widens the intake. Guimbal does not publish bulletins publicly and we do not scrape behind a login: those documents are uploaded by hand into the same catalogue. Applicability to a specific airframe is assessed by CAMO.

What does an inspector receive during an audit?

A single ZIP from the “Aircraft → Authority export” screen: the techlog register for the selected period in CSV and PDF (including reversed and correcting entries), the due list, the compliance history, AD/SB status, components with installation history, defects, aircraft documents and a manifest with SHA-256 checksums of every file. The formats are open, so the data can be read without our application. Generating the pack is recorded in the event register.

Who has access to operator data?

An account belongs to exactly one organisation and sees only its data — changing an identifier in the URL does not expose another operator aircraft or entry, and that isolation has automated negative tests that run on every change to the system. There are three roles: pilot, engineer, administrator. The signatory is always the logged-in person; there is no way to indicate “on whose behalf” a signature is made.

How much does it cost?

We publish no price list, because the commercial model is not settled yet — we would rather say so than invent a pricing table. Rollouts are pilot projects: a conversation about your fleet and maintenance programme, then pricing based on the number of aircraft and how much data has to come off paper. Write to us through the form and you will get a concrete proposal.

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.

Book a demo

or write to kontakt@camobook.com