The graph is precise, but incomplete: It shows a 160-foot altitude loss. It does not show where the student was looking, whether turbulence contributed, how the controls felt, or why the correction came late.

Flight data is powerful when it answers the question it can actually support - and dangerous when it is asked to prove more.

Flight data can show what a recorded variable did and when it changed. It cannot automatically show why the change occurred, whether the pilot saw the traffic conflict, how the controls felt, whether the airplane was coordinated, which checklist item was completed, or whether a student is ready for a solo endorsement, stage check, or practical test. The strongest debrief combines recorded evidence with student recall, instructor observation, aircraft procedures, and the applicable training standard.

Core boundary: Telemetry is evidence about the channels and events it actually records. It is not a complete representation of the flight, the pilot's reasoning, or every knowledge, risk-management, and skill element evaluated by the FAA Airman Certification Standards.

What flight data can do well

When the source, calibration, and labels are understood, recorded data can help an instructor reconstruct:

• where the airplane flew;
• how altitude changed;
• when bank, pitch, heading, course, or ground track changed;
• how long a deviation lasted;
• whether a correction reduced or increased the deviation;
• where two attempts differed;
• whether a pattern repeated across comparable sessions;
• how the aircraft moved relative to a runway, assigned heading, selected altitude, or maneuver boundary;
• whether the student recognized a trend earlier on a later attempt, when the event markers and debrief notes support that conclusion.

Those capabilities are valuable because memory alone is incomplete. A graph can settle a factual question such as whether altitude began decreasing during entry or after the bank was established. It can also identify the exact phase that deserves discussion.

The limitation appears when the graph is asked to answer a question its inputs do not support.

Flight data cannot prove the pilot's control inputs

A change in pitch, bank, heading, or vertical speed does not necessarily reveal what the pilot did with the controls.

An altitude loss in a steep turn might be associated with:

• increasing bank;
• insufficient total lift;
• airspeed decay;
• turbulence;
• a deliberate traffic-avoidance maneuver;
• an instructor control input;
• sensor lag or mounting error;
• a combination of factors.

Unless the system records reliable control-position or force data, it cannot prove that the student used too much elevator, failed to use rudder, changed power late, or trimmed incorrectly. Those may be reasonable instructional hypotheses, but they must be checked against the student's account, instructor observation, aircraft response, and other evidence.

Flight data may not show coordination

Bank, heading, and ground track do not establish whether the airplane was coordinated.

A pilot can hold the intended bank and heading while slipping or skidding. Portable telemetry often does not include a validated slip/skid, yaw-rate, sideslip-angle, or rudder-input channel. Even when a device has motion sensors, installation, alignment, filtering, and aircraft vibration affect interpretation.

For slow flight, stalls, climbing turns, and traffic-pattern work, the instructor may need to rely on:

• the aircraft's slip/skid indication;
• sight, sound, and control feel;
• instructor observation;
• student description;
• a suitable onboard data source, when available.

Do not label a maneuver "coordinated" merely because the path looks smooth.

Flight data may not identify the exact stall event

The FAA defines a stall by exceeding critical angle of attack, not by one airspeed, pitch attitude, or vertical-speed value.

A typical portable record may lack:

• angle of attack;
• stall-warning activation;
• buffet;
• control feel;
• yaw and slip/skid;
• the exact point at which the wing reached critical angle of attack.

A high pitch angle does not prove a stall. A low eIAS or groundspeed does not prove a stall. A rapid altitude loss does not prove the precise full-stall point. In an intentional stall debrief, the instructor should identify the cues observed in the airplane and use the trace to reconstruct entry and recovery timing without claiming a sensor-detected event that was not recorded.

Flight data cannot show the complete outside scan

A student may meet an altitude, heading, or bank target while failing to clear the area or monitor traffic.

Telemetry generally cannot establish:

• where the student was looking;
• whether traffic was seen;
• whether the runway was confirmed clear;
• whether terrain and obstacles were considered;
• whether the student maintained orientation;
• whether attention was trapped inside the cockpit.

The FAA ACS integrates collision avoidance, situational awareness, task management, and other risk-management elements with aircraft control. A clean trace does not erase an inadequate scan.

Flight data cannot reveal the decision reason by itself

A path change can have multiple explanations.

Consider a go-around that begins earlier than expected. The data may show the descent stopping, power-related pitch change, a lateral move, and climb establishment. It may not show that:

• an aircraft was still on the runway;
• another airplane began departing;
• ATC issued an instruction;
• a gust caused a sudden loss of alignment;
• the student lost visual contact with the runway;
• the instructor called for the maneuver;
• the pilot applied a prebriefed stabilized-approach gate.

The reason matters. Without it, the system should not label the decision late, early, correct, or incorrect solely from the flight path.

Flight data cannot independently verify checklist or POH/AFM compliance

Unless configuration and switch states are recorded from a reliable source, the trace may not show:

• flap position;
• landing gear position;
• propeller setting;
• trim position;
• carburetor heat or alternate air;
• checklist completion;
• actual power setting;
• whether the pilot followed the aircraft-specific sequence.

A climb that develops slowly after a go-around might involve aircraft performance, density altitude, downdraft, delayed power, configuration, trim, or another cause. The graph can focus the question, but it should not invent the cockpit sequence.

The current POH/AFM and approved checklist remain controlling.

Flight data cannot recreate the environment perfectly

Recorded or downloaded conditions may differ from what the airplane encountered.

Potential gaps include:

• winds aloft that do not match the local training area;
• gusts and turbulence between reporting points;
• runway contamination or surface condition;
• wake turbulence;
• downdrafts or mechanical turbulence;
• temperature variation;
• density-altitude changes;
• sensor update rate and latency;
• GPS reception or device dropouts.

