Technology
Target architecture
Meridian is a cloud-based passenger experience platform designed to operate across existing private aviation connectivity infrastructure. Starlink, Gogo, Viasat and other providers deliver the connection — Meridian turns that connection into an intelligent, destination-aware experience.
Where it lives
The core application, content engine, destination logic, brand inventory, analytics, campaign management and operator controls live outside the aircraft in secure cloud infrastructure. The aircraft does not carry the Meridian application stack — the onboard network is the access point through which passengers reach it.
The aircraft path
Satellite / air-to-ground network
Provider constellation or ground network
Aircraft connectivity system
Terminal · antenna · modem
Cabin Wi-Fi network
Router · access points · captive portal
Passenger device
Own browser — nothing installed
Encrypted passenger session
Requests up, experience down — carried over the aircraft path above to the Meridian cloud below.
The Meridian cloud platform
Application & experience delivery
The responsive passenger web experience
Destination engine
Route, timing and season resolved to context
Campaign & content engine
Brand inventory · operator rules · ranking
Analytics · dashboards
Aggregate engagement, never identity
Feeding the destination engine
Operator & aviation data — scheduling, dispatch, trip feeds and aviation data APIs — enters as trip and destination context. Dashed path: data, not passenger traffic.
Target architecture · integration depth depends on provider and operator configuration
The aircraft provides access. The cloud provides intelligence.
How it deploys
Five layers in the cloud, one already on the aircraft. Who controls the cabin network decides the path; software comes first and hardware only where it earns its place; what survives a dropped link is designed, not hoped for.
What Meridian actually is.
Passenger experience
Experience engine
Data + integrations
Meridian platform
Cloud infrastructure
Aircraft access layer
How Meridian knows the destination
Passengers should not have to tell the system where they are flying when that information can be obtained programmatically from the operator's own systems and commercial aviation data.
Meridian does not require access to safety-critical aircraft systems to function.
The initial architecture favours commercially available trip, scheduling and aviation-data sources over direct avionics integration — implementation stays software-led, not aircraft-modification-led.
Every source on the left is a system the operator already runs. The engine reads the trip, the tail, the departure, the arrival and the timing — nothing about who is on board — and resolves them into where this flight is going and when, so the cabin shows what is relevant there.
The mechanics
Beneath the passenger experience: a stable per-aircraft address, a per-trip link everywhere else, and a resolution rule that never guesses.
Resolution, step by step
Wrong-destination content is treated as a trust failure; no Member identity is required to resolve any of it.
The connectivity providers
The providers below supply the communications infrastructure and bandwidth. Meridian is the software and passenger-experience layer above it — the relationship is architectural, not competitive.
Role
Connectivity infrastructure.
Meridian relationship
Meridian operates over the connection rather than replacing it.
Potential deeper integration
Portal behaviour, APIs, aircraft context, or provider-level deployment would depend on technical access and commercial arrangements.
Role
Private-aviation connectivity infrastructure.
Meridian relationship
Meridian sits above the aircraft network.
Potential deeper integration
Router, portal, or platform access may support more native deployment.
Role
Satellite connectivity infrastructure.
Meridian relationship
Meridian uses the connection rather than competing with the connectivity provider.
Potential deeper integration
Portal, API, or platform integration may enable a more seamless passenger experience.
Other providers
Meridian is designed as a connectivity-agnostic platform. The architectural objective is not to depend on a single provider — that keeps operator flexibility intact and keeps Meridian from becoming structurally tied to one hardware ecosystem.
Providers are named here in their architectural role, not as Meridian partners. No integration, API access or commercial relationship with any provider exists today.
Questions for the room
For the conversation with a connectivity provider, a router vendor, or an aviation IT team.
Can the passenger captive portal or landing page be customised?
Can an external cloud-hosted web application be used as part of the Wi-Fi onboarding experience?
Can the router redirect or deep-link passengers to an external URL?
Are portal-configuration APIs available?
Can aircraft tail number or network identity be exposed securely to an approved application?
Can trip or destination context be passed into the passenger experience?
Are there APIs for connectivity state, aircraft identity, or session context?
Can selected web content be cached locally onboard?
Does implementation require provider approval?
Would any integration require certification, STC changes, or aircraft modification?
What functionality is controlled by the operator versus the connectivity provider?
What functionality can be configured fleet-wide remotely?
These questions determine integration depth. They do not determine whether Meridian can exist — the baseline product remains a cloud software platform.
Security + privacy
Meridian is architected around contextual relevance rather than invasive tracking.
Contextual inputs — none of them identity
Destination intelligence does not require surveillance.
Principles
Passenger identity enters the system only where deliberately implemented and consented to — and never as a requirement for the destination experience itself.
The activation path
The only point at which a passenger becomes identifiable is the moment they ask for something. Everything before it runs on flight context, and everything measured afterwards is aggregated.
Origin, destination, date, season. No passenger identity.
Deterministic rules select eligible collections and formats.
The existing captive portal, in the passenger's own browser.
The passenger browses, or does not. Nothing is required.
The passenger asks for something. This is the only point data is created.
The request is routed to the right partner in the arrival market.
A dealer, broker, concierge or host acts on it.
Reported back for attribution. Aggregate, not individual.
Operator implementation flow
The first working session with an operator is a survey of what already exists — not a proposal to change it.
What we need from an operator
Connectivity
Fleet
Trip data
Passenger experience
IT + security
Commercial
Deployment status
Capability-level precision: the demonstration platform is live today; live portal delivery and operator controls in production arrive with a pilot; multi-operator operations arrive with scale.
What exists today: the passenger experience, route resolution and dashboards run end to end as a live interactive demonstration on seeded data.
A limited aircraft group on two or three corridors, with live portal delivery, operator controls in production and real engagement measurement replacing the assumptions.
Centralised content operations, multi-operator controls, multi-market fulfilment routing and campaign management across corridors.
The simple version
Starlink, Gogo and Viasat connect the aircraft.
The aircraft network connects the passenger.
Meridian connects the passenger to the world around their destination.
Meridian does not need to rebuild the aircraft. It needs to intelligently use the infrastructure already there.
Meridian introduces no hardware and no avionics change. What it costs an operator in integration effort varies by connectivity configuration, and the only honest way to find out is on a small group of aircraft.
