Pre-submittal finding closure
Closing hardware data that falls short of its design assurance level
This work closes a finding where a device's hardware lifecycle data does not support the design assurance level, the DAL, it was assigned. An engineer reads the DO-254 lifecycle data against the objectives for the assigned DAL, maps each objective to the evidence that should meet it, and finds the objectives left unsupported or the configuration records that do not tie the evidence to the device that was built. It runs during a pre-submittal review. You receive a closure brief on the unsupported objectives, an evidence request list for the hardware data still owed, and a disposition package mapping lifecycle data to objectives and configuration records for the assigned DAL.
When this review is needed
- A programmable device was assigned a DAL whose verification and validation objectives the lifecycle data does not meet.
- Elemental or requirements-based verification expected at the DAL was not performed or not recorded.
- The configuration records do not tie the verified design to the device actually fabricated.
- Advanced verification methods the DAL leans on were used but their results are not captured as evidence.
The problem
Hardware assurance under DO-254 is where lifecycle rigor is easiest to under-record, because much of the evidence lives in tool outputs, review artifacts, and configuration data that a busy team treats as engineering byproduct rather than certification evidence. A device gets a DAL, the design is built and verified, but the objectives for that DAL, elemental analysis, requirements-based verification, the link from verified design to fabricated part, are not all captured. The reviewer checks objective by objective against the DAL and finds the ones the lifecycle data does not actually support.
What gets reviewed
- The DO-254 objective set for the assigned DAL enumerated
- Each objective mapped to the hardware lifecycle artifact that should satisfy it
- Requirements-based and elemental verification checked against what the DAL requires
- The configuration records checked to tie the verified design to the fabricated device
- Objectives with no supporting evidence, or evidence below the DAL, identified
- A mapping of lifecycle data to objectives and configuration records for the DAL
What gets validated
- Every objective applicable to the assigned DAL maps to a hardware lifecycle artifact
- Requirements-based verification and any elemental analysis meet what the DAL requires
- Configuration records link the verified design to the device that was actually fabricated
- Verification method results relied on for the DAL are captured as evidence, not left in tool logs
- Where an objective has no evidence, it is flagged as owed rather than presumed met
Evidence normally required
- The hardware lifecycle data, including plans, design, and verification records
- The assigned DAL and the objective set that applies to it
- The verification results and any elemental analysis outputs
- The hardware configuration records for the fabricated device
- The finding text describing the DAL-to-data mismatch
Common discrepancies
- Elemental analysis expected at the DAL that was never performed or never recorded
- Verification results held in tool outputs but not captured as lifecycle evidence
- Configuration records that do not tie the verified design to the fabricated part
- An objective for the assigned DAL with no supporting artifact at all
What is at stake
Hardware data that does not support its DAL is not acceptable evidence, and the missing objectives cannot be assumed away. Producing them can mean re-running verification, reconstructing elemental analysis, or rebuilding the configuration link between the verified design and the fabricated device, all of which cost schedule. If a mismatch survives to service, a hardware finding can force a design data effort long after the device is fielded, which is the most expensive outcome of all.
Move from findings to resolution
Identify the missing data behind the finding.
How the work runs
Map data to objectives
Link each objective to the hardware artifact meant to satisfy it, including configuration records.
Isolate the shortfalls
Identify objectives with no evidence or with evidence that does not reach the DAL.
Package the disposition
Write the closure brief, list the artifacts owed, and deliver the objective and configuration mapping.
What the buyer receives
Who uses the output
- Certification engineers closing the hardware finding before submittal
- Verification leads scoping the hardware verification or analysis work now required
- Records staff restoring the configuration link between verified design and fabricated device
How the work fits into the transaction or program
This closure runs at pre-submittal, after the DAL is assigned and the hardware lifecycle data is assembled. It parallels the software objective check and, like it, depends on a stable assurance level flowing from the safety assessment. Its output feeds the hardware compliance argument, and because unmet objectives can require re-verification, closing it early keeps the added rigor inside the program's own schedule.
Start with a single asset
Confirm each requirement maps to substantiating evidence.
Jurisdiction-specific considerations
FAA and EASA both recognize DO-254 for complex hardware, but the categories of device each treats as in scope and the supplementary guidance each applies can differ, so the objective mapping is expressed against the reviewing authority's expectations rather than a single interpretation.
Regulatory limits
This work maps hardware lifecycle data to DAL objectives and identifies where the DAL is not supported. It does not perform hardware verification, run elemental analysis, assign the DAL, approve the lifecycle data, or make any compliance finding.
What this review does not cover
- Executing hardware verification or generating elemental analysis
- Assigning or reassigning the design assurance level
- Making the compliance finding on the hardware lifecycle data
Specific to this review
- Hardware evidence is under-recorded more often than it is absent, because verification results live in tool outputs that were never captured as certification artifacts.
- The configuration link from verified design to fabricated device is the objective most often broken, since it depends on records outside the verification effort itself.
- Elemental analysis is a DAL-driven objective that a team may skip entirely if it did not read the objective set carefully for the level it was assigned.
Sources
RTCA. Design assurance objectives and lifecycle data for airborne electronic hardware (FPGA/ASIC/PLD).
SAE International. Development assurance process at aircraft and system level, including requirements capture and validation.
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
Frequently asked questions
Is missing hardware evidence usually a gap in work done or work recorded?
More often it is recording. The verification was run but its results sit in tool outputs or informal reviews that were never captured as lifecycle evidence. We separate the two, because a recording gap can be closed by assembling what exists, while genuinely absent verification has to be scheduled and performed.
Relevant glossary terms
Related pages
Where this fits
Talk to an engineer who has done this work
We will walk through your current state, the records or evidence involved, and a scoped first engagement.
Talk through the aircraft, records, evidence, deadline, and next useful step.