Objective compliance
Compliance-checklist review for avionics and equipment suppliers
A compliance-checklist review checks whether each objective on a supplier's compliance checklist is backed by a status a reviewer can trust. It is for avionics and equipment teams whose objective-by-objective checklist has to agree with the evidence before submittal. The review covers objective coverage against the applicable standards, the status assigned to each objective, and the evidence each status points to. You receive an annotated checklist with each objective confirmed or flagged and a list of objectives whose status is overstated, unevidenced, or missing.
When this review is needed
- The checklist is the index a reviewer will read against and the team needs each objective status confirmed first.
- Several objectives were marked satisfied early and the evidence behind them has moved or thinned since.
- A standard revision changed the objective set and the checklist still reflects the prior edition.
- Status is recorded as a single mark with no link to the artifact that earns it.
The problem
A compliance checklist is read as a promise: every objective satisfied, with evidence behind it. In practice the marks go in early and rarely come back out. An objective gets a satisfied status on the strength of a plan, the work shifts, and the mark stays green while the evidence underneath it never materializes or moves elsewhere. The checklist then says more than the package can show, and the first objective a reviewer samples sets the tone for the rest.
What gets reviewed
- Objective coverage against the applicable standard edition for the assurance level
- The status assigned to each objective and whether the evidence earns it
- The link from each satisfied objective to the artifact that substantiates it
- Items marked not applicable and the rationale recorded for the exclusion
- Consistency between the checklist and the means-of-compliance plan it implements
- Statuses that depend on lifecycle activities still open
What gets validated
- Every objective required for the assurance level appears with a status
- Each satisfied status points to lifecycle data that supports the claim
- Not-applicable statuses carry a recorded, defensible rationale
- The checklist reflects the standard edition the certification basis names
- Objective statuses agree with the means-of-compliance plan they implement
- No objective is marked satisfied while the activity behind it is still open
- Independence objectives are evidenced as independent where the level requires it
Evidence normally required
- The current compliance checklist with its objective statuses
- The applicable standard edition and the assigned assurance level
- The means-of-compliance plan the checklist implements
- References or an index to the lifecycle data behind each objective
- The certification basis naming the standard edition in force
Common discrepancies
- Objectives marked satisfied with no traceable evidence behind the status
- A checklist built against a prior standard edition than the basis names
- Not-applicable statuses with no rationale a reviewer can defend
- Statuses that disagree with the means-of-compliance plan they implement
- Independence objectives marked satisfied without evidence of independence
- Satisfied objectives whose underlying lifecycle activity is still open
What is at stake
An overstated checklist invites the reviewer to test the weakest entries first, and a status that does not hold turns the whole checklist into something to be re-verified rather than relied on. The schedule cost is the re-verification; the credibility cost is that the reviewer stops taking the marks at face value.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Pin the objective set
Confirm the standard edition the certification basis names and the objectives the assurance level requires.
Test each status
Check whether each satisfied or not-applicable status is earned by traceable evidence or a defensible rationale.
Cross-check the plan
Reconcile the checklist against the means-of-compliance plan it implements and flag the disagreements.
Annotate and prioritize
Deliver the annotated checklist and a prioritized list of objectives whose status does not hold.
What the buyer receives
- An annotated checklist with each objective confirmed or flagged
- A list of objectives whose status is overstated, unevidenced, or missing
- A coverage check of the objective set against the standard edition in force
- A prioritized closure list ordered by the review risk each objective carries
Who uses the output
- Compliance leads finalizing the objective-level checklist
- Certification leads confirming the checklist before submittal
- Engineering teams closing the objectives the review flagged
How the work fits into the transaction or program
The review works at the objective level, one step below the compliance matrix. It pairs with a compliance-matrix review when the requirement-to-evidence mapping above the objectives also needs checking, and with a tool-qualification evidence review when objectives lean on automated activity.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
FAA and EASA accept the same RTCA and EUROCAE objective sets, so the checklist content is largely common. The difference is which standard edition the certification basis invokes and how a program records its objective rationale, so the review checks the checklist against the edition in the basis rather than against the newest published one.
Regulatory limits
Endeavor Elements checks the applicant's compliance checklist for completeness, consistency, and traceability. It does not make compliance findings, satisfy objectives on the applicant's behalf, or issue any approval. The applicant and the authority keep their roles.
What this review does not cover
- Making official compliance findings or issuing any approval
- Performing the lifecycle activities that satisfy the objectives
- Writing the rationale for objectives the supplier marks not applicable
Specific to this review
- Checklist statuses are entered early and seldom revisited, so the dominant finding is a satisfied mark whose evidence never caught up.
- A not-applicable status is a claim, not a default; without a recorded rationale it is the easiest entry for a reviewer to challenge.
- Independence objectives fail on the same trap as the rest: the activity happened, but nothing in the record shows it was performed independently.
- A checklist built to a superseded standard edition can be internally consistent and still wrong, because it answers an objective set the basis no longer invokes.
Sources
RTCA. Objectives and lifecycle data for airborne software assurance, by design assurance level (DAL A-E).
RTCA. Design assurance objectives and lifecycle data for airborne electronic hardware (FPGA/ASIC/PLD).
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
SAE International. Development assurance process at aircraft and system level, including requirements capture and validation.
Frequently asked questions
How is this different from a compliance-matrix review?
A compliance-matrix review checks that requirements map to a means of compliance and evidence. A compliance-checklist review works one level down, at the objective set the standard defines, confirming each objective status is earned.
Can you check objectives we have marked not applicable?
Yes. Not-applicable is one of the most challenged statuses in review. The check confirms each exclusion carries a recorded, defensible rationale rather than an unexplained mark.
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.