PlaneConnection supports six safety report types aligned with the Safety Management System requirements of 14 CFR Part 5. Each type captures a distinct category of safety-relevant information and follows specific workflow rules. Reports are tracked by auto-generated codes for traceability.
Report Type Comparison
| Type | Code Prefix | Definition | Triggers Risk Assessment | Triggers Investigation | Can Generate CPAs |
|---|
| Hazard | HAZ | A condition that could foreseeably cause or contribute to an aircraft accident. | Yes | Optional | Yes |
| Incident | INC | An occurrence associated with aircraft operation that affects or could affect safety. | Yes | Yes | Yes |
| Near-Miss | NMS | An event that could have resulted in an accident or incident but did not. | Yes | Optional | Yes |
| Concern | CON | A systemic or organizational issue that could erode safety over time. | Optional | No | Yes |
| Observation | OBS | A factual observation about a safety-related condition or practice. | No | No | Optional |
| Audit Finding | AUF | A finding from an internal safety audit documenting a nonconformity or deficiency. | Optional | No | Yes |
Detailed Definitions
Hazard
A hazard is a condition, object, activity, or situation that could foreseeably cause or contribute to an aircraft accident as defined in 14 CFR 5.5. Hazard reports initiate the Safety Risk Management (SRM) process and require a risk assessment.
Examples: Deteriorating runway surface, inadequate procedure, recurring equipment malfunction.
Workflow: Report submission, risk assessment assignment, SRM severity and likelihood evaluation, risk control documentation, CPA generation if needed.
Regulatory basis: 14 CFR 5.53 (System analysis and hazard identification)
Incident
An incident is an occurrence, other than an accident, associated with the operation of an aircraft that affects or could affect the safety of operations. Incidents trigger the investigation workflow and may require external notification.
Examples: Runway incursion, in-flight equipment failure managed without injury, fuel discrepancy discovered after flight.
Workflow: Report submission, safety manager review, investigation, root cause analysis, findings documentation, CPA generation.
Regulatory basis: 49 CFR 830.5 (NTSB immediate notification), ICAO Annex 13
Near-Miss
A near-miss (also called a “near hit”) is an event that could have resulted in an accident or incident but did not, due to circumstances or intervention. Near-miss reports are a primary source of proactive safety data.
Examples: Traffic conflict resolved by TCAS, aborted takeoff due to a vehicle on the runway, go-around triggered by an unstable approach.
Workflow: Report submission, safety manager review, risk assessment, optional investigation, CPA generation if needed.
Regulatory basis: 14 CFR 5.71(a)(4) (Employee safety reporting)
Concern
A concern is a report about a systemic or organizational issue that could erode safety over time. Concerns address culture, workload, training gaps, or procedural drift rather than discrete events.
Examples: Chronic understaffing during peak operations, inadequate training on a new procedure, pressure to dispatch in marginal weather.
Workflow: Report submission, safety manager review, optional risk assessment, CPA generation to address systemic issue.
Regulatory basis: 14 CFR 5.71(a)(7) (Employee safety concerns)
Observation
An observation is a factual, neutral report about a safety-related condition or practice. Observations do not require that a hazard or risk be identified — they serve as raw data for trend analysis and safety assurance.
Examples: Checklist step skipped without consequence, ramp condition documented during walkthrough, positive safety practice noted.
Workflow: Report submission, safety manager review, data feeds into trend analysis and safety performance indicators.
Regulatory basis: 14 CFR 5.71 (Safety performance monitoring and measurement)
Audit Finding
An audit finding is a result from an internal safety audit that documents a nonconformity, deficiency, or area for improvement. Audit findings link to specific regulatory requirements or internal procedures.
Examples: Expired training records, incomplete maintenance documentation, non-compliance with an operational specification.
Workflow: Report submission, safety manager review, CPA generation to address finding, corrective action verification.
Regulatory basis: 14 CFR 5.73 (Safety performance assessment)
Submission Modes
All six report types can be submitted using any of the four available modes.
| Mode | Reporter Identity | Visible To | Use Case |
|---|
| Standard | Recorded and visible | Safety manager, reviewers, admin | Default mode for routine reporting. |
| Confidential | Recorded but restricted | Safety manager only | Sensitive reports where the reporter’s identity must be protected from the broader team. |
| Anonymous | Not recorded | No one | Reports involving potential retaliation concerns. Reporter cannot be identified or contacted for follow-up. |
| Natural Language | Varies (standard or confidential) | Per selected mode | AI-assisted submission — the reporter describes the event in free-form text and the system extracts structured fields. |
Natural Language Report Submission
Natural language submission reduces the barrier to reporting by allowing reporters to describe events in their own words rather than filling out structured forms. This is especially useful for:
- Time-constrained reporters who need to capture an event quickly before details fade.
- New users unfamiliar with the structured report form.
- Complex events where the reporter is unsure how to categorize the event.
The AI extraction process handles:
| Extracted Field | How It Works |
|---|
| Report type | Classified based on keywords and event description (e.g., mentions of “could have” suggest near-miss, explicit nonconformity language suggests audit finding). |
| Date and time | Extracted from temporal references (“yesterday,” “during the 0800 departure,” “on March 12”). |
| Location | Identified from airport codes (ICAO/IATA), facility names, or geographic descriptions. |
| Aircraft | Tail numbers and flight numbers extracted when mentioned. |
| Category | Mapped to standard categories based on the domain of the event. |
| Severity indicators | Inferred from described outcomes, consequences, and proximity to harm. |
SHELL Classification Model
Safety reports in PlaneConnection support the SHELL classification model (ICAO Doc 9859) to categorize the human factors dimensions involved in a safety event. SHELL stands for Software, Hardware, Environment, Liveware-Self, and Liveware-Others.
| Component | Code | Description | Examples |
|---|
| Software | S | Non-physical aspects of the system — procedures, manuals, checklists, symbology, software interfaces. | Ambiguous checklist wording, outdated SOP, confusing cockpit display logic, unclear maintenance manual steps. |
| Hardware | H | Physical equipment, tools, and aircraft systems. | Cockpit layout, control feel, instrument readability, seat design, tool ergonomics. |
| Environment | E | The operating environment — physical, organizational, and regulatory. | Weather conditions, lighting, noise, temperature, airport layout, regulatory pressure, time zones. |
| Liveware-Self | L-S | The individual at the center of the model — their physical and cognitive state. | Fatigue, stress, workload, experience level, health, complacency, situational awareness. |
| Liveware-Others | L-O | Interactions with other people in the system. | CRM dynamics, ATC communication, maintenance handoffs, crew coordination, supervision quality. |
When completing the SHELL classification, select all components that apply to the event. Most
events involve multiple SHELL interactions (e.g., a Liveware-Self fatigue issue combined with a
Software procedural gap).
Reporter Role Classification
Each safety report captures the role of the person who submitted the report. This supports analysis of reporting patterns across different operational roles.
| Role | Description |
|---|
| Pilot | Flight crew member (PIC, SIC, or relief pilot). |
| Dispatcher | Flight operations dispatcher or coordinator. |
| Maintenance | Aircraft maintenance technician or inspector. |
| Ground Crew | Ramp, fueling, or ground handling personnel. |
| Flight Attendant | Cabin crew member. |
| Management | Operations manager, safety manager, or executive. |
| Other | Any other role not listed above. |
- Which roles submit the most reports (indicating active safety culture participation).
- Whether certain report types are concentrated in specific roles.
- Whether all operational roles are represented in the reporting data (gaps may indicate under-reporting in specific areas).
Auto-Generated Report Codes
Each report receives a unique tracking code upon submission. The format is:
| Component | Description | Example |
|---|
PREFIX | Report type code (see table above) | HAZ |
YYYY | Four-digit year of submission | 2026 |
NNNN | Sequential number, zero-padded | 0042 |
HAZ-2026-0042 identifies the 42nd hazard report submitted in 2026.
Report codes are used for cross-referencing in investigations, CPAs, and compliance dashboards.
Report Statuses
Lifecycle statuses and transition rules for safety reports.
Submit a Safety Report
Safety report submission.
Your First Safety Report
Tutorial walkthrough of the reporting process.
Investigation Workflow
How reports connect to the investigation process.
