Type-design packages
Configuration management support for a type-design data package
This review checks the configuration management evidence in a type-design data package so the data submitted matches the configuration under control. It reads baselines, revision histories, and release records and confirms each piece of evidence carries the identity and revision it claims, and that the whole package describes one coherent configuration rather than a mix of versions. A certification engineer runs it so a reviewer cannot find two documents describing different builds of the same item. You get a configuration-consistency assessment, a list of items whose evidence and control records disagree, and a plan to reconcile them.
When this review is needed
- The package is being assembled from evidence produced across several revisions and it must describe one build.
- A late design change rippled through documents and the baselines may no longer agree.
- Software and hardware configuration indexes need to reconcile with the system-level baseline.
- A reviewer will check that submitted data matches the controlled configuration and the applicant wants mismatches found first.
The problem
A data package is assembled from documents produced over a long development, and the configuration keeps moving underneath them. A test is run against one revision, a report is written against another, and the release record captures a third, so the package quietly contains several versions of the same item. Configuration control is maintained in the tools, but the evidence carried into the package is a snapshot that drifts from those tools the moment it is exported.
What gets reviewed
- Baselines checked so the package describes one coherent configuration
- Each evidence item checked to carry the identity and revision it claims
- Revision histories reconciled across the documents that reference each item
- Software and hardware configuration indexes reconciled with the system baseline
- Release records confirmed to match the configuration the evidence was produced against
- Late changes traced through every document they should have touched
Scope this review
Tell us the asset, the event, and the evidence in scope, and we will outline a focused first engagement.
Identify what is missing against the means of compliance.
What gets validated
- Every evidence item names a configuration identity and revision that exist in the control records
- The revision an item is tested or analyzed against matches the revision its report claims
- Baselines referenced across the package agree on the configuration of shared items
- Software and hardware configuration indexes reconcile with the system-level baseline
- Every late change appears in each document that references the changed item
Evidence normally required
- The configuration management plan and the baseline definitions
- The configuration indexes for the system, software, and hardware
- Release records and revision histories for the controlled items
- The evidence documents with their stated identities and revisions
- The change history for design changes made during the project
Common discrepancies
- A report written against a revision different from the one the test was run on
- Baselines across the package that disagree on a shared item's revision
- A configuration index that lists a revision no release record supports
- A late change reflected in some referencing documents but not all
What is at stake
Configuration mismatches undermine every claim built on the affected items, because a reviewer cannot tell which version the evidence actually proves. Catching one mismatch prompts the reviewer to distrust the rest, and the review expands into a version audit across the package. Reconciling late, after the evidence was produced, can mean rerunning work against the controlled revision, which is exactly the cost the control system was meant to avoid.
How the work runs
Fix the baselines
Establish the configuration the package is meant to describe and confirm the baselines agree on it.
Check each item
Confirm every evidence item carries the identity and revision it claims and that the control records support it.
Reconcile the indexes
Align the software and hardware configuration indexes with the system-level baseline.
Trace late changes
Follow each late change through every document it should have touched and log where it did not.
What the buyer receives
- A configuration-consistency assessment across the package's evidence
- A mismatch list where evidence and control records disagree on identity or revision
- A reconciliation plan ordering the mismatches, with any needed rework flagged
Who uses the output
- Certification leads who present a single coherent configuration in review
- Configuration managers who reconcile the baselines and indexes
- Engineers who confirm which revision their evidence was actually produced against
How the work fits into the transaction or program
Configuration management is the discipline that lets every other piece of evidence be trusted, because it fixes which version each claim is about. This review confirms the package describes one configuration before the compliance map treats its evidence as settled, so no downstream claim rests on the wrong revision. It runs late in assembly, once the individual evidence items exist.
Start with a single asset
Reduce finding cycles by checking the package first.
Jurisdiction-specific considerations
FAA and EASA both require configuration control over the type-design data and expect the submitted package to reflect the controlled configuration, and where DO-178C or DO-254 apply, their configuration management objectives add specific expectations by level. The review reads the evidence against the control expectations that actually apply to this article.
Regulatory limits
This work checks whether the submitted evidence matches the controlled configuration. It does not operate the configuration management system, does not make a compliance finding, and does not determine airworthiness or grant approval. Those remain with the applicant and the authority.
What this review does not cover
- Running the configuration management system or issuing baselines
- Producing or re-releasing the evidence documents
- Making the compliance finding for the configuration
Specific to this review
- Evidence carried into a package is a snapshot, and it starts drifting from the control tools the instant it is exported, which is why the package can hold several versions of one item.
- A single confirmed mismatch changes how a reviewer reads the rest, turning a spot check into a version audit across the whole package.
- Late design changes are the usual source of mismatches, because they must touch every referencing document and one is almost always missed.
Sources
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
Federal Aviation Administration. FAA type certification process, certification basis establishment, and compliance findings.
European Union / EASA. EASA design and production certification, STCs, ETSO authorizations, and EASA Form 1 release.
SAE International. Development assurance process at aircraft and system level, including requirements capture and validation.
RTCA. Objectives and lifecycle data for airborne software assurance, by design assurance level (DAL A-E).
Frequently asked questions
We control configuration in our tools, so why check the package?
The tools hold the live configuration, but the evidence in the package is exported at a point in time and can drift from the tools afterward. A report may claim a revision the test never ran on. This review confirms the exported evidence still matches the controlled configuration it references.
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.