Aviation · Operational Software · A Webonautics Product
Digital Voyage Report System — Jet Airways · 2012–2019
An operational system built to reconcile real-world aviation data across aircraft, airports, and external systems.
Enabling faster, more accurate maintenance decisions across fleet operations.
An electronic flight log system replacing paper-based Voyage Reports across four aircraft types
Interfacing with four live Jet Airways operational systems, synchronising flight data across engineering, rostering, and finance through event-driven, scheduled updates.
Seven years of continuous operational use. IP retained by Webonautics.
ATR72
ATR72-500
Regional turboprop. Thrust: 2,750 SHP. MZFW: 20,300 kg. Full form validation suite.
A330
Airbus A330-243
Wide-body long-haul. Thrust: 71.1K. MZFW: 170,000 kg. Tank capacity: 139,090 L.
B737
Boeing 737-700
Narrow-body. Thrust: 22K. MZFW: 54,657 kg. Tank capacity: 26,025 L.
B777
Boeing 777-300ER
Heavy wide-body. Thrust: 115K. MZFW: 237,682 kg. Tank capacity: 181,270 L.
In aviation, the Techlog — or Voyage Report — is the authoritative record of every flight, used across commercial and military operations. Every departure, every fuel load, every crew detail, every technical observation: all captured on paper forms that then needed to be manually transcribed into multiple downstream systems for engineering, rostering, and finance.
Techlog is the electronic version of that paper-based system. It is not a simple digitisation — it is a centralised web application that translates the entire Techlog process online, interfaces with four Jet Airways operational systems in real time, and delivers validated data automatically to the right departments the moment a flight record is confirmed.
A mirror image of the paper Techlog for every flight and every aircraft type.
With automated data retrieval from FLD/LIDO, built-in validation, and real-time delivery to Engineering, Internal Operations, Rostering, and Finance. No manual transcription. No duplicate entry. No paper.
The Techlog system operates through three primary processes — two automated, one user-driven — working in sequence for every flight that lands.
Automated · Every 10 Minutes
FLD Retrieval:
Every 10 minutes, Techlog polls the Jet Airways FTP server and pulls FLD flat files for three days simultaneously — previous, current, and next. Three days are needed because FLD operates in UTC: a flight very early in the day may appear in the previous day's file, a flight very late may appear in the next day's file. The 10-minute polling frequency reflects the live nature of flight operations — data changes continuously as flights land, are delayed, cancelled, or rescheduled. Each poll captures the latest state.
User Interaction · On Flight Landing
Data Entry & Flagging
After a flight lands, an AME user opens the pre-populated record and completes the aircraft-type-specific form from the paper Techlog. Where handwriting on the paper form cannot be read or a value cannot be confirmed, the field is flagged — marking it for resolution before delivery to any downstream system that requires it.
Conditional · Gate-Based Delivery
Delivery Gates
Each downstream system has its own delivery gate. If a flagged field is not required by a particular system, that record passes through and is delivered — the gate opens. If the flagged field is required by the system, the record is held at that gate until the flag is verified and cleared. Each system only waits for the fields it needs.
What made Techlog technically demanding was not the form itself — it was the five-way live integration with Jet Airways systems — one source and four destinations — each with its own data format, transfer protocol, and update frequency. An additional operational CSV was also generated for day-to-day use.
LIDO / FLD
Lufthansa Systems
Data Source — Flight Information
The single data source. Techlog polls FLD flat files via FTP every 10 minutes. Three days of files are pulled simultaneously — previous, current, and next — because FLD operates in UTC. Flights very early in the day appear in the previous day's file; flights very late appear in the next day's file. The 10-minute frequency reflects live flight operations: data changes continuously as flights land, are delayed, cancelled, or rescheduled. Files contain scheduled and actual OOOI times, fuel loads, TOW, payload, alternate destination, crew identifiers, and aircraft registration.
AMOS
Swiss-AS
Data Destination — Engineering
Aircraft maintenance and operations system. Techlog delivers engineering-relevant flight data including actual fuel figures, technical observations, and flight times — enabling AMOS to update aircraft maintenance records and airworthiness tracking without manual re-entry.
Netline
Lufthansa Systems
Data Destination — Internal Operations
Used for internal operations and feeds into other downstream systems within Jet Airways. Techlog delivers the relevant operational flight data enabling Netline to update records and support internal operational workflows.
Avient
Rostering System
Data Destination — Rostering
Rostering system. Techlog delivers crew-relevant data including actual block times and flight duty periods — enabling Avient to update crew records, flight duty time calculations, and roster management without manual input.
FMS
Finance Management System
Data Destination — Finance
Finance system. Techlog delivers flight-relevant financial data — enabling the Finance team to update cost records, fuel cost calculations, and operational financials automatically from confirmed flight records.
Operational CSV
Additional Output
Supplementary — Operational Purposes
An additional CSV output generated for day-to-day operational use — providing a flexible, human-readable extract of flight data for operational teams alongside the structured system-to-system flat file deliveries.
Every Techlog record moves through a defined sequence — from live system retrieval through human verification to automated multi-system delivery.
Techlog Data Flow — Jet Airways
One of the most technically demanding aspects of Techlog was building and maintaining four entirely separate form architectures — one for each aircraft type in the Jet Airways fleet. Each aircraft type has different operational parameters, different field sets, different validation rules, and different pre-set equations.
The A330 alone has pre-set equations and validation standards across dozens of fields — covering fuel loads, weight calculations, OOOI times, crew identifiers, and technical observations — all of which must validate against aircraft-specific min/max thresholds before a record can be submitted.
Every field in the Techlog form is subject to real-time validation against pre-set equations and aircraft-specific standards. Where an AME user cannot read the handwriting on the paper Techlog form — or cannot confirm a value — the field is flagged. This is not an error state; it is a deliberate workflow mechanism that reflects the operational reality of transcribing handwritten paper forms.
The gate logic that governs delivery to downstream systems is the critical architectural decision: each system has its own set of required fields. A flagged value only blocks delivery to systems that need that specific field. If a field is flagged but is not required by a given system, the record passes that system's gate and delivers. If the field is required, the record waits at that gate until the flag is verified and cleared by an authorised user.
Techlog was conceived, built, documented, and owned entirely by Webonautics. Suma Srinivas wrote the complete technical documentation — the system guidebook, field specifications, integration protocols, and operational procedures.
Multiple approaches were made to acquire Techlog. The terms offered did not reflect the value of what had been built — a live, validated, four-aircraft, four-integration operational system embedded in one of India's largest airlines. The IP was not sold.
Jet Airways ceased operations in April 2019. Techlog operated until the airline closed. The intellectual property remains with Webonautics.
A two-founder studio directed, designed, and delivered a real-time flight data system that interfaced with four enterprise aviation platforms simultaneously — UI entirely by Suma, PHP and MySQL by a NDA-bound development partner, architecture by Lathesh. Operated without interruption inside a major international airline for five years. The IP was never sold.