Scanned component records
Checking the digital records index of a component-history source file
When a component-history source file lives as scans, the digital records index is what makes it usable, and this review tests that index against the files it points to. It is run by records specialists for operators, lessors, and MRO teams before a trace package is shared or migrated. Checks cover whether each scan opens, reads, searches, ties to the right aircraft and serial number, and matches the record the index says it is. The component records lead receives an exception list of index entries that would fail a reviewer, with the fix needed for each.
When this review is needed
- A component trace package is about to be uploaded to a counterparty's review platform.
- Records were bulk-scanned by a vendor project and the index has never been sampled for accuracy.
- A migration between records systems re-keyed file paths and index links may have broken.
- Reviewers keep asking for documents the team believes are already in the package.
The problem
A scanned archive fails quietly. The index looks complete, the folder counts look right, and only when someone opens file after file does it emerge that scans are skewed, pages are missing, OCR never ran, or the index entry for one serial number opens the paperwork for another. The team discovers this on a counterparty's timeline instead of its own.
What gets reviewed
- Sampled and targeted opening of scans across every index section
- Index entry metadata checked against the document actually stored: type, date, aircraft, serial number
- OCR and text-search coverage measured across the package
- File naming and folder structure tested against the index's referencing scheme
- Duplicate, orphaned, and dead-link entries identified
- Legibility of stamps, sign-offs, and certificate blocks confirmed on the records that matter most
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 sampled index entry opens the document it describes, at the revision it claims
- Serial numbers in the scans agree with the serial numbers the index assigns them
- Key certificates remain readable at the resolution stored, including stamps and signatures
- Text search returns the sampled documents when queried by part number and serial number
- No index section relies on files that exist only in a superseded folder tree
Evidence normally required
- The digital records index in its native export format
- Read access to the stored scans or the records platform hosting them
- The installed-part list and serial-number register for tie-back testing
- Scanning-project documentation, if a vendor performed the digitization
Common discrepancies
- An index entry whose linked file is a different document with a similar name
- Scans stored as images with no OCR layer, invisible to any search
- Certificate scans where the release stamp is cut off or too dark to read
- Whole subfolders orphaned by a platform migration and absent from the index
What is at stake
Index defects convert into trace findings. A reviewer who cannot find or read a record treats it as absent, writes the exception, and shifts the burden of proof back to the operator. Re-scanning and re-indexing under transaction pressure costs far more than the same work done before the package went out.
How the work runs
Profile the index
Map sections, counts, and the referencing scheme, and design the sample.
Open and read
Test sampled entries for legibility, correctness, and revision.
Test retrieval
Run part-number and serial-number searches and record what the package fails to return.
Queue the fixes
Deliver exceptions with a specific remediation for each: re-scan, re-key, or re-link.
What the buyer receives
- An index exception list ranked by trace impact
- A remediation queue naming each file to re-scan, re-key, or re-link
- A short statement of index reliability the team can attach when sharing the package
Who uses the output
- Component records leads preparing a trace package for outside review
- Records-system administrators fixing links and metadata
- Quality leadership deciding whether a scanning vendor's work is acceptable
How the work fits into the transaction or program
Index quality sits underneath every other component-history check. Binder verification, release-document review, and serial-history reconciliation all assume the index will surface the right file; when it does not, their findings are noise. Running the index review first keeps the rest of the source review honest.
Start with a single asset
Confirm release certificates and component traceability are complete.
Jurisdiction-specific considerations
FAA guidance in AC 120-78 accepts electronic recordkeeping when the system preserves integrity and retrievability, and 14 CFR 91.417 still governs what must be kept and produced. EASA-context holders answer to the record requirements of Regulation (EU) 1321/2014. Neither regime accepts an index defect as an excuse for failing to produce a required record.
Regulatory limits
The review evaluates indexing and retrievability, no more. It does not validate the technical content of the records, does not rule on airworthiness, and does not constitute approval of the electronic recordkeeping system by any authority.
What this review does not cover
- Re-scanning or re-keying the archive itself
- Selection or configuration of a records-management platform
- Review of the underlying maintenance decisions the scans document
Specific to this review
- OCR failure is the most common invisible defect: files open fine but no search will ever find them.
- Migration between platforms breaks links silently because both systems report success while pointers go stale.
- Reviewers judge a package by the first ten documents they open, so early index errors color everything after.
- A scan can be perfectly legible and still useless if nothing ties it to the aircraft or serial number it belongs to.
Sources
Federal Aviation Administration. FAA acceptance criteria for electronic recordkeeping systems and electronic signatures.
Federal Aviation Administration. FAA guidance on making and keeping maintenance records and acceptable recordkeeping practices.
European Union / EASA. Continuing airworthiness, maintenance records, CAMO responsibilities, and the airworthiness review process in the EASA system.
U.S. Government (eCFR). Records an owner or operator must keep, including total time in service, current status of life-limited parts, and AD compliance.
Frequently asked questions
How large a sample is enough?
Sampling is sized to the package structure, then weighted toward the records a reviewer will actually pull: release certificates, LLP history, and AD accomplishment evidence get full coverage while routine correspondence is sampled. A defect pattern in any section triggers a full pass of that section.
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.