Assess whether an engineering tool needs qualification

Use this skill

Use Arc Skills to assess qualification need for each stated tool use. Trace input, tool output, credited engineering objective and every independent downstream check.

Inputs:
- Tool name, version, configuration and operational use.
- Project-controlled software or hardware assurance basis and assigned level.
- Evidence showing how generated or reported results are reviewed or re-executed.

Return a use-by-use table with credible tool error, escape path, detection evidence and provisional disposition. State which controlled criteria and authority decision are still required. Do not assign a TQL from the tool name.

Set up the toolkit · Read the skill instructions

What you provide and what you get

A generator and coverage reporter have different credit paths

Illustrative engineering example.

A synthetic airborne-software project uses generator G-2 to produce source code and reporter C-4 to summarize executed coverage. The generator output receives complete source review and tests; the C-4 summary is copied into the compliance package without reconciliation to raw execution data.

The two tools cannot receive one blanket label. G-2 is a development tool whose generated source remains subject to later verification; C-4 is a verification tool whose own summary is being trusted. The deciding question is whether a plausible error is actually detected at the scope at which output is credited.

The first row is conditional, not a tool approval: “complete review” must be evidenced and must cover the emitted branch behavior. The third row prevents old tool evidence from silently carrying over after a version change. The software level and controlled DO-178C/DO-330 criteria determine any formal qualification route; the example supplies neither a TQL nor a certification conclusion.

Follow the output credit, not the tool label

1. Draw each input → tool → output → credited artifact path for the stated configuration.
2. Name a plausible tool error and ask whether it could satisfy an objective falsely.
3. Inspect each claimed independent check against that specific error and all relevant outputs.
4. Record the controlled criteria, missing evidence and decision owner before a qualification disposition.

Questions about this task

Can a code generator avoid qualification?

Possibly, when its output receives independent verification sufficient to detect relevant generator errors. Record what is checked, for which configuration, and under the project’s controlled assurance basis.

Does a vendor qualification certificate settle this use?

No. Qualification credit depends on the project’s intended use, operational constraints, tool version and applicable objectives; assess whether the certificate covers those conditions.

Sources and further reading

• FAA AC 20-115D: Official guidance on airborne software assurance using DO-178C and applicable supplements.

FAA AC 20-115D recognizes DO-178C and DO-330; detailed tool criteria and TQL decisions require the project-controlled texts and authority process.

Related tasks

• Check software assurance evidence against DO-178C objectives: Inspect the software objective evidence that may credit this tool output.
• Check hardware assurance evidence against DO-254 objectives: Review the separate hardware assurance use case.
• Review development assurance level allocation rationale: Confirm the allocated assurance basis before tool assessment.