Maintenance intelligence Riyadh · Built for airlines and MROs Guided preview · synthetic data Rev 2026.09
The intelligence layer for aviation maintenance
Every finding should make the next decision better.
Aviation maintenance creates valuable knowledge every day—in unexpected findings, engineering decisions and the work that follows.
We’re building AviOS to turn that knowledge into operational intelligence: connecting evidence, revealing dependencies and comparing recovery paths, so maintenance teams can anticipate more, respond with clarity and learn from every outcome.
Built for the complexity of MRO. Designed around human expertise.
Records · connected, provenance keptDependencies · shown, never inferredRecovery · assumptions printedAuthority · stays human
Our ambition
Built around human expertise
Our ambition: a maintenance operation that learns.
From the first observation to the final outcome, our goal is to make every finding contribute to a more informed operation.
AviOS is being developed to bring maintenance records, technical knowledge and operational constraints into one accountable decision environment—where teams can understand what happened, assess what comes next and preserve what they learn.
The problem
01 / 08 · Stated the way operators feel it
One unexpected finding. A new set of dependencies.
Finishing the task is only part of the work. A missing part, an engineering disposition, an independent inspection or a test can still hold up the next activity.
An unexpected finding can change the scope. Teams need the finding, its evidence and the affected work together to understand what needs to happen next.
Make the next action clear. Understand what threatens a milestone, who owns the blocker and which evidence is still needed for review.
01
What is blocked? Bring the finding and the affected records into view.
Context
02
Who owns the next action? Keep the recorded blocker, owner and milestone together.
Coordination
03
What supports the decision? Review the evidence, assumptions and remaining gaps.
Accountability
From finding to release
02 / 08 · Guided scenario
One finding. Everything it touches, in view.
Follow a non-routine finding through the platform: what it blocks, what it costs to recover, who decides, and what evidence closes it. Each step says whether it is in the platform today, in development, or on the roadmap.
Guided scenarioSynthetic dataIllustrative interface, not a live screenNo operational system is actuated
Corrosion at hydraulic line clamp, LH wheel well, ATA 29
Recorded by the signed-in technician against the executing task card, with photographs attached. The execution is paused at that step; the pause and its reason are part of the custody chain.
Aircraft
HZ-AVO · synthetic
Recorded by
Mechanic · authenticated session
Severity
Per customer policy · awaiting engineer
Evidence
2 photographs · step reference
What is real here. Task cards, executions with per-step actors, pause and resume, and independent inspection are in the deployed preview. Recording a finding on a maintenance visit is part of the first Control Tower slice, which is in development.
Dependencies · HZ-AVO · outstanding onlyIn the platform today
FindingFND-2026-0417
Task cardTC 29-11-04 · paused
Work orderWO-2026-3312 · in work
ComponentClamp assy · S/N 8841 · fitted
DeferralMEL 29-31-02 · Cat C · 6 days left
MilestoneReturn to service · planned
Every line names its source column. WorkOrder.aircraftId · TaskCard.workOrderId · ComponentInstallation.position · MelItem.aircraftId. Solid lines are foreign keys the database enforces; dashed lines are references a person typed, shown with less confidence.
Nothing is inferred. The dependency view draws only relationships stored between records. It does not guess from a shared ATA chapter, a date or a description, and it lists on screen what it excludes: people, tooling, hangar slots and the flight schedule.
Control Tower · Visit HZ-AVO C-check · blockersIn development · CT-01
Blocker · entered by plannerEngineering disposition required
Repair or replace? Task card 29-11-04 cannot close until an engineer dispositions the finding.
Owner: engineering. Target: today 16:00.
Blocker · entered by materialsPart not in stock
Replacement clamp assembly on order; supplier lead time entered as 2 days.
Owner: materials. The hydraulic pressure test cannot start until the repair is complete.
Milestone at risk
Return to service · recorded as at risk
Critical path
Not calculated · by design
Downstream
Pressure test · inspection · release
Recorded, not computed. In the first Control Tower slice every blocker, owner and milestone state is entered by a person and opens the underlying record; there are no durations, projected end dates or calculated critical paths. Engineering disposition, scope and material changes and evidence-gated closure are the next slice, not yet built.
Recovery path comparison over deferrals, directives and fitted components
Path
Clears
Hours
Cost (model)
Only this path does
MINIMUM
Expired and blocking items only
18 h
USD 110k
Least ground time; MEL 29-31-02 leaves the hangar with 6 days left
CLEAR ALL
Every open deferral while the aircraft is down
26 h
USD 159k
Avoids a second grounding for 29-31-02
Assumptions printed with the result. AOG hour USD 6,000 · labour hour USD 120 · MEL rectification 8 h · directive 12 h · return-to-service 2 h. A planning model, not contracted rates. Scope: deferrals, directives and fitted components. Excluded: open work orders, scheduled maintenance, parts availability, crew and hangar capacity.
Ranks options; does not price a recovery. The comparison is computed by comparing step sets, not totals. It is not an optimiser and not a release decision. A tail whose deferrals have all expired correctly shows one path.
My work · role queues · HZ-AVOIn the platform today
Engineer
Disposition finding FND-2026-0417
Materials
Receive clamp assy · issue to WO-2026-3312
Mechanic
Resume TC 29-11-04 after disposition
Inspector
Required inspection on repair · different person
Decision recordEngineering disposition
Replace clamp, blend and treat local corrosion per approved data; pressure test before close.
The disposition is the engineer's, recorded under their authenticated session in the system where they are authorised to give it. AviOS shows it, links it and never issues it.
Roles are enforced on the server. Administrator, engineer, mechanic, inspector and viewer each see the records in their custody and the next permitted action. Safety-critical actions are refused with the reason and its regulatory basis shown. A formal disposition object on a visit is part of the next Control Tower slice.
Execution EXE-2026-0611 · custody chainIn the platform today
CustodyWho did what, when
08:12 · step 4 paused · mechanic · finding FND-2026-0417 raised 15:40 · disposition recorded · engineer next day 10:05 · step 4 resumed · mechanic · replacement fitted, S/N 9102 11:30 · pressure test result recorded · mechanic 12:10 · required inspection · inspector, a different person · pass 12:12 · Execution complete · not a release to service
Certificate of release
Cannot be issued while an overdue deferral, open directive or incomplete work order stands
Signature
Ed25519 · verified on every read
Audit
Certificate actions hash-chained
Completion is not release. The certificate of release to service is a separate, gated act by certifying staff; the certifier must differ from the performer. Where an older row has no recorded actor, the screen says so rather than inventing one.
Reliability · ATA 29 · recorded eventsPartly today · loop is roadmap
Recorded today
Removal events, dispatch reliability, rates per 1,000 FH, MTBUR
Trend
Reported only when the minimum history exists; otherwise "insufficient history"
Actual vs assumption
Roadmap
Honest about the loop. Recorded events already feed the reliability views, which refuse to draw a trend on too little history. Feeding actual recovery hours and outcomes back into the planning assumptions is on the roadmap, and AviOS does not ship a validated prognostic model.
Why it matters. A missing part, an engineering disposition, an inspection or a test can block several activities at once. Teams need to see what is blocked, why, who owns the next action and which milestone is affected, with the options and their assumptions visible and the authority still attached to the decision.
The platform
03 / 08 · What you can see and do today
Grouped by the decisions your people make.
Explore the guided preview on synthetic data. Follow aircraft records, maintenance work and components, inspect their recorded relationships, and compare scoped recovery options. Development and roadmap items are identified below.
In the deployed previewIn developmentRoadmap
01Records and custody
Know the state of the aircraft and the work
An operator-scoped register of aircraft, work orders, technical-log entries, task cards, executions, serialized components and shop visits, with recorded actions attributed to the signed-in account.
Work orders with controlled status changes, completion permissions and independent inspection
Technical-log defects and rectifications recorded against the signed-in account
Task cards authored, reviewed and approved by separate accounts
In development: Deferral from the technical-log screen
02Airworthiness controls
See the conditions that need attention
Review checks for deferrals, directives, component installation and release readiness, with reasons shown when an action is blocked.
Deferrals carry category intervals; expiry is derived, not read from a flag
Directives tracked per aircraft, compliance recorded against the signed-in engineer
Component installation refused when life-expired, position occupied or wrong operator
Certificate of release blocked while an overdue deferral, open directive or incomplete work order stands
03Dependencies and recovery
Explore dependencies and recovery assumptions
Navigate stored relationships between maintenance records and compare recovery paths within an explicitly limited planning model.
Dependency view drawn only from stored relationships; excluded scope listed on screen
Recovery paths compared over deferrals, directives and fitted components, assumptions printed
In development: Check and Finding Control Tower: blockers, findings and milestones on a visit
Roadmap: Disposition, scope and material change, evidence-gated closure
04Shop lifecycle
Follow a component through the shop
Engine and component shop visits move through inducted, teardown, repair, test and release stages, with workscope items, findings and test-cell runs recorded against the signed-in account.
Stage changes controlled by the user’s role
Four-tab evidence workspace: workscope, modules, findings, test runs
In development: Creating and inducting a new visit from the interface
05Reliability
Trends from recorded events, or an honest blank
Dispatch reliability, removal rates per 1,000 flight hours and MTBUR computed from recorded events, with control-limit alert status.
Reports "insufficient history" rather than a trend below the minimum periods
Engine test-cell trend to limit from recorded runs
Roadmap: Validated prognostics and remaining-useful-life estimates
06Roles and tenancy
Keep access aligned with responsibility
Five roles, administrator, engineer, mechanic, inspector and viewer, with safety-critical actions gated on the server and every record scoped to its operator.
Cross-operator lookups refused with the reason shown
Certificates Ed25519-signed and re-verified on every read
Certificate actions written to a hash-chained audit log
In development: Database-level row security, written and awaiting activation
The product
04 / 08 · Preproduction build
Explore the working preview.
The preview uses synthetic maintenance records. A technical briefing can walk through the implemented workflows, their evidence and their limits. Live vendor connectivity and production acceptance are still to be established.
Screens behind sign-in are shown live in a briefing, on synthetic data, with the platform's own limits printed on them. We do not publish interior screenshots on this page until each one is captured from the current release.
What the preview shows
Fleet, work orders, technical log, task cards and executions with custody chains
Deferrals, directives, serialized components and shop visits
The dependency view and the scoped recovery comparison
The copilot with its evidence labels
Refusals rendered verbatim, with regulatory basis
What it does not claim
No vendor system connected; no live telemetry
No certificate represents real maintenance
No regulatory approval sought or granted
No validated prognostic or remaining-useful-life model
No mobile technician app; the web interface is responsive
The copilot
05 / 08 · Scripted example
Ask the operational question. Inspect the evidence.
The copilot answers by calling AviOS's own airworthiness, planning, reliability and rotable functions over the operator's records, then labels each answer by whether records were consulted. It is advisory. It authorises nothing.
Copilot · scripted example · synthetic dataBacked by records
What it does
Calls eleven platform functions, including airworthiness status, fleet risk, due lists, read-only what-ifs, reliability and the rotable pool
Shows evidence status, including partial results and when no records were consulted
Shows the record references behind each function call
Provides trace identifiers for reviewing exchanges
Where it stops
Cannot issue, defer, close, approve or release anything
References are per function call, not per sentence
No document or manual retrieval yet; no recovery-plan tool yet
Adversarial evaluation of unsupported questions is planned, not complete
Integration
06 / 08 · Above your systems of record
Build on your systems. Keep the source in view.
AviOS is designed as a read-first intelligence layer above the maintenance and engineering system, electronic technical log and parts system an operator already runs. The integration approach preserves source identifiers, revisions and timestamps as data is mapped into a common fleet model.
Systems you already run
M&E / maintenance system of record
Electronic technical log
Parts and inventory
Health-monitoring and ACARS-style feeds
AviOS
Canonical fleet model · provenance on every record · deterministic airworthiness logic · tenant-scoped ingestion path, tested against synthetic feeds
What your people get
Linked records with the source named
Dependencies drawn from stored relationships
Recovery options with assumptions printed
Answers labelled by their evidence
Current state, stated plainly. No vendor system is connected in the current environment. The ingestion path accepts M&E-style and ACARS-style feed records and is tested against synthetic feeds. Named vendor adapters are roadmap and go live read-only, after the gates below.
Gate 01
Source of record agreed
Which system owns which fact, and what AviOS may never originate.
Gate 02
Vendor entitlement
Licence, modules, interface scope and data-use permission confirmed by the operator and vendor.
Gate 03
Interface contract
Schemas, identities, timestamps and change semantics documented and versioned.
Gate 04
Security and residency
Review, credentials, tenancy and retention agreed before any data moves.
Gate 05
Reconciled shadow run
Historical bootstrap and a read-only shadow period with variance measured, before anyone relies on it.
Trust and authority
07 / 08 · Built for a certifying industry
The platform prepares. Your people decide.
Aviation runs on accountable signatures. AviOS helps assemble records and applies defined checks to support review. Authorised people remain responsible for engineering decisions and release.
Deterministic where it matters
Rules, not model output
Deferral intervals, directive applicability, component life limits and release gating run on versioned, testable logic. The copilot explains and retrieves; it does not decide.
Attributed and signed
Evidence that stands up
Every mutation is attributed to an authenticated account. Certificates of release are Ed25519-signed and re-verified on every read, and certificate actions are written to a hash-chained audit log.
Accountable by design
No automated release
No automated action authorises a release, defers a defect, closes a finding or overrides an engineering decision. Refusals are shown verbatim with their regulatory basis.
Decision logic references EASA Part-145 and Part-M and the corresponding FAA rules. AviOS is not certified or approved by any authority, holds no SOC 2 or ISO attestation, and is available as a guided preproduction preview. Production acceptance and live integrations remain incomplete.
Operator-scoped data; cross-operator lookups refused with the reason shown
Data freshness matters: distinguish screen refresh time from the age of source information
"Not assessed" shown where a metric has not been assessed, never a number
For airlines and MROs
08 / 08 · What a credible evaluation involves
Start with a workflow. Measure the difference.
Agree a baseline, select a maintenance workflow and define success together. These are proposed pilot objectives, not measured customer results.
Airlines and operators
Fewer surprises between the finding and the release
A continuously linked picture of open work, deferral exposure and directive status per aircraft, with what is blocked and who owns it in the same view as the records themselves.
Grounded aircraft: recovery options compared with assumptions visible
Deferral expiry derived from the interval, not a flag someone set
Copilot answers labelled by their evidence
MRO organisations
Turn the hangar with the evidence already assembled
Task cards, executions, inspections and shop visits with per-step custody, so certifying staff review instead of collate and every refusal is explained.
Independent inspection enforced; completion shown as distinct from release
Shop visits with workscope, findings, modules and test runs
Control Tower view of blockers and milestones on a visit, in development
Pilot objectives we propose to measure
Time to assemble the context pack for a non-routine finding: records, dependencies, evidence and owner.
Time to identify the open blocker on a visit, and who owns the next action.
Completeness of release-readiness evidence at final review, and the number of gaps found late.
Reconciliation variance between AviOS and the system of record during a read-only shadow run.
User acceptance by role: planner, engineer, technician, inspector and certifying staff.
Sequence: guided preview on synthetic data → design-partner workshop on your workflows → read-only adapter against an extract from your system of record → reconciled shadow run → pilot objectives measured and reported.
The film
An illustrated scenario · 3:38
Disruption rarely begins with chaos. It begins with one signal.
The film walks through the operating model: a signal becomes operational context with source evidence in view, recovery paths are placed side by side with their consequences visible, and an accountable person records the decision, its owner and its rationale.
Interfaces in the film are simulated and labelled as such; they are not screens of the shipped product. Airline imagery is supplied film material used as industry context; no customer relationship or endorsement is implied. The film speaks of recommendations and enterprise-wide coordination as a direction; today's platform compares options with assumptions printed and does not recommend, approve or actuate anything.
Company
The ARK AI Company · Riyadh
Aviation people, building aviation software.
AviOS is built by The ARK AI Company, based in Riyadh. We are building maintenance intelligence for the people responsible for aircraft, engineering work and operational readiness.
AviOS is building the operational intelligence layer for aviation maintenance—connecting non-routine findings, engineering knowledge and recovery decisions to help every maintenance event improve the next.
How we build
Start with a real maintenance decision. Keep its source records and assumptions visible. Test the workflow with the people who will use it.
Evidence over claims
Determinism where it matters
Authority stays human
Your data is your asset
Source relationships visible
Limits printed on screen
Discuss a pilot
See AviOS on your fleet's terms.
A working walkthrough of the preview on synthetic data: records, dependencies, the recovery comparison and the copilot, with the platform's limits shown. Bring a workflow you want to evaluate and the questions your team needs answered.
