Arc Skills / Standards and development assurance
Check software assurance evidence against DO-178C objectives
This task checks whether current software lifecycle evidence supports the objectives applicable to an approved software level. Arc Skills produces an evidence map that separates a test result from configuration and problem-report closure.
Use this skill
Use Arc Skills to review the supplied software evidence against the project-controlled DO-178C objective matrix. Preserve the matrix’s exact objective IDs and approved applicability.
Inputs:
- Approved software level, controlled edition, supplements and objective matrix.
- Software baseline, plans, lifecycle index, test records and problem reports.
- Configuration records tying tests to the reviewed build.
Return a row-level evidence map with artifact revision, observed result, open report and owner. If controlled objective text is absent, use descriptive topics and label all objective IDs unverified.What you provide and what you get
| What you have | How it is used | What you get |
|---|---|---|
| Approved level and objective matrix | Defines which rows are actually applicable | Scoped objective list |
| Lifecycle and test records | Shows activity and observed results | Evidence status |
| Build and problem-report index | Checks currency and unresolved issues | Configuration/closure gaps |
A tested build still has an open disposition
Illustrative engineering example.
A synthetic Level C project submits requirement tests for build SW-12 and a trace export. The problem-report index lists PR-9 against SW-12 as unresolved. The controlled objective matrix itself was not supplied, so the row labels below are review topics, not invented DO-178C objective identifiers.
| Topic (ID unverified) | Evidence | Assessment | Required next record |
|---|---|---|---|
| Requirement test execution | TR-12 records passes on SW-12 | Execution evidence present for listed tests | Reconcile scope with the project objective matrix |
| Trace and baseline | TRACE-12 references SW-12 requirements | Trace present, completeness unassessed | Controlled baseline and trace review record |
| Problem-report disposition | PR-9 remains open for SW-12 | Closure claim not supported | Impact assessment and approved disposition for PR-9 |
A passed test establishes the observed outcome of its defined procedure on SW-12. It does not establish that every applicable software objective, independent review, or quality process is complete. PR-9 could affect the claimed requirements or tests; its impact has to be assessed before closing related rows.
The example deliberately avoids numerical objective IDs because the controlled matrix is missing. The next useful artifact is an exact objective-to-evidence map at the approved software level, including any applicable supplement, with the version of every artifact visible.
Map objectives through current lifecycle data
- Confirm the assigned software level, selected DO-178C edition, supplements and approved tailoring.
- For each applicable matrix row, follow plan → artifact → review or execution result → baseline.
- Check problem reports, changed code and re-verification against the tested build.
- Report present, stale, missing and unassessable evidence separately.
Questions about this task
Does structural coverage prove compliance?
No. It is one possible evidence stream under a controlled objective matrix; development, verification, configuration and process evidence must be reviewed where applicable.
What if the objective matrix is unavailable?
Inventory the supplied evidence and identify gaps without assigning objective numbers or a software-level compliance verdict.
Sources and further reading
- FAA AC 20-115D: Official guidance on airborne software assurance using DO-178C and applicable supplements.
FAA AC 20-115D identifies DO-178C and applicable supplements as a means of compliance; objective detail comes from the controlled project texts.