ELORA
Rev 2 · Aug 2026 · Configuration & compliance

What configuration is this aircraft in — and can you prove it?

ELORA is a configuration and compliance layer for airline engineering and CAMO teams. It reads the systems you already run, answers in plain language, and returns a source you can open behind every statement.

ELORA workspace Evidence record
>Is SB 34-1234 embodied on MSN 4172?

Embodied at Rev 3 under EO 21-0456, 14 Mar 2024.

One aircraft in the fleet remains at Rev 2.

Sources · 3 · each one openable

Closed 14 Mar 2024 · station KEF · task card 34-11-00-720 · signed off against EO 21-0456.
Effectivity block lists MSN 4172. Rev 3 supersedes Rev 2 — kit part number changed at Rev 3.
Engineering order raised against SB Rev 3, approved 02 Feb 2024, applicable to 6 of 7 tails.
Illustrative interface · values are examples, not customer data

The problem

An engineer opens ten windows to answer one question.

The question is simple. Which configuration standard is this aircraft in, is that modification embodied, and where is the evidence.

The answer is not in one place. It is spread across the maintenance system, the OEM portal, modification records, manuals and drawings, scanned shop reports and a shared drive — none of which talk to each other.

So it gets rebuilt by hand. Every aircraft, every time, leaving no reusable trace behind it.

M&E / records system OEM portals Modification records Manuals & drawings Shop reports (PDF) Shared & cloud drives
5–6systems queried
0reusable trace

How it works

A layer on top of the systems you already own.

Nothing is replaced, nothing is migrated, and the source of truth does not move.

STEP 01

Connect

Read-only connectors into the maintenance system, modification records, OEM data and document stores.

STEP 02

Ask

Ask in plain language. No query language, no new database to populate, no change to your records.

STEP 03

Assemble

The answer comes back as a structured deliverable, in the format the process and the regulator expect.

STEP 04

Prove

Every statement is anchored to the document, revision and page it came from. Nothing is asserted that cannot be opened.

What you get back

An evidence pack, not a chat answer.

Configuration baseline and delta, per tail

What is fitted, under which modification, at which revision — and what differs from the fleet standard.

Applicability checked against the aircraft

Service bulletins, airworthiness directives and modifications assessed against the actual configuration, not the fleet average.

Reliability and removal analysis

Removals, shop findings and OEM service data assembled into one analysis instead of a week of manual retrieval.

A record that survives an audit

Structured report, audit trail, and a retrievable citation behind every line — the same answer, reproducible six months later.

What operators told us

Six discovery interviews across four airlines and a lessor.

We publish what was disproved alongside what was confirmed. Interviewees are not named.

Confirmed

Fragmentation and manual re-keying was named as the single biggest problem at VP Technical Operations level — volunteered, not prompted.

An avionics engineer at a major European carrier listed more than seven disconnected systems and estimated a connected assistant would cut reliability analysis by more than half.

Disproved

Electrical load analysis is not the pain. It surfaced as a downstream administrative step, never as a bottleneck. That finding is why this page changed.

Lessors are not the buyer. Asked directly about configuration, one leasing company answered that it is an airline problem.

Still open

Willingness to pay is unproven. No price has been tested with a budget holder.

OEM data licensing for third-party ingestion is unverified and is a gating risk we are clearing before we build further.

We also built a CS-25 electrical load analysis tool, and it works. It is how we learned that the calculation was never the hard part — finding and proving the configuration it runs against is.

Start here

A paid pilot on one real question.

Six to eight weeks, fixed fee. One configuration or compliance question your team actually has, answered end to end with full traceability — timed the old way and the new way, with your engineers as the judge.

What we need

One question, one owner

A named engineering or fleet budget holder, and a question that costs you real hours today.

What we need

Read-only access

Scoped, read-only, under your data-handling terms. Nothing is written back to your records.

What you get

A measured baseline

The finished evidence pack, plus a before-and-after time measurement you can take to a budget.

Data handling

Your technical data stays yours.

Wiring manuals, load lists, modification records and fleet data are treated as confidential by default. Access is read-only and scoped to the pilot question. We do not write to your records and we do not train on your data.

We work to an ISO/IEC 27001 path, GDPR obligations for any personal data, and whatever NDA and residency terms you impose. If your terms and our architecture cannot be reconciled, we will say so before the pilot rather than after it.

Who we are

Avionics engineers at an airline, building the thing we needed.

Óskar Ásgeirsson

Co-founder

B.Sc. Mechanical Engineering, Reykjavík University. M.Sc. Aeronautical Engineering, Linköping University. Eight years across aircraft systems, design and continued airworthiness.

Sigurður Evert Ármannsson

Co-founder

B.Eng. Aerospace Engineering, University of Liverpool. Five years in continuing airworthiness management, and author of the analysis tooling behind ELORA.

ELORA is pre-revenue and pre-product. What exists today is the domain knowledge, the working analysis tooling, and six discovery interviews. What we are looking for is the first operator willing to put one real question in front of it.

Contact

Tell us the question that costs you a week.

info@elora.is

Reykjavík, Iceland. We work with operators, CAMO and design organisations across Europe and North America.