# Traceability Matrix Auditor

> Generate and validate the DO-178C traceability matrix for airborne software. Maps HLR to LLR to source code and runs bidirectional checks for orphan code and dead requirements.



Tags: Aviation, DO-178C, Traceability, Aerospace, Certification, Compliance


## Example Prompts

- Generate a traceability matrix for this airborne software project
- Check for orphan code and dead requirements in the matrix and source
- Run the bidirectional trace check on docs/traceability-matrix.md and src/

URL: https://rakenne.app/skills/traceability-matrix-auditor/index.md

Try this skill: https://rakenne.app/a/?skill=traceability-matrix-auditor



## Overview

Generate and validate the DO-178C traceability matrix for airborne software. The skill maps **High-Level Requirements (HLR)** to **Low-Level Requirements (LLR)** to **source code** and runs bidirectional coverage checks — identifying **orphan code** (source code with no traceable requirement) and **dead requirements** (requirements with no implementing code). It validates that coverage is complete at every level as required by DO-178C Table A-4 through A-7 objectives.

Traceability is a mandatory certification objective for all DO-178C software levels (DAL A through D). Gaps discovered during a DER review or FAA/EASA audit late in a program can delay certification by months — finding them early with automated checks is critical.

## When to use this skill

Use this skill when you are:

- **Generating a traceability matrix from scratch** — starting from your system requirements, HLR documents, and LLR/design specs, and needing a structured matrix that maps each requirement down to the source code that implements it.
- **Running pre-audit traceability checks** before a DER review, FAA/EASA certification audit, or Stage of Involvement (SOI) review to identify and fix coverage gaps before they become findings.
- **Checking for orphan code** — source functions, modules, or files that exist in the codebase but cannot be traced back to any LLR or HLR, which DO-178C prohibits at DAL A/B.
- **Checking for dead requirements** — requirements in the HLR or LLR that have no corresponding implementation, indicating either missing code or a requirements error.
- **Updating the matrix after a change** — when a software modification adds, removes, or changes requirements or code, verifying that the matrix is consistent with the updated configuration.

Typical users include avionics software engineers, DERs (Designated Engineering Representatives), systems safety engineers, and certification program managers at aerospace OEMs, Tier 1 suppliers, and airborne software development contractors.

## Getting Started

Add your requirements documents (HLR, LLR, design specs) and source code to the project workspace, then activate the *Traceability Matrix Auditor* skill. Tell the agent your software level (DAL A through D), the document structure (filenames, section IDs used as requirement identifiers), and the source code directory. The agent will generate or update the matrix and run bidirectional checks.

## Example conversation

> **You:** We need a traceability matrix for our flight control law module. DAL B. HLRs are in `docs/hlr.md` (IDs: HLR-FCL-001 to HLR-FCL-042), LLRs in `docs/lld.md` (IDs: LLR-FCL-001 to LLR-FCL-087), source code in `src/fcl/`.
>
> **Agent:** Parsing HLR and LLR documents... 42 HLRs and 87 LLRs identified. Scanning `src/fcl/` for traceability tags... Found `@req` annotations in 14 of 23 source files. Building matrix now.
>
> **Agent:** Matrix generated: `docs/traceability-matrix.md`. Running bidirectional coverage checks for DAL B objectives...
>
> **Agent:** Coverage check complete. Issues found:
> - **3 orphan functions**: `fcl_pitch_limiter_override()`, `fcl_bank_angle_clamp()`, `fcl_ground_spoiler_inhibit()` — no `@req` tag, no LLR reference traceable. These must be traced or justified as dead code (not permitted at DAL B without deviation).
> - **2 dead requirements**: LLR-FCL-043 and LLR-FCL-044 — no source code traces to these requirements. Either implementing code is missing or the requirements were deleted without updating the LLD.
> - **HLR coverage**: 40/42 HLRs covered. HLR-FCL-038 and HLR-FCL-039 have no child LLRs.
>
> **You:** LLR-FCL-043 and 044 were deleted in the last ECR but the LLD wasn't updated. Flag them for removal.
>
> **Agent:** Flagged LLR-FCL-043 and LLR-FCL-044 as "Deleted — pending LLD update (ECR-2024-117)." Updated matrix with open action items. Remaining: resolve 3 orphan functions before SOI-3.

## Output excerpt

Example bidirectional trace check result:

```
============================================================
DO-178C Traceability Matrix Audit
Module: Flight Control Law (fcl) | DAL: B
============================================================

HLR Coverage (Table A-4 Obj 1):
  Covered: 40 / 42 HLRs
  FAIL — HLR-FCL-038: No child LLRs found.
  FAIL — HLR-FCL-039: No child LLRs found.

LLR Coverage (Table A-5 Obj 1):
  Covered: 85 / 87 LLRs
  WARN — LLR-FCL-043: No source code reference. Flagged for deletion (ECR-2024-117).
  WARN — LLR-FCL-044: No source code reference. Flagged for deletion (ECR-2024-117).

Orphan Code Check (Table A-5 Obj 6):
  FAIL — src/fcl/pitch_limiter.c :: fcl_pitch_limiter_override()
         No @req tag. No traceable LLR. Not permitted at DAL B.
  FAIL — src/fcl/bank_angle.c :: fcl_bank_angle_clamp()
         No @req tag. No traceable LLR.
  FAIL — src/fcl/spoiler.c :: fcl_ground_spoiler_inhibit()
         No @req tag. No traceable LLR.

Summary: 5 findings require resolution before SOI-3 review.
         Matrix saved to: docs/traceability-matrix.md
============================================================
```



---

Back to [Skill Library](https://rakenne.app/skills/index.md)