> ## Documentation Index > Fetch the complete documentation index at: https://docs.planeconnection.com/llms.txt > Use this file to discover all available pages before exploring further. # Flight Operations Data Model > How operational data flows through PlaneConnection: trips, legs, crew, passengers, aircraft, and flight logs -- and how ops data feeds safety management. Flight operations generate a rich stream of data -- every trip planned, every leg flown, every crew assignment made, every passenger boarded, and every maintenance item tracked. Understanding how this data is structured and how it flows through PlaneConnection is essential for getting the most out of both the Operations and Safety modules. More importantly, this operational data is a primary input to your Safety Management System, providing the factual context that makes risk assessments and safety performance monitoring meaningful. This page is for operations managers, safety managers, and administrators who need to understand how data entities relate to each other in PlaneConnection. For the feature-level overview, see [Modules Overview](/en/explanation/modules-overview). For safety-specific data flows, see [Safety Performance Monitoring](/en/explanation/safety-performance). ## Core Entities and Relationships PlaneConnection's operations data model centers on the **trip** as the primary unit of work. All other entities connect to trips directly or through their components. ```mermaid theme={} erDiagram TRIP ||--o{ LEG : contains LEG ||--o{ CREW_ASSIGNMENT : has LEG ||--o{ PASSENGER_MANIFEST : has LEG }o--|| AIRCRAFT : "flown by" LEG ||--o| FLIGHT_LOG : "recorded in" CREW_ASSIGNMENT }o--|| CREW_MEMBER : "assigns" PASSENGER_MANIFEST }o--|| PASSENGER : "includes" AIRCRAFT ||--o{ DUE_ITEM : tracks AIRCRAFT ||--o{ DISCREPANCY : has CREW_MEMBER ||--o{ QUALIFICATION : holds FLIGHT_LOG ||--o{ EXPENSE : generates TRIP ||--o{ EXPENSE : incurs TRIP }o--o| OWNER : "billed to" TRIP { string trip_number string status date start_date date end_date } LEG { string origin string destination datetime departure datetime arrival string status } AIRCRAFT { string tail_number string type float total_hours float total_cycles } CREW_MEMBER { string name string role string certifications } PASSENGER { string name string preferences } FLIGHT_LOG { float block_time float flight_time float fuel_burn int landings } ``` ## The Trip Lifecycle A trip is the top-level container for a planned sequence of flights. It progresses through a defined lifecycle: ### Trip Creation A trip begins as a request or a planned movement. At creation, it captures the high-level intent: who is traveling, where they need to go, when they need to arrive, and any special requirements (catering, ground transportation, customs). The trip is assigned a unique trip number that serves as its identifier throughout the system. ### Leg Planning Each trip is composed of one or more **legs** -- individual flight segments from one airport to another. A round trip with a fuel stop might have three legs: origin to fuel stop, fuel stop to destination, and destination back to origin. Each leg captures the airports (origin and destination as ICAO/IATA codes), scheduled departure and arrival times, which aircraft is assigned, the crew (pilot-in-command, second-in-command, and any additional crew), which passengers are on board for this specific leg, planned fuel load and uplift, and weight-and-balance calculations for the specific load. Legs are independent entities within a trip. Different legs can use different aircraft (for repositioning), have different crew (for crew swaps), and carry different passengers (for multi-stop itineraries). ### Crew Assignment Crew members are assigned to specific legs, not to trips as a whole. This flexibility supports complex scheduling scenarios where crew rotate between legs or where a positioning flight uses different crew than the revenue flight. Each crew assignment records the crew member's role on that leg (PIC, SIC, flight attendant) and contributes to their duty time, flight time, and currency tracking. When a crew assignment is made, PlaneConnection can check certification and type rating for the assigned aircraft, medical currency, duty time limitations under Part 135 Subpart F, and recency and currency requirements. ### Passenger Manifests Passengers are associated with specific legs through manifest entries. Each manifest entry links a passenger record to a leg, capturing the seat assignment (if applicable), baggage count and weight, special requirements, catering preferences, and ground transportation needs. The passenger record itself -- maintained independently of any trip -- stores contact information, travel documents, preferences, and flight history. ### Flight Execution and Logging When a leg is flown, the **flight log** captures what actually happened versus what was planned. This includes block time (gate-to-gate duration), flight time (airborne duration), fuel burn and fuel uplift, number of landings (relevant for cycle tracking), instrument approaches flown (relevant for currency), the actual route flown, any delays and their causes, and discrepancies -- aircraft issues noted during the flight. Flight log data is the authoritative record of operational activity. It feeds into multiple downstream calculations and records. ## Aircraft Records Each aircraft in PlaneConnection maintains a comprehensive profile: **Static data** -- Registration (tail number), type/model, serial number, configuration (seats, baggage capacity), and specifications (range, speed, payload). **Running totals** -- Total airframe hours, total cycles (landings), engine hours, and APU hours. These totals are updated automatically from flight log entries. **Due items** -- Maintenance inspections, airworthiness directives (ADs), service bulletins, and other compliance items tracked against time (calendar date), hours (airframe or engine), or cycles. Each due item has a compliance deadline and a warning threshold that triggers notifications as the deadline approaches. **Discrepancies** -- Open items recorded during operations -- squawks, write-ups, and deferred maintenance items. Discrepancies are tracked to resolution and can be linked to maintenance work orders. ## Crew Records Crew records maintain the personnel data needed for scheduling, compliance, and safety: **Qualifications** -- Type ratings, certifications, check ride dates, and training records. Each qualification has an expiration date that PlaneConnection monitors for currency. **Medical status** -- FAA medical certificate type, issue date, and expiration. Medical currency is checked during crew assignment. **Flight time** -- Accumulated flight hours by aircraft type, role (PIC, SIC), and conditions (day, night, instrument). Flight time records are built automatically from flight log entries. **Duty time** -- Work periods tracked against Part 135 Subpart F limitations, including weekly flight time limits, required rest periods, and quarterly rest requirements. **Schedule history** -- Complete record of past and upcoming trip assignments, enabling workload analysis and equitable scheduling. ## How Operations Data Feeds Safety The integration between operations and safety data is one of PlaneConnection's most significant architectural decisions. Rather than treating operations and safety as separate systems, the platform connects them so that safety management is grounded in operational reality. ### Flight Hours and Fatigue Tracking Flight log data flows directly into fatigue-relevant calculations. Duty periods, flight hours, rest intervals, and cumulative workload are available to the safety module for monitoring against Part 135 Subpart F requirements and for use in fatigue risk assessments. When a safety report references crew fatigue as a contributing factor, the actual duty time and flight time data from operations provides objective context for the investigation. ### Discrepancies as Hazard Sources Aircraft discrepancies entered in operations are potential hazard inputs for the safety module. A recurring discrepancy on a specific aircraft type -- persistent avionics issues, recurring hydraulic leaks, frequent brake wear -- can be identified as a systemic hazard and entered into the risk register for formal assessment. ### Operational Context for Safety Reports When a safety report references a specific flight, the report can link to the operational record. Investigators can see the crew assignments, passenger load, weather at the time, airport characteristics, and flight log data -- all without leaving the investigation workflow. This contextual linkage makes investigations more thorough and findings more accurate. ### Utilization Data for Risk Assessment Aircraft utilization patterns -- hours flown, cycles accumulated, types of operations (IFR vs. VFR, day vs. night, domestic vs. international) -- inform risk assessments. Higher utilization in challenging conditions increases exposure to certain hazards, and that exposure should be reflected in your risk register. ### Reporting Normalization Safety report counts in isolation can be misleading. Reporting 10 events in a month means something different for an operator flying 500 hours than for one flying 50 hours. Operations data provides the denominators (flight hours, departures, cycles) needed to normalize safety metrics into meaningful rates. ## The Reporting Layer PlaneConnection's operations module includes 40+ report types that provide views into the underlying data model: | Category | Example Reports | | --------------- | ----------------------------------------------------------------- | | **Utilization** | Annual utilization, aircraft hours/cycles, fleet status | | **Financial** | Operating costs, expense summaries, invoice status, pilot payment | | **Fuel** | Contract fuel receipts, contract vs. retail analysis | | **Scheduling** | Scheduled calendar legs, crew schedules, aircraft availability | | **Owners** | Owner usage summary, company briefing, revenue/expense allocation | | **Custom** | User-defined reports with configurable parameters | These reports are views into the operational data model, not separate data stores. They pull from the same trips, legs, flight logs, and financial records, ensuring consistency across every report. ## Related Feature-level overview of Safety and Operations modules. How operational data feeds safety performance indicators. How all this data is isolated between organizations. How operational hazards enter the SRM process.