Safety-assessment evidence review for certification teams

When this review is needed

• A safety-assessment data package is about to go to the authority and the team wants the trace confirmed before it leaves.
• A finding questions whether a failure condition classification is actually supported, and a response is due.
• A design change alters a failure mode and the safety case has to be re-walked against the revised architecture.
• The functional hazard assessment was written early and no one has checked that later requirements absorbed every hazard.

The problem

Safety assessments accrete over a program. A hazard identified at the functional level spawns a probability budget, which spawns derived safety requirements, which are supposed to flow into design and verification, but the artifacts are authored by different people at different phases. By submittal, a classification can sit in the SSA with no requirement enforcing it, or a mitigation named in the PSSA that never became a testable line. The team reading the package for the first time as a whole is often the authority.

What gets reviewed

• Functional hazard assessment entries checked for a corresponding failure condition in the system safety assessment
• Failure condition classifications compared against the probability and integrity budgets that justify them
• Derived safety requirements traced forward into the requirement set and back to the hazard that produced them
• Mitigations and design assumptions named in the PSSA confirmed to appear in verifiable form
• Common-cause and independence claims checked for the analysis that substantiates them
• Safety-assessment references to the certification basis confirmed against the agreed basis of record

What gets validated

• Every failure condition in the SSA maps to a hazard in the functional hazard assessment, with no orphan on either side
• Each classification is backed by a quantitative or qualitative budget consistent with ARP4761A guidance
• Derived safety requirements appear in the controlled requirement set rather than only in the analysis narrative
• Mitigations relied on by the assessment have a verification method assigned, not just a description
• Independence and common-cause arguments cite the specific analysis that supports them

Evidence normally required

• The functional hazard assessment for the function or aircraft level under review
• Preliminary and system safety assessments, including fault trees or equivalent analyses
• The requirement set the derived safety requirements are meant to live in
• The requirement feedback record from the safety process to the design
• The agreed certification basis and any prior findings on the safety case

Common discrepancies

• A derived safety requirement stated in the PSSA that never entered the controlled requirement set
• A failure condition classified as hazardous whose probability budget is not substantiated
• An independence claim in a fault tree with no supporting common-cause analysis
• A hazard closed in the functional hazard assessment with no mitigation carried into design

What is at stake

A safety claim that does not trace invites a finding that stalls the submittal until the team reconstructs the link under time pressure. A failure condition classified more favorably than its evidence supports is worse: it can force a redesign or a fresh analysis late, after schedule and cost have already been committed against the earlier answer.

How the work runs

What the buyer receives

• A gap list naming each unsupported safety claim and the artifact it should trace to
• An evidence map linking hazards, classifications, requirements, and verification in one view
• A closure sequence ordered so dependent gaps are worked before the claims that rest on them

Who uses the output

• Compliance management assembling the submittal and answering to the authority for the safety case
• Safety engineers who own the analyses and have to close the flagged links
• Certification leadership deciding whether the package is ready to submit or needs another pass

How the work fits into the transaction or program

The review sits between the safety analysis work and the compliance submittal. It takes the assessments as authored and confirms they hold together as a case before an authority reads them, feeding the gap list into the requirement and verification work that has to close before the package can support a finding.

Jurisdiction-specific considerations

FAA and EASA both accept ARP4761A as an acceptable means for the safety-assessment process, but the two authorities frame the certification basis and the expected level of substantiation differently, so the review notes where a classification defensible under one framing needs additional support to hold under the other.

Regulatory limits

The review checks that the safety evidence is internally consistent and traceable. It does not accept the safety assessment, make a compliance finding, or determine that any failure condition classification is correct for airworthiness purposes. Those decisions rest with the applicant's authorized representatives and the authority.

What this review does not cover

• Authoring or re-running the fault trees, Markov analyses, or other safety analyses
• Setting or approving failure condition classifications on the applicant's behalf
• Making a compliance finding or securing any authority acceptance

Specific to this review

• The functional hazard assessment is written earliest and reviewed last, so hazards that never grew into requirements are the most common silent gap.
• A favorable classification with a thin budget is more expensive to fix than a missing requirement, because closing it can reopen the architecture.
• Independence is where safety cases most often overstate their position: a fault tree assumes it, but the common-cause analysis that would prove it is missing or stale.

Sources

Frequently asked questions

Relevant glossary terms

Related pages

Where this fits