Removal reasons and findings

Two referentials, one idea: making countable what was only ever narrated.

Until now, the reason for a removal and the result of an operation lived in free text — “removed for failure”, “nothing to report”, “fastener #3 to replace”. That is irreplaceable for understanding an intervention. But text cannot be counted: no unscheduled-removal rate can be extracted from a sentence, and no in-service feedback can be exported to a manufacturer.

The code does not replace the note. It adds a countable dimension alongside it: the code makes the fact countable, the note makes it understandable.

Two different questions

They add up, they do not replace each other. A component can be removed on a scheduled interval (reason) and be found corroded (finding).

The pair that does all the work

This is the example to remember, because it explains why two vocabularies are needed rather than one:

A crew reports an anomaly. The component is removed with the reason “Reported failure”. In the shop nothing is reproduced: the finding is “Failure not confirmed”.

The result:

• the removal counts as unscheduled — it did ground the aircraft and consume a spare;
• the component itself does not count as failed — nothing was wrong with it.

A reason alone cannot say that. And conflating the two durably distorts reliability rates in the most expensive direction: healthy units get replaced.

Managing removal reasons

Screen Administration › Removal reasons (/admin/removal-reasons). Each reason carries:

• a technical code, frozen after creation (e.g. panne_constatee);
• a label shown throughout the application, translatable;
• a family: scheduled, failure, damage, end of life, modification, opportunity, administrative;
• a “counts as a failure” flag;
• a display order and a status.

The “counts as a failure” flag is NOT derived from the family

This is deliberate, and it is the setting that deserves the most attention. Accidental damage is a failure of the component; an opportunity removal is not, even though both are unscheduled removals. Exactly where the line falls is an operator’s decision, not a mechanical consequence — hence the independent flag.

The reserved non_renseigne code

It exists for one reason only: historical data migration. Every removal predating the coded vocabulary lacks a reason, and no automatic interpretation was made of their notes — guessing a reason from free text would amount to fabricating reliability data.

This code is not offered when recording a new removal. It means “we do not know”, which a technician never deliberately chooses.

Managing findings

Screen Administration › Findings (/admin/finding-codes). Same fields, plus an optional ATA chapter.

The chapter moves the finding to the top of the list for the item being worked on, without ever excluding the others: you regularly find something other than what you were looking for, and a hard filter would stop the technician from saying so.

A finding without a failure belongs there

Uncheck “indicates a failure” for “Nothing to report” and “Failure not confirmed”. Otherwise an intervention where nothing was found would count as a failure.

And a recorded “nothing to report” is not an empty box: it distinguishes a check performed with no result from a check not recorded. That is reliability information in its own right.

Day-to-day recording

At removal — the dialog offers the reason right after the date, before the component’s new condition: the reason explains the removal, the condition is only its consequence. Free-text notes remain available below.

When closing an operation — the finding is offered in the confirmation window, next to “completed by”. That is the moment of the gesture: asking someone to reopen an edit dialog afterwards to code what they found guarantees nobody will. A correction remains possible later by editing the operation.

In both cases, only active codes are offered. A retired code stays readable on past records.

Retire rather than delete

Deleting a reason or a finding is refused as soon as a record refers to it: erasing the reason of a past removal would destroy reliability data.

To take a code out of service, set its status to “retired”: it disappears from the entry selectors and stays readable in history.

What this enables

These two vocabularies are the first lock on in-service feedback. The underlying data already existed — meter readings at installation and removal, timestamped work orders, consumption per operation — but stayed unusable for lack of codes.

Once coded, reporting back to a manufacturer or a technical authority becomes a question of format, no longer a question of data.