Pre-submittal finding closure
Closing software data that falls short of its assigned level
This work closes a finding where a system's software lifecycle data does not meet the DO-178C objectives its assigned software level demands. An engineer reads the lifecycle data against the objective set for the assigned level, maps each objective to the evidence that should satisfy it, and identifies the objectives with no supporting artifact or with an artifact that does not reach the required rigor. It runs during a pre-submittal review. You receive a closure brief on the unsatisfied objectives, an evidence request list for the lifecycle data still owed, and a disposition package mapping lifecycle evidence to objectives for the assigned level.
When this review is needed
- Software was developed to a lower level and then reassigned higher without the added objectives being met.
- Structural coverage evidence required at the assigned level is missing or was collected at the wrong criterion.
- Independence required for verification activities at the level was not applied and is not documented.
- The lifecycle data satisfies most objectives but a handful for the assigned level have no artifact behind them.
The problem
A software level is easy to assign and hard to fully satisfy. The objectives climb steeply between levels, and structural coverage, independence, and verification of verification are exactly the ones that get shortchanged when a system's level is raised late or when the plans were written to one level and the work drifted to another. The lifecycle data looks substantial, but a reviewer checks it objective by objective against the assigned level, and the objectives with no artifact, or an artifact that misses the required criterion, are where the finding lands.
What gets reviewed
- The DO-178C objective set for the assigned software level enumerated
- Each objective mapped to the lifecycle artifact that should satisfy it
- Coverage evidence checked against the structural criterion the assigned level requires
- Verification independence checked where the assigned level requires it
- Objectives with no artifact, or an artifact below the required rigor, identified
- A mapping of lifecycle evidence to objectives for the assigned level
What gets validated
- Every objective applicable to the assigned software level maps to a lifecycle artifact
- The structural coverage evidence meets the criterion the assigned level requires
- Verification activities that require independence at the assigned level show it and document it
- No objective is satisfied by an artifact produced to a lower level's rigor
- Where an objective has no evidence, it is flagged as owed rather than assumed met
Evidence normally required
- The software lifecycle data, including plans, standards, and verification results
- The assigned software level and the objective set that applies to it
- The structural coverage results and the criterion used
- The verification records and the independence documentation
- The finding text describing the level-to-data mismatch
Common discrepancies
- Structural coverage collected at a weaker criterion than the assigned level requires
- Verification independence required at the level but neither applied nor documented
- A system raised to a higher software level late, with the added objectives never addressed
- An objective for the assigned level with no lifecycle artifact behind it at all
What is at stake
Software data that does not meet its assigned level is not acceptable evidence, and the objectives cannot be waved through. The missing work, whether structural coverage runs, added independence, or verification artifacts, has to be produced, and that is schedule the program may not have. Discovering the shortfall at the authority means renegotiating under review rather than planning the added rigor in-house, and a level mismatch left unaddressed can force a costly redo of the verification effort.
Move from findings to resolution
Identify the missing data behind the finding.
How the work runs
Enumerate the objectives
List the DO-178C objectives that apply to the assigned software level.
Map data to objectives
Link each objective to the lifecycle artifact meant to satisfy it, checking criterion and independence.
Isolate the shortfalls
Identify objectives with no artifact or with an artifact below the required rigor.
Package the disposition
Write the closure brief, list the artifacts owed, and deliver the objective-to-evidence mapping.
What the buyer receives
- A closure brief listing the unsatisfied objectives for the assigned level and how each closes
- An evidence request list for the lifecycle data and verification artifacts still owed
- A reviewer-ready disposition package mapping lifecycle evidence to objectives at the assigned level
Who uses the output
- Certification engineers closing the software finding before submittal
- Software verification leads scoping the coverage or independence work now required
- Program managers weighing the schedule cost of producing the missing objective evidence
How the work fits into the transaction or program
This closure runs at pre-submittal, once the software level is assigned and the lifecycle data is assembled. It depends on a stable software level, which itself traces from the safety assessment, and it feeds the software compliance argument. Because unmet objectives usually mean new verification work, closing this early lets the program schedule the rigor rather than discovering the gap under the reviewer's eye.
Start with a single asset
Confirm each requirement maps to substantiating evidence.
Jurisdiction-specific considerations
FAA and EASA both recognize DO-178C, but the depth of software data each will review and the stage-of-involvement or level-of-involvement practice each applies can differ, so the objective mapping is presented in the form the reviewing authority expects to work through.
Regulatory limits
This work maps lifecycle evidence to objectives and identifies where the assigned level is not met. It does not perform software verification, produce structural coverage, assign the software level, approve the lifecycle data, or make any compliance finding.
What this review does not cover
- Executing software verification or generating structural coverage evidence
- Assigning or reassigning the software level
- Making the compliance finding on the software lifecycle data
Specific to this review
- The objectives that most often fall short are structural coverage, independence, and verification of verification, because they scale hardest between levels.
- A late level increase is the classic trigger, since the plans and work were built for the lower level and the added objectives were never retrofitted.
- An artifact collected to a weaker criterion looks like evidence but does not satisfy the objective, so the gap hides behind a document that appears complete.
Sources
RTCA. Objectives and lifecycle data for airborne software assurance, by design assurance level (DAL A-E).
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
Can we close this by lowering the software level instead?
Only if the safety assessment supports a lower level, which is an engineering and authority question, not a documentation shortcut. We can show which objectives a level change would relieve, but the level itself follows from the hazard assessment. We map the data to whatever level is assigned; we do not reassign it.
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.