Going Paperless Fails at the Aircraft, Not at the Office

The paperless business case is written from the wrong end

Read any proposal for an electronic tech log or a paperless flight operations rollout and notice whose day it describes. Dispatch stops chasing sectors. Engineering sees a defect the hour it happens rather than the week it happens. Finance closes the month without waiting for a folder to arrive by courier. Somebody can finally count something.

What the same programme asks of the crew

All of that is real and worth having. But turn the document around. What changes for the pilot? They used to write on a sheet, in whatever order suited them, and hand it over. Now they unlock a device, wait for it to wake, find the right sector among several that look alike, and complete a set of fields that somebody who has never flown that route decided were mandatory.

Why the workaround is always paper and a photograph

The programme has moved effort toward the person with the least time available and moved benefit toward the people with the most. That asymmetry is not a detail. It is the whole mechanism. Systems built this way do not get rejected outright; they get worked around, and the workaround in this industry is entirely predictable. The crew writes on paper anyway and photographs it at the hotel. The office now receives an image, unstructured, several hours late, in a message thread, and pays a licence fee for the privilege.

Paper is a strong competitor and deserves the respect

It helps to stop treating paper as a legacy problem and start treating it as an incumbent with a genuinely good feature set. It has been iterated on for a century and it is very hard to beat in the specific conditions where the record gets made.

Where paper actually falls down

Paper's weaknesses are real, but notice that every one of them is downstream. It is a poor transmitter, a poor aggregator, and a single copy that can be lost, misread or quietly amended with the same pen that wrote it. Those failures belong to everyone except the person holding it, which is precisely why paper keeps winning the argument at the aircraft and losing it in the boardroom. The practical consequence is that a digital flight log has to beat paper in the rain at the end of a twelve-hour duty, not in a demonstration on office wifi with a full battery and a rested presenter. Winning only the second contest is not winning.

Offline is the assumption, not the edge case

Aircraft spend their working lives in exactly the places with the worst connectivity. A remote strip. An apron behind a hangar with a steel roof between the device and everything else. A foreign station where nobody enabled roaming. Altitude. The moments when the record most needs to be made are systematically the moments when the network is least likely to be there.

So offline capability is not a feature to be listed alongside others. It is the assumption the whole thing rests on. An offline flight operations app must allow a complete, signed entry with no connectivity whatsoever, and it must be no slower or more awkward in that state than in any other. Anything that degrades when it cannot reach a server is a web form with an app icon.

What happens when the device reconnects

The genuinely hard part is not disconnection. It is reconnection. While the device was dark, the record on it and the record everyone else could see went their separate ways. The sector was rescheduled. Someone in the office corrected a figure the crew had also corrected, differently. There are now two accounts of the same flight and they do not match.

The failure that matters is not lost data. Lost data announces itself. The dangerous outcome is data reconciled silently — one version quietly replacing another with nobody told, which is how an operation ends up confidently reporting a number no human being ever asserted. Divergence has to become visible to a person, and the resolution has to be legible afterwards. Crews also need an unambiguous answer to one question: has what I wrote actually left this device? If that is ever uncertain, sensible pilots keep a paper copy as insurance, and you are back where you started with extra steps.

Capture at the point of truth, or transcribe it later

Every hop between an event and its record introduces delay and error. That much is obvious. What is less obvious, and much more damaging, is that the errors are not random.

Times recalled an hour later round to the nearest five minutes. They do not scatter evenly around the true value; they land on tidy numbers and drift toward whatever was planned, because the plan is what the person remembers once the detail has gone. Fuel figures get quietly reconciled so the arithmetic works. A twelve-minute hold short of the runway becomes taxi time and then ceases to exist. Noise you can average out over a quarter. Bias you cannot, and it compounds in the places you care about: duty and flight time calculations, block-time analysis, invoiced hours, the trend data engineering uses to decide whether something is getting worse.

That is the case for flight data capture at the point of truth, and it is not a purity argument. A record made ten minutes after the event contains different information from one made three hours later, and the difference is systematically flattering.

What should be captured immediately, and what can wait

The honest counterweight is that the point of truth is also the point of maximum workload. Nobody should be filling in fields during a critical phase of flight, and a design that assumes they will is worse than the transcription it replaced. The realistic goal is narrower and more useful: capture the perishable things while they are still true, let everything else wait, and be deliberate about which is which. Most post-flight reporting fails this test by treating every field as equally urgent, which guarantees that all of them get done at once, badly, at the end. That is also how the same flight ends up recorded three different ways in three different systems — the fragmentation problem starting at the aircraft rather than in the back office.

What structure buys, and what it costs the person writing

Free text is fast for the writer and nearly useless in aggregate. A defect described in a well-written sentence is perfectly readable by the engineer who opens it and impossible to count across a fleet. You cannot ask how often that snag recurred, or on which tails, without a person reading three hundred sentences.

