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 runs on the author’s own aircraft and on the training fleet of an operational partner, 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
1234:30
TACH przed
1198:00

Przegląd 500 h za 20:30 FH · usterek otwartych: brak

Czas blokowy 0:54
Lądowania 6
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 · 6 zadań
Zadanie Statek Limit Termin Pozostało Postęp Status
500H-PLAT Przegląd 500 h płatowca SP-GDM Nalot (block) przy 1255:00 19:36 FH wkrótce
100H-PLAT Przegląd 100 h płatowca SP-GDM Nalot (block) przy 1275:30 40:06 FH dopuszczony
ARC Przegląd zdatności do lotu (ARC) SP-GDM Kalendarz 26.02.2027 214 dni dopuszczony
LLP-MR Łopata wirnika nośnego – resurs SP-DGM Nalot (block) przy 2200:00 612:42 FH dopuszczony
12M-PLAT Przegląd 12-miesięczny płatowca SP-DGM Kalendarz 24.07.2026 27 dni tolerancji 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.

The chain

One flight in four links

See the full chain →

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.

  1. 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.

    Aircraft
    SP-GDM
    Flight time
    0:54
    Landings
    6
    Defects
    NIL
    Entry status
    draft changes to signed

    signature: password + SHA-256 + server time

  2. 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
    1234:30 changes to 1235:24
    Tach
    1198:00 changes to 1198:54
    Engine
    1084:30 changes to 1085:24
    Landings
    2898 changes to 2904

    increment +0:54 · +6 ldg

  3. 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.

    500 h inspection
    in 20:30 changes to in 19:36
    100 h inspection
    in 41:00 changes to in 40:06
    ARC
    214 days · unchanged
    Aircraft stops in
    approx. 14 days changes to approx. 13 days

    tolerance measured from the planned due point

  4. 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.

    Aircraft
    serviceable
    Pilot privileges
    valid
    Open defects
    none

    serviceable – 500 h inspection in 19:36

A diagram of the data flow, not a screenshot. The figures come from a demonstration fleet (SP-GDM) and exist only to show the mechanism – they are not any operator’s data and not real counter states. The same flight and the same counters sit behind the techlog entry mock-up and the maintenance due list elsewhere on this site.

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–27.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 have no customer list and no references to show – we are at the beginning. The price list, on the other hand, is public, and a rollout starts with 90 days of dual-run with paper.

Who is behind it

Written by an operator, not by a software house

CamoBook is built by mamcarz.com – Paweł Mamcarz – and published by his business, Doradztwo Paweł Mamcarz. It exists because keeping continuing airworthiness for his own Extra 300L in a spreadsheet and a binder stopped adding up, and it then had to survive the pace of a partner’s training fleet. The first user of the system is its author – and he carries the consequences of every shortcut in the code.

Author and publisher

mamcarz.com

CamoBook is written and maintained by Paweł Mamcarz (mamcarz.com) and published by his business, Doradztwo Paweł Mamcarz. The same entity runs the Akrobacja.com flight operation – so the first user of the system is its author, and he carries the consequences of every shortcut in the code.

Doradztwo Paweł Mamcarz · NIP 7122188089 · ul. Jesionowa 18, 05-825 Grodzisk Mazowiecki

The flight operations this came out of

  • The author’s own flight operation

    Akrobacja.com

    Aerobatic flights and training on the Extra 300L from Radom-Piastów airfield, run by the same business that publishes CamoBook. An airframe with a demanding maintenance programme – hence the focus on life limits and manufacturer bulletins. Flown by world champion Maciej Kulaszewski.

  • Operational partner – helicopter training organisation

    Heli Solution

    A separate company, not a co-publisher of the system. PPL(H) training, type ratings, rental and sightseeing flights in Jedlińsk, at Piastów airfield. Its training fleet – the Guimbal Cabri G2 and Robinson R44 – flies a lot, in short flights, with crews changing constantly. That is the fleet on which CamoBook keeps a technical log every day.

    Lotnicza 25, 26-660 Jedlińsk · ATO/DTO PL/DTO-105 · +48 797 105 105

Akrobacja.com is the author’s own flight operation; Heli Solution is a separate company and an operational partner. Neither publishes nor co-owns the system – they are the fleet CamoBook runs on every day.

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

Origin

Where this came from

CamoBook started with a paper log in the cockpit and a spreadsheet at the maintenance desk – two places where the same flight hours lived separate lives. The worst part was never the retyping; it was not knowing whether the counter behind the next inspection date was actually current. A look at the systems already on the market closed nothing: some keep a good log, others compute life limits well, none covered the whole path from the pilot’s entry to the answer whether the aircraft may fly tomorrow. So that path was built from scratch – first for one aerobatic aircraft, then for a partner’s training fleet.

Read the full story →

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?

Billing follows the aircraft, not the user – accounts for pilots, engineers and administrators are included. The rate is marginal, so every further aircraft costs less: the first powered aircraft is PLN 149 net per month on annual settlement, the first glider PLN 49, and from the sixteenth it is PLN 59 and PLN 27 respectively. The organisation minimum is PLN 149 per month, the rollout is a one-off (self-service PLN 0, guided from PLN 1,900 for the first aircraft), and it starts with 90 days of pilot dual-run with no subscription. The full table, with worked examples for typical fleets, is on the Pricing page.

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 [email protected]