Approved data
Approval-data validation for installations and alterations
Approval-data validation confirms that the engineering data behind an installation or alteration is approved or acceptable as the work requires, correctly referenced, and consistent with what was actually done. It serves modifiers, equipment suppliers, and the teams installing approved articles. The trigger is data heading into a sign-off, where the distinction between approved and acceptable data, and the match between the data and the work, both have to be right. It examines the data type and its approval status, the references the installation relies on, the drawings and instructions, and the link from the data to the recorded work. You receive a data-status map and a list of references that are wrong type, missing approval, or out of step with the work.
When this review is needed
- An installation is about to be signed off and the data behind it needs to be confirmed as the right type.
- An alteration relied on data whose approval status is unclear or assumed.
- Drawings and instructions reference upstream data that may not be approved for this use.
- The work performed and the data it was performed to have drifted apart and need reconciling.
The problem
The hardest part of an alteration is rarely the engineering: it is showing the data behind it carries the right status for the job. Approved data and acceptable data get used interchangeably until a sign-off depends on the difference. A drawing cites an upstream document that was acceptable for a different purpose, the instructions reference a revision that was never approved for this installation, and the work as recorded no longer matches the data it claims to follow.
What gets reviewed
- The data type behind each element of the installation and whether it is approved or acceptable
- The approval status and basis of the references the installation relies on
- Installation drawings and whether they cite data approved for this use
- Instructions for continued airworthiness and the data they descend from
- The link between the recorded work and the data it was performed to
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
- Each element relies on data of the type the work actually requires
- References to approved data resolve to data that carries approval for this installation
- Acceptable data is used only where acceptable data is sufficient for the task
- Drawings and instructions cite revisions approved or accepted for this use
- The recorded work matches the data it claims to follow
- Continued-airworthiness instructions descend from data that supports them
Evidence normally required
- The installation or alteration data package and its references
- The approval-status records for the cited data
- Installation drawings and continued-airworthiness instructions
- The work records showing what was performed
Common discrepancies
- Acceptable data relied on where approved data was required
- References to data approved for a different purpose or installation
- Drawings citing revisions that were never approved for this use
- Recorded work that has drifted from the data it claims to follow
- Continued-airworthiness instructions with no approved data behind them
What is at stake
Data that turns out to be the wrong type stops a sign-off cold and can unwind an installation already on the aircraft. The alteration has to be re-substantiated against data that actually carries approval, the records show a configuration the data does not support, and the rework happens with the asset already committed to a return-to-service date.
How the work runs
Classify the data
Identify whether each element relies on approved or acceptable data and what the work requires.
Check the status
Confirm each reference carries approval or acceptance for this specific use.
Reconcile to the work
Match the recorded work to the data it was performed to and flag the drift.
Plan the corrections
List wrong-type and unsupported references with a correction plan ranked by exposure.
What the buyer receives
- A data-status map showing the type and approval status of each reference
- A list of references that are wrong type, missing approval, or out of step with the work
- A correction plan ordered by sign-off and return-to-service exposure
Who uses the output
- Certification and engineering leads clearing the sign-off
- Quality teams reconciling the recorded work to the data
- Modifiers confirming the installation rests on data of the right type
How the work fits into the transaction or program
The validation focuses on the status and referencing of the data behind a job. It complements a record validation that checks a full certificate set, and a field-approval support engagement where the alteration is one the authority approves directly.
Start with a single asset
Reduce finding cycles by checking the package first.
Jurisdiction-specific considerations
The approved-versus-acceptable distinction and the route an alteration takes to an approval differ by authority, so a reference that carries the right status in one system can be the wrong type in another for the same work.
Regulatory limits
Endeavor Elements validates the type, status, and referencing of the applicant's data. It does not approve data, declare data acceptable on the authority's behalf, or guarantee a sign-off. The approval status and the authority's role are unchanged.
What this review does not cover
- Approving data or declaring it acceptable on the authority's behalf
- Signing off the installation or returning the asset to service
- Generating the approved data the installation lacks
Specific to this review
- Acceptable data and approved data are distinct categories, and an installation that needs approved data is not satisfied by data that is merely acceptable.
- Data approved for one purpose or installation does not carry that approval to a different use, which is a frequent source of wrong-type references.
- A sign-off can fail on the status of the data even when the engineering and the workmanship are sound.
- The recorded work and the data it follows can drift apart over a job, leaving a configuration the cited data does not support.
Sources
U.S. Government (eCFR). Maintenance recordkeeping content and approval-for-return-to-service requirements, including 43.9, 43.11, and Appendix B.
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 guidance on making and keeping maintenance records and acceptable recordkeeping practices.
SAE International. Development assurance process at aircraft and system level, including requirements capture and validation.
Frequently asked questions
What is the difference between approved and acceptable data here?
Approved data carries a formal approval for the use; acceptable data is sufficient for tasks that do not require approval. We confirm each element relies on the type its task actually demands.
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.
Walk through your situation with an engineer who has done this work.