The EFB performance cross-check is the least glamorous item in the EFB framework and the one that stops the most accidents. The performance and mass-and-balance applications are the type B tools that most directly touch safety, because their output drives take-off speeds, thrust, runway suitability and centre-of-gravity limits. And here is the uncomfortable truth: these apps are almost never wrong because the software failed. They are wrong because of what went into them.

Why the EFB performance cross-check exists

A transposed weight — 26,000 kilograms typed as 62,000. The wrong runway or intersection. A stale wind, an outdated configuration, the wrong flap setting. The computer faithfully turns a wrong input into a confident, precise, wrong answer — and a precise wrong answer is more dangerous than an obviously rough one, because it looks authoritative. This is exactly the minor-or-worse risk that made these applications type B in the first place.

The failure mode is human, and it looks like success

It is worth being blunt about the shape of this failure, because it is not the shape crews are trained to expect. There is no warning, no amber caption, no degraded mode. The application behaves perfectly. It receives a number, applies a valid method, and returns a result to two decimal places. Everything about the presentation says the answer is trustworthy, and the only thing wrong with it is the premise.

Paper tables were, in one narrow respect, more forgiving. Interpolating by hand kept the pilot inside the shape of the numbers, and a figure that did not belong tended to feel wrong on the page. A tablet removes that contact with the data. It offers a single, clean output, and the cognitive work that used to sit in the calculation now has to be reinserted deliberately. That reinsertion is the cross-check.

The categories of input error worth rehearsing

• Transposition and magnitude. Digits swapped, a decimal misplaced, a unit assumed. The result is often wildly wrong and therefore catchable — if anyone is holding an expectation to catch it against.
• Wrong context. The right calculation for the wrong runway, the wrong intersection, the wrong departure. Nothing about the figure looks unreasonable; it is simply an answer to a different question.
• Stale data. A wind, a temperature or a configuration entered earlier and still sitting in the field after conditions moved on.
• Wrong configuration. A flap setting or a thrust option that does not match what the crew will actually fly.

In our experience the second and third categories are the dangerous ones, precisely because they produce plausible numbers. A gross-error check catches the first easily. Catching the others depends on the crew re-establishing the context out loud rather than checking arithmetic.

What the cross-check actually is

The defence the whole system relies on is the independent cross-check, sometimes called a gross-error or reasonableness check. Before acting on a result, you deliberately ask whether the number is sensible: does this take-off speed look right for roughly this weight; is this thrust setting in the expected range for this runway and these conditions; does the trim match the loading you can see? You do not re-fly the full calculation — you hold an independent expectation and compare, so a gross error jumps out.

The distinction that makes it work

The cross-check is not a second calculation and it is not a proofread. It is the deliberate act of forming an expectation before looking at the answer. A pilot who knows roughly what a speed should be for roughly this weight on roughly this runway has a filter. A pilot who reads the output first and then assesses whether it seems reasonable has already been anchored by the number they are supposed to be testing.

Independence is the whole point

For the check to mean anything it has to be genuinely independent. Best practice in a two-crew flight deck is that each pilot enters the performance data independently and the two results are compared — not one pilot typing while the other watches the same screen and agrees. Two people making the same slip on the same device is not a cross-check; it is a shared error. And if the two results disagree, you do not average them or pick the friendlier one — you stop, find out why, and resolve it before you move.

Why shared-screen verification fails so reliably

Watching someone else type is a poor error-detection task and a worse one under time pressure. The observing pilot inherits the same source data, the same assumptions and the same reading of the situation, and gains only the opportunity to notice a keystroke. Everything upstream of the keystroke — the wrong runway, the stale wind, the assumed unit — passes through unexamined because both pilots share it. Independence is not about two sets of eyes. It is about two separate routes to the same answer.

What an inspector looks for

We would expect scrutiny to fall on whether independence is real. The telling questions are procedural: does the operator’s procedure require independent entry, or merely a check; what does the procedure say happens on a disagreement; and can crews describe the disagreement case without hesitating? An operator whose crews reach for averaging, or who resolve a mismatch by re-running one device, has a cross-check on paper and a shared error in practice.

The myth: “the app is more accurate than I am”

It is. That is not the point. The application’s arithmetic is beyond reproach and entirely irrelevant to the failure mode that actually threatens the operation. Accuracy protects you from a bad calculation; it does nothing whatsoever about a bad premise. The pilot’s contribution is not precision — it is judgement about whether the premise was right, and that is a contribution no amount of software accuracy replaces.

The app proposes; the crew, cross-checking, disposes. That is the relationship the type B classification assumes, and any operation that has quietly inverted it has removed a control without noticing.

Related reading

The classification that puts performance and mass-and-balance applications in this category is explained in type A vs type B EFB applications, and the obligation behind all of it in what EASA actually requires of an electronic flight bag. The physical discipline sits in mounting, stowage and critical phases, and the case where the device itself lets you down in when the EFB fails. The approval and administration framework is covered in our guide to EFB operational approval.

For the rule text itself, see Regulation (EU) 965/2012 on EUR-Lex or the EASA Easy Access Rules library. If you are the person who has to write and defend the cross-check procedure, the Raven EFB Administrator course is built for exactly that responsibility.

Frequently asked questions