The instructor should ask which weather source was used, when it was updated, and whether the student or instructor has more representative information from the training area.

The specific limits of FlytWERX eIAS

When airspeed matters, FlytWERX can add estimated indicated airspeed, or eIAS, to the debrief. eIAS is a calculated training estimate based on GPS-derived speed, winds aloft, temperature, and the active wind correction; more representative local winds can be entered when available. The airplane's approved airspeed indication remains controlling in flight. See How FlytWERX calculates eIAS.

An instructor should ask:

• What wind source and time were used?
• Was the wind representative of the maneuver altitude and training area?
• Was the temperature input current?
• Was the value eIAS, direct aircraft airspeed, simulator airspeed, or groundspeed?
• Were there abrupt local changes that the wind correction could not represent?
• Was the aircraft indication compared during the session?
• Is the value clearly labeled as estimated?

The airplane's approved airspeed indication remains controlling in flight. eIAS supports debriefing and trend analysis; it does not replace the aircraft instrument or prove regulatory compliance by itself.

Flight data cannot determine causation automatically

Timing can support a causal question, but sequence is not always cause.

If bank increases before altitude decreases, that relationship deserves review. It does not prove that excessive bank was the only cause. Power, airspeed, turbulence, control input, and sensor behavior may also matter.

A responsible analysis uses three labels:

Observed fact

Bank increased from the selected target, then altitude began decreasing.

Instructional hypothesis

The altitude loss may have begun because the increasing bank was not matched with the required pitch, power, or bank correction.

Verification needed

Compare the student account, instructor observation, eIAS trend, power/configuration information, and another attempt.

Keeping those labels separate prevents a confident-looking graph from becoming an unsupported diagnosis.

Flight data cannot determine complete proficiency or readiness

The FAA ACS evaluates knowledge, risk management, and skill together. A product can help measure selected performance variables, but it cannot independently determine whether the student:

• understands the maneuver and aircraft limitations;
• manages traffic and weather appropriately;
• uses checklists and procedures correctly;
• makes sound decisions under workload;
• transfers the skill to a new scenario;
• performs with the required independence;
• qualifies for an endorsement;
• is ready for a stage check or practical test.

Those decisions belong to qualified instructors and authorized school personnel using the complete record and applicable requirements.

Use three evidence categories in every debrief

Directly recorded

Examples include GPS position, altitude from the identified source, bank, pitch, heading, ground track, or direct aircraft data when the connection supports it.

Calculated or derived

Examples include eIAS, AGL estimates, event boundaries, stability measures, or scores. The method and input quality matter.

Interpreted

Examples include "late recognition," "insufficient rudder," "poor scan," "unstable decision-making," or "ready for solo." These require instructor judgment and may depend on evidence outside the recording.

The interface and written debrief should preserve those distinctions.

A six-step data-limits check

Step 1: Name the question

Do not open every graph without a purpose. Ask one question such as, "When did the altitude deviation begin?"

Step 2: Identify the source

State whether the field came from aircraft avionics, Stratus, iPhone or iPad sensors, simulator telemetry, GPS, manual entry, or a calculation.

Step 3: Check quality and context

Review calibration, mounting, dropouts, update rate, weather inputs, aircraft, lesson objective, and instructor assistance.

Step 4: Separate fact from interpretation

Write what the record shows before writing why it may have happened.

Step 5: Add the missing human evidence

Ask the student what was noticed, what action was taken, and why. Add instructor observation and the applicable aircraft procedure.

Step 6: Choose one next test

Use another demonstration, chair-flying exercise, simulator session, dual attempt, or authorized practice event to test the instructional hypothesis.

What a school should evaluate before adopting this workflow

What should a pilot prove?

A useful pilot should show that instructors understand exactly what the recorded data can and cannot establish. Define the baseline, responsible reviewers, representative users, support effort, errors, workarounds, privacy risks, and stop criteria before the first session. At the decision meeting, choose to scale, modify, extend, or stop.

How should implementation start?

Begin with one defined workflow, one representative cohort, a small instructor group, and a written baseline. Keep required records and approvals in their current systems until the school verifies accuracy, usability, support, privacy, export, and compliance behavior. Expand only after difficult cases and failure modes have been tested.

FlytWERX school pricing is quote-based. For the complete buying framework, use the pricing and plan comparison, flight-school implementation, data migration and record continuity, ROI measurement, and software comparison. The controlled pilot method is covered in How to Pilot New Technology at a Flight School.

Put this into practice

Take one graph and write two lists: what it establishes and what still requires instructor context. Review the result with the person who owns the training decision, then use the next comparable attempt to test whether the change worked.

Next step: Use Flight Data With Instructor Judgment.

Important implementation and governance limits

This framework is educational and does not make a student, instructor, stage-check, record, privacy, security, compliance, procurement, or quality determination for a specific school. Apply current regulations, approved courses, school procedures, authoritative records, contracts, privacy and security requirements, and qualified human review. Verify the production FlytWERX configuration before operational use.

Frequently asked questions

Is flight data objective?

It can be objective about a correctly recorded and labeled field. Source quality, calibration, processing, and context still matter, and the data may not answer the instructor's causal question.

Can FlytWERX tell an instructor exactly what the student did wrong?

It can show recorded deviations, timing, trends, and comparisons. The instructor determines the likely cause and corrective technique using the full evidence.

Can data replace instructor notes?

No. Notes preserve the lesson objective, student explanation, instructor assistance, decisions, and context that telemetry may not contain.

Should every available variable be shown to the student?

Not necessarily. Select the smallest set that answers the debrief question. Too many traces can obscure the one relationship the student needs to understand.

Can a score prove ACS compliance?

No. A score can summarize selected measured dimensions. Complete ACS evaluation includes knowledge, risk management, procedures, judgment, and skills that may not be recorded.