Home/Workflows/Station information
Operations · Stations

One structure.
The whole airline.

Operational information sits in a structure the airline builds for itself, maintained by the departments that own it, and reaches people through the application and systems through the API.

Overview

Built once, read everywhere

Department events sit above the line and consumer events below it, from the shape of the structure through to the systems it feeds.

STATION INFORMATION · STRUCTURE TO CONSUMERS
STARTCOMPLETEDEPARTMENTSPEOPLE AND SYSTEMSStructureOwnershipContentPublicationIn the appOver the APIIn service

A structure you build

Sections, categories and content types follow the way the airline is organised, and they move when the organisation moves.

Owned where the knowledge sits

Each area is maintained by the department that holds it, and nothing reaches a crew until it has been through review.

Read by people and by systems

The same content serves the application on the device and the API your own systems call.

Step by step

From the structure to the systems it feeds

What the platform does with the airline’s own information, and what reaches people and systems while it happens.

DepartmentsPeople and systems
01Set up

The airline defines the shape

Sections, categories and content types are built to match the operation, covering flight, technical and ground operations, cabin crew and catering in one structure.

  • Hierarchy built to match the operation
  • Any part of the airline can hold a section
  • Reshaped as the organisation changes
STRUCTURE

The shape people navigate

02Ownership

Each area belongs to the people who know it

Editing rights follow the structure, so a department maintains its own area and the rest of the airline reads it from the same place.

  • Editing rights follow the structure
  • Departments maintain their own areas
  • Company directory accounts carry the permissions
OWNERSHIP

A name behind every area

03Continuous

Content is edited as a revision

An owner edits a revision alongside the published version, so work in progress never reaches a crew by accident. The revision timeline shows what changed and when.

  • Revisions edited alongside the version currently published
  • Attachments carried with the content they belong to
  • Revision timeline showing what changed and when
CONTENT

Current material on the device

04On change

Reviewed, then published

Content and structure changes queue for review. The reviewer sees exactly what is unpublished before releasing it, and publication moves the application and every connected system to the same content at once.

  • Unpublished data and attachment changes listed before release
  • Content and structure changes queued with a pending review count
  • Publication takes effect across the platform at once
PUBLICATION

The change appears where it is read

Departments see what is live

IN THE APP
05In use

It reaches people on the device

Staff read the current content in the application, on handhelds and desktops, and it stays with them on the device when a link is unavailable.

  • Current content available on handhelds and desktops
  • Held on the device without a connection
  • Synchronised when connectivity returns

Owners publish once for every channel

OVER THE API
06In use

Systems read the same content

A documented API serves the whole structure, so operators feed their own systems from it and build their own applications on top of it, including the channels their passengers use.

  • Documented API across the whole structure
  • Operator-built applications served from the same content
  • Operational and passenger facing systems fed from one place
RECORD
07Retained

The structure carries its own history

Editions are retained behind the current content, ready for an operational or authority review of what a station held at a given time.

  • Edition history retained per station
  • Superseded content preserved with the current structure
  • Available for audit
STATION INFO · CONSUMERS
APPLICATION
Handheld and desktop
CURRENT
REST API
Whole content structure
DOCUMENTED
OPERATOR APPS
Built on the same content
SERVED
OFFLINE
Held on the device
SYNCED
Interfaces

Your own applications, on the same content

A documented API serves the whole structure, so the platform sits behind the systems and applications your airline already runs.

  • Documented REST API across the whole structure
  • Operator-built applications served from the same content
  • Operational and passenger facing systems fed from one place
  • Station data export to flight planning systems

Put your whole airline on one structure

Talk to our engineers about the structure your operation needs, the departments that would own it, and the systems that would read from it.