Structure fixes that and charges for it. Every mandatory field is a toll levied on the person least able to pay it, and the tolls add up faster than anyone estimates. Past a certain point crews stop completing forms thoughtfully and start completing them survivably: the shortest legal input that makes the screen go away. The data then looks complete and means nothing, which is the worst of both worlds, because it is now trusted.

How to tell whether a mandatory field earns its place

The judgement is field by field, and the test is blunt. What decision downstream changes because this is structured rather than written? If nobody can name the decision, the field exists because somebody once wanted a column, and it should go. Forms that were built by transcribing the paper sheet box for box are particularly prone to this, because half those boxes only existed to make a printed grid balance.

The workable shape is a small set of structured fields that everything downstream genuinely depends on, and a generous free-text space alongside for the thing the form did not anticipate. Remove that space and you have removed the only channel through which the operation learns anything it was not already expecting.

Signature, attribution and electronic records compliance

An electronic record has to answer three questions as well as ink does: who attested, to what exactly, and when. Then a fourth that paper answers by physics — has it changed since?

Many regulators now accept electronic records where the operator can demonstrate integrity, attribution and availability, but the applicable regime differs by jurisdiction and by class of record, and the burden almost always sits with the operator rather than the supplier. Nobody from an authority is going to be satisfied by an assurance that the software handles it.

Attribution when one device serves several crews

Attribution is where most implementations are weakest, and the weakness is organisational rather than technical. A tick box on a shared tablet logged in as “crew” attests nothing at all, and a digital signature that cannot be tied to an identified individual at an identified moment is a graphic. Where one device serves several crews in a day, the question of who signed has to be answered deliberately, because the default answer will be wrong.

Why an amended entry has to still show the original

Amendment deserves the same care. Ink is amended visibly: struck through, initialled, dated, with the original still legible underneath. That is a feature, not an accident, and it is the standard an electronic record has to meet. Any aircraft logbook software that makes past entries editable without leaving a mark has removed the property that made the record worth keeping.

Retention, and what happens if the supplier relationship ends

Retention is the part everyone defers. A record nobody can produce on demand is functionally not a record. The questions are unglamorous and worth asking early: what does this look like in seven years, who can retrieve a specific sector from four years ago without assistance, and what happens to the archive if the commercial arrangement with the supplier ends. That last one belongs in the total cost conversation rather than the compliance one, but it gets asked in neither.

Half-paperless is more expensive than either state

The cautious rollout plan is always the same: run both for a while, in parallel, until everyone is comfortable. It sounds like risk management. It is usually the most expensive state an operation can occupy.

Running both means reconciling both. Two records of the same sector will disagree — not occasionally, routinely — and the reconciliation is a person, doing it by hand, at the exact moment the organisation was told its administrative burden would fall. Worse is the ambiguity about which one counts. Ask five people in a dual-running operation which record is authoritative and you will get at least two answers.

A parallel run with a date and a named condition for ending is a transition. One without either is a permanent tax, and it hardens: after a year, both processes have their defenders and neither can be removed without an argument. If nobody in the organisation will commit to the date the paper stops, that is not a scheduling detail. It is the clearest available signal that the electronic record is not yet trusted, and that is the thing to fix before anything else.

Devices, mounts and the pilot's personal phone

The kit is the other half of this, and it is where programmes die quietly. Devices need to survive a long duty, a cold soak overnight and a flight deck in direct sun. They need mounts that work in the aircraft you actually operate rather than the one in the brochure photograph. Updates have to arrive at a moment of the operation's choosing, not at pushback. And where a crew mobile app runs on a pilot's personal phone, that phone is now doing regulatory work: someone has to decide who pays for it, what the operator may do to it, what happens to the records on it when the pilot leaves, and whether a crew member may decline. None of this is interesting. All of it is load-bearing.

Whether it survives contact with the ramp

Most of the questions asked during a paperless evaluation are about the office end, because that is where the evaluators sit. These are the ones that actually predict the outcome:

• Can a complete, signed entry be made with the device in flight mode, and is it any slower that way?
• How many taps and how many seconds from picking up the device to a finished sector record? Measure it on the ramp, not at a desk
• When the device reconnects and two versions of the flight disagree, does a human being find out?
• Can a crew member tell, without asking anyone, whether what they wrote has left the device?
• For each mandatory field, name the decision downstream that changes because it is structured. If you cannot, delete it
• Is there somewhere to write the thing the form did not anticipate, and does anyone read it?
• Can you show who attested to a specific entry, when, and that it has not changed since — to someone who is not inclined to take your word for it?
• What is the date the paper stops, and who owns it?

It is why the crew-facing side of Aerotalon is the part we argue about most. The person with the least time to spare is the one who decides whether any of the rest of it works.

A paperless programme is not a data project with a device attached. It is a change to the last two minutes of somebody's working day, repeated several thousand times a year by people who did not ask for it. Design those two minutes properly and the structured data arrives on its own. Design them badly and no amount of reporting at the other end will save it, because the record it is reporting on was written on paper in a car park and photographed later.