Skip to content

Task-card close-out

Closed task cards checked against engine-module source records

A task-card source review examines the closed card set from an engine visit as execution evidence, card by card. It is commissioned by records leads and MRO program managers when the card set has to stand behind the visit at file transfer, redelivery, or audit. Cards are checked for complete sign-offs, valid references to approved data, and agreement with the build sheets and findings they claim to implement. The result is a card-level exception log the engine trace support file can carry forward.

When this review is needed

  • A work package is being closed and the card set must be proven complete before the engine file is archived.
  • An incoming records team received thousands of card images and needs to know whether the set is usable evidence.
  • An audit finding questioned card close-out discipline and the exposure needs sizing.
  • A redelivery standard requires demonstrable execution evidence for the last visit, beyond the release alone.

The problem

A card set is judged by its weakest cards. Individually, a missing inspector stamp, an unreferenced data revision, or a step marked not applicable without justification looks trivial. Across a full engine visit those defects decide whether the set proves the work happened as released, and reading for them takes a systematic pass that operational teams rarely have time to make.

What gets reviewed

  • The card index reconciled against the workscope, so the set is demonstrably complete
  • Sign-off fields checked on every card: mechanic, inspector, and any required independent verification
  • References on each card resolved to the approved data revision actually in the file
  • Steps marked deferred, transferred, or not applicable traced to their justification
  • Cards generating parts movement matched to the release and fitment records they triggered
  • Card dates sequenced against the visit timeline in the build and test records

Scope this review

Tell us the asset, the event, and the evidence in scope, and we will outline a focused first engagement.

Send a representative, redacted record set and we will scope the review.

What gets validated

  • Every workscope line maps to at least one closed card, and orphan cards map to an authorized addition
  • No closed card carries an empty or illegible sign-off block on a required step
  • Data references cite revisions that were current at execution, verifiable in the file
  • Cards that removed or installed hardware agree with the build sheets on part and serial
  • Not-applicable and deferral annotations carry an authorization, never a bare initial

Evidence normally required

  • The closed task-card set, native files or legible scans
  • The workscope and any approved workscope amendments
  • Build sheets and findings records from the same visit
  • The approved data index used by the shop, with revision status
  • Deferral or carry-over records associated with the visit

Common discrepancies

  • Cards closed against a data revision issued after the stamped execution date
  • An inspector sign-off present on the summary page but absent on the step that required it
  • Hardware moves recorded on cards that the build sheets show against a different serial
  • A workscope amendment executed on cards that no amendment authorization covers

What is at stake

Defective cards convert from paperwork noise into leverage the moment a counterparty reviews the file. Work that was done properly becomes work that cannot be shown, and the cost lands as purchase-price arguments, redelivery findings, or repeated inspections that exist only to replace missing signatures.

How the work runs

01

Build the index

Reconcile every card against the workscope and amendments to establish the complete set.

02

Read the cards

Check sign-offs, data references, and annotations on each card against requirements.

03

Cross-match hardware

Verify part and serial moves on the cards against build sheets and release documents.

04

Issue the exception log

Deliver defects ranked by cure difficulty, with shop-curable items flagged first.

What the buyer receives

  • A card-level exception log identifying each defective or unsupported card
  • A completeness matrix from workscope line to closed card
  • A prioritized list of defects the executing shop can still cure

Who uses the output

  • Records leads assembling a defensible visit file
  • MRO program managers closing out vendor performance on the visit
  • Buyer and lessor reviewers who will sample the card set during transfer

How the work fits into the transaction or program

Cards are where the visit's claims meet signatures. This review supplies the ground truth for the shop-visit package review above it: a release is only as strong as the cards behind it, and exceptions found here often explain discrepancies already suspected in the build sheets or the findings register.

Start with a single asset

Confirm release certificates and component traceability are complete.

Jurisdiction-specific considerations

For FAA work, card entries function as the maintenance record required by 14 CFR 43.9, and AC 43-9C describes the content a record needs to carry. EASA Part-145 organizations close cards under their exposition procedures, and the receiving CAMO relies on them under Regulation 1321/2014. Sets produced for dual-release engines are checked against both expectations, since a card adequate under one convention can be thin under the other.

Regulatory limits

This is documentary review only. It does not re-certify work, judge the technical adequacy of the shop's methods, or declare the engine airworthy; the executing organization's releases and the operator's acceptance keep their regulatory standing regardless of the review's findings.

What this review does not cover

  • Assessment of the shop's technical workmanship
  • Recovery negotiations with the executing MRO
  • Human-factors or process audits of the shop floor

Specific to this review

  • Card defects are strongly clustered: a handful of mechanics, shifts, or card templates usually account for most exceptions in a set.
  • Scanned card sets fail differently than native electronic ones; scans lose legibility on stamps, while electronic sets hide auto-populated sign-off fields.
  • The window for curing a defective card closes fast, since shops can amend records while staff and stamps are current but rarely years later.
  • Sampling finds bad cards; only a full index reconciliation finds missing ones.

Sources

Frequently asked questions

Is a sample review enough, or does the whole set need reading?

A sample sizes the defect rate and is often the right first step. Completeness, though, cannot be sampled: proving no card is missing requires reconciling the full index against the workscope. Most engagements pair a full index check with a targeted read of the high-consequence cards.

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.