Skip to content

Conformity records

Conformity records support for installation approval packages

Conformity records support checks that the articles used to generate test evidence were the right articles, in the right configuration, and eligible to produce evidence at the time they were tested. It is prepared by or for the modifier before an installation approval package reaches formal review. The work reads the article identity, the configuration each article held, and the conformity established before testing, then confirms every test result rests on an article tied to a controlled build. You receive an article-to-test eligibility view, a gap assessment where a result cannot claim a conforming article, and a closure plan before submittal.

When this review is needed

  • Test evidence was generated on articles whose configuration at test time was never pinned to a controlled build.
  • A test article was modified between builds and the modifier has to show which revision each result belongs to.
  • An article's conformity was supposed to be established before a test ran, and the project needs to confirm it actually was.
  • A reviewer is expected to trace a test result back to a conforming article, and the team wants that trace verified first.

The problem

A test result is only evidence if the thing tested was the thing being approved. A conformity record ties a test article to a controlled configuration and establishes that the article was eligible to produce evidence before the test ran. In practice articles get reworked between runs, engineering units stand in for production configurations, and conformity that should have preceded a test gets documented after the fact or not at all. The result sits in the package looking authoritative while the article behind it cannot be tied to the approved build.

What gets reviewed

  • Article identity confirmed for each test that feeds the compliance evidence
  • The configuration each test article held at the time of test, tied to a controlled build
  • Pre-test conformity established for the articles that require it
  • Rework between builds reconciled so each result is assigned to the correct revision
  • Engineering or prototype articles distinguished from the configuration being approved
  • A closure plan for results that cannot yet claim a conforming article

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 relied-upon test result maps to an article of known identity and configuration
  • The article's configuration at test time matches a controlled build in the package
  • Pre-test conformity was established where the evidence requires it, not after
  • Rework between runs is accounted for so no result is attributed to the wrong revision
  • Prototype or engineering articles are not silently treated as the approved configuration

Evidence normally required

  • The conformity records and inspection reports for the test articles
  • Test reports with the article identity and configuration they cite
  • The build and rework history for each test article
  • The controlled configuration the installation is approved against
  • Any conformity request or authorization that preceded testing

Common discrepancies

  • A test result attributed to an article whose configuration at test time is undocumented
  • A conformity record dated after a test rather than established before it ran
  • An engineering unit used for a test that stands in for a production configuration without a bridge
  • A reworked article whose two builds are not distinguished across its test results

What is at stake

A test result whose article cannot claim conformity is not evidence a reviewer can accept, and repeating the test is often the only remedy once the article has moved on or been reconfigured. A conformity gap found late can strand an otherwise complete data set, because the underlying test has to be re-run on a conforming article against the same schedule the submittal was built on.

How the work runs

01

List the relied-upon tests

Identify every test whose result the compliance evidence depends on and the article each used.

02

Pin the article configuration

Establish the configuration each test article held at test time and tie it to a controlled build.

03

Confirm eligibility

Verify conformity was established before each test where the evidence requires it.

04

Plan the closure

Flag results that cannot claim a conforming article and sequence any re-test needed.

What the buyer receives

  • An article-to-test eligibility view across the relied-upon results
  • A gap assessment naming each result that cannot claim a conforming article
  • A closure plan for the conformity gaps before the package is submitted

Who uses the output

  • Certification project managers confirming the test evidence rests on conforming articles
  • Engineering leads deciding whether a result stands or a test must be re-run
  • Compliance staff tracing results back to conforming articles for the reviewer

How the work fits into the transaction or program

The conformity check sits between the test evidence and the configuration the package claims. It is what makes a test result count, so it is confirmed before results are bound into the verification trace and the compliance matrix. A gap found here saves the project from carrying a result the reviewer will reject.

Start with a single asset

Reduce finding cycles by checking the package first.

Jurisdiction-specific considerations

Both FAA and EASA require that compliance evidence rest on conforming articles, and the principle is common, but the conformity mechanism differs. The FAA works through conformity inspection and authorization, while the EASA system establishes conformity through the design organization's own processes. The check confirms conformity was established under whichever mechanism the certification basis invokes rather than assuming one satisfies the other.

Regulatory limits

The work confirms test articles were conforming and eligible and flags results that were not. It does not perform conformity inspections, does not authorize testing, and does not make a compliance finding or grant an approval. Conformity determination and the compliance decision rest with the authority and its delegates.

What this review does not cover

  • Performing conformity inspections or issuing conformity authorizations
  • Re-running any test on a conforming article
  • Any compliance finding or approval on the test evidence

Specific to this review

  • A test result is only usable if conformity preceded it, so a conformity record dated after its test is a finding even when the article was in fact conforming.
  • Reworked test articles are the classic trap, because two builds share one article number and results get attributed across them without a clean split.
  • A conformity gap cannot always be closed on paper: if the article has moved on, the only remedy is re-running the test on one that conforms.

Sources

Frequently asked questions

The test passed. Why does conformity of the article matter?

A passing test only counts as evidence if the article tested was the configuration being approved and was eligible to produce evidence when tested. If conformity was never established, or the article was later reworked, the result cannot be tied to the approved build, and a reviewer will treat it as unsupported regardless of the numbers.

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.