Reviewing task-card records inside a modification-baseline source file

When this review is needed

• A configuration baseline is being rebuilt and the embodiment claims rest on task cards nobody has opened since the check event.
• A buyer or lessor has questioned whether a listed modification was actually worked, and the answer lives in the closed card set.
• The maintenance-information system shows a work package closed while the scanned cards show steps without stamps.
• A modification-status review surfaced entries the status report cannot support and the cards are the next place to look.

The problem

Card sets get closed under hangar pressure. A package leaves the check with a signed cover certificate, and everyone assumes the cards beneath it are complete. Years later the configuration manager needs those cards to prove a modification was embodied, and finds stamps missing on individual steps, cards citing data revisions the file never held, and continuation sheets that were never scanned. Chasing each defect back through an MRO that has since reorganized its archive takes weeks the baseline schedule does not have.

What gets reviewed

• Every card in the closed set that a modification claim in the baseline depends on
• Sign-off completeness across mechanic, inspector, and RII steps
• The data revision each card cites, compared to the SB or STC revision held in the source file
• Cross-references from cards to embodiment evidence and effectivity notes
• Cards that raised non-routines, followed through to the closure record
• The configuration-control log entry that should mirror each card closure

What gets validated

• Each closed card carries the required sign-off for every step, with RII items stamped by an authorized inspector
• The accomplishment instruction a card cites exists in the source file at the revision that was worked
• Card effectivity matches the aircraft serial number and its configuration at the time of the work
• Parts fitted under a card appear in the configuration records with release paperwork attached
• Closure dates on the cards reconcile with the work-package certificate and the corresponding logbook entry

Evidence normally required

• The closed task-card set, scanned or native digital
• SB accomplishment records and STC data packages the cards reference
• The configuration-control log and effectivity notes for the serial number
• Work-package close-out certificates and related logbook entries
• The modification status report the baseline is meant to support

Common discrepancies

• Cards stamped complete at the header while individual steps sit unsigned
• A card citing an SB revision later than the copy held in the source file
• Embodiment claimed on the status report with no card in the closed set to show for it
• Cards from a descoped work item still filed in the package as if accomplished

What is at stake

A baseline that leans on unverified cards fails at the worst possible moment, usually mid-transaction, when a counterparty's reviewer opens the same cards and prices every unsupported line as a discrepancy. Each card defect then has to be argued or bought out under deadline instead of resolved quietly during the baseline build.

How the work runs

What the buyer receives

• An exception list naming each card that lacks source support and the missing element behind it
• A card-to-source cross-reference the configuration support package carries forward
• A short read-out of systemic patterns, such as one check event producing most of the exceptions

Who uses the output

• Configuration managers assembling or defending the modification baseline
• Records teams chasing the specific documents each exception calls for
• Asset managers deciding which exceptions matter before the next transaction

How the work fits into the transaction or program

Task cards are one strand of a wider modification-baseline source review that also reads non-routines, logbooks, and the status report against the same package. Card exceptions feed the configuration support package alongside the other strands, so a gap found here is either closed by another record type or carried as a known open item with an owner.

Jurisdiction-specific considerations

Under FAA rules the maintenance-record content requirements of 14 CFR 43.9 and the retention duties of 91.417 shape what a card must show, while AC 43-9C describes accepted practice. EASA operators working under Regulation 1321/2014 hold task cards inside the continuing-airworthiness record system, and CAMO conventions on sign-off and retention differ enough that a mixed-history aircraft needs both lenses applied to the same set.

Regulatory limits

The review reports what the closed cards and their sources do and do not demonstrate. It makes no airworthiness determination, issues no approval, and does not re-certify or re-release any work described on the cards.

What this review does not cover

• Physical verification that a modification is installed on the aircraft
• Re-performance or engineering re-approval of the work the cards describe
• Authoring replacement task cards or maintenance data

Specific to this review

• A card set can be complete by count and still fail the review; the frequent defect is a present card citing data the source file does not hold.
• RII steps are the most commonly unsigned items because they are stamped by a different person than the one who closes the card.
• Task cards prove work was performed; they do not by themselves prove the modification applies to the serial number, which is why effectivity notes are read in the same pass.
• Scanned sets routinely drop the reverse side of two-sided cards, and that is where continuation sign-offs tend to sit.

Sources

Frequently asked questions

Relevant glossary terms

Related pages

Where this fits