Five systems, one aircraft

AerSynx was written inside a continuing airworthiness organisation, not next to one. It did not begin with a product idea. We bought the tools first: one for maintenance, one for stock, spreadsheets for everything the two of them left out.

None of them was wrong on its own. Each did the job it was sold for. Together they meant the same aircraft had four answers, and no way to tell which one an auditor would accept.

This is the story of what we have been doing since, and of the one decision underneath every module we have added to it.

#Five desks, five systems, one aircraft

A working day in an operation looks like this. The CAMO desk tracks directives, life limits and the maintenance programme. The hangar floor opens work orders, books labour, closes them. The supply counter holds stock, quotations and purchase orders. The lease desk prepares deliveries and redeliveries. The quality office runs the audit trail and screens the organisations you do business with.

All five work on the same aircraft. And all five have usually been handed their own system, their own spreadsheet and their own version of it.

Nobody is lying. Everyone is reading the truth on their own screen. The problem is that those truths do not agree.

The quiet part is that nothing ever breaks. No system fails. The numbers add up inside each copy. What is lost is the ability to say which copy is the record — and that was the only property that mattered.

#The real cost is not the errors. It is the re-typing.

The visible cost of this arrangement is assumed to be mistakes — a wrong figure quoted to a lessor, a date missed on a review. It is not.

The invisible and far larger cost is that people spend their week moving a number from one screen to another.

Aviation runs on people who are good at judgement. The engineer deciding whether a finding is acceptable. The planner deciding what can wait and what cannot. The buyer deciding which supplier to trust. The records officer who knows which document proves what when a review starts.

Very little of their week goes on any of that. The rest goes on copying, checking, reconciling and chasing.

That was reasonable while systems could not talk to each other. Twenty years ago there was no alternative. Today there is — which makes spending man-hours on transcription a choice rather than a constraint.

#Why integration is not the answer

The standard response to this problem is integration: let the two systems pass data to each other.

Integration works, but it concedes something at the outset — that there is something to pass. The data still lives in two places, and the bridge between them needs maintaining. When the bridge breaks, nobody notices, because both ends continue to look internally consistent.

What we are saying is simpler. There is nothing to pass, because the data is already there. The aircraft supply sees and the aircraft CAMO sees are not two records that agree. They are one record.

#Our mission

Put the whole operation on one aircraft record. Directives and life limits in CAMO. Work orders and labour in Part-145. Stock, quotations and purchase orders in supply. Deliveries and redeliveries in lease. Audit trail and partner screening in quality. One record underneath all of them.

Today that means 7 working areas and 53 modules. The count is not the point. The point is that whichever one you open, you are looking at the same aircraft.

#Our vision

Nobody re-types what another desk has already entered. In practice that looks like this:

• A life limit approaching in CAMO opens the demand in supply on its own
• An hour booked against a work order in the hangar becomes the labour line on the invoice
• A new directive is pulled from the authority every night and matched to the fleet by type and variant — a MAX does not inherit an NG's directive, and nobody has to read a bulletin for the directive to find its aircraft
• Every organisation you do business with is screened against sanctions lists every night, and the people who need to know are told
• The part fitted to the aircraft and the paperwork that proves it sit on one chain
• Who changed a next-due date, and when, is not a question you ask around the office

Stated in one sentence: the engineer does engineering, the buyer does buying, and neither spends the afternoon reconciling the other's spreadsheet.

The record stays whole — not because somebody guarded it, but because nobody had to rebuild it.

#Writing the rule into the code

The most common mistake in aviation software is leaving the rule to training. The screen is made flexible, the rule is written in a manual, and enforcing it depends on somebody remembering.

We do the opposite, and it is worth being specific about what that means, because "enforced by the system" is a phrase every vendor uses. A few examples.

A [life limit](/glossary#llp) is absolute. An overhaul does not reset it, a shop visit does not reset it, a swap does not reset it. There is one formula, and all five paths through the system call it — because a second formula is a second answer.

[Overdue is strictly before today](/blog/an-overdue-task-is-not-a-late-one). A task due today is not overdue; it is due. The difference is one comparison operator and one aircraft on the ground.

A record is [evidence](/blog/what-counts-as-evidence) only if it resolves to the same aircraft. Attaching a document is not enough: it has to have been read, summarised, linked to an accepted event type, and that event has to resolve to the aircraft in question. If one of the four is missing the system refuses the closure and names which one.

[Who can see what is an axis, not a preference](/blog/who-can-see-whose-money). Where a customer runs several legal entities, which company owns the money and the part is written on the record itself. Every action is named individually, and each can be granted or withheld per title and per person.

These live in the code rather than in a manual — which is also why they are tested.

#How we get there: depth before breadth

In a regulated environment a module that is nearly right is a module that is wrong. A life limit cannot be approximate. An overdue cannot start roughly. Evidence cannot be probably correct.

So each area is finished to the standard a reviewer would accept before the next one opens.

There is a price and we do not hide it: we move slowly. That is the answer to "why is that module still missing". The alternative would be ten areas half-built — and in aviation a half-built system is worse than no system, because it persuades people to rely on it.

#What we do not claim

A company saying what it cannot do is heard less often than one saying what it can. We publish both.

There is no certification yet. Some enforcement layers are still rolling out. A disabled login does not kill a token already in hand. All of it is written plainly on our security page.

We do not claim anything we have not measured. That rule costs us marketing copy regularly and we keep it anyway, because a claim an auditor can disprove is worse than no claim at all.

#Where we are

The company is registered in Estonia. Engineering and support sit in Antalya, inside the timezone most of the operators we build for already work in.

And we still work the same way: every module starts as a problem somebody had that week. Nothing here was designed in a workshop.