An EASA Part-145 component shop releases every unit with an EASA Form 1, and behind every Form 1 sits test evidence the regulation requires you to keep, protect, and produce on demand. Most shops meet the letter of this with paper test sheets and PDF printouts. This guide maps the actual Part-145 clauses to what a structured test-data system covers, so the same records that satisfy the auditor also feed your analytics.
The Clauses That Touch Test Data
| Clause | Requirement | TofuPilot feature |
|---|---|---|
| 145.A.40(b) | Test equipment controlled and calibrated to an officially recognised standard; calibration records and traceability kept | Station identifier on every run, linking results to the bench and its calibration register |
| 145.A.50(d) | CRS for components issued as EASA Form 1, backed by acceptance test evidence | Complete run record per release: measurements, limits, result, date, unit identity |
| 145.A.55(a) | Retain all records necessary to prove requirements were met for the CRS | Immutable run history per serial number |
| 145.A.55(a)(3) | Detailed maintenance records kept 3 years from CRS issue | Cloud retention beyond the mandated period |
| AMC 145.A.55 | Electronic systems: backup within 24 hours of new entries, safeguards against unauthorised alteration, backup stored in a different location | Managed storage with replication; records not editable after upload |
Two details from the AMC and guidance material are worth knowing precisely. First, the acceptance test report should be attached to a Form 1 issued as Inspected/Tested, and Block 12 must cite the maintenance data with its revision status; "in accordance with the CMM" alone is not acceptable. Second, the retention clock runs from when the record was created or last amended, so a system that timestamps every run gives you the retention basis for free.
Structure the Test So the Record Is the Evidence
The regulation asks for proof that the unit met its acceptance criteria. A structured test produces that proof as a side effect of running. Each measurement carries its limits, its unit, and a description tying it back to the maintenance data:
name: LRU Bench Acceptance Testversion: 1.0.0description: Functional acceptance test for a returned unit on the repair benchunit: serial_number: default_value: "LRU000001" part_number: default_value: "622-1234-001"main: - name: Power Supply Check python: phases.power_check measurements: - name: supply_voltage unit: V description: "28V nominal bus input, per CMM test 1A" validators: - operator: ">=" expected_value: 27.5 - operator: "<=" expected_value: 28.5The run record then contains everything the release depends on: the serial number and part number, each measured value against its declared limit, the procedure name and version, the station that ran it, and the timestamp. When the Form 1 goes out as Inspected/Tested, the attached test report is a query, not a scan.
Procedure versioning matters here more than it first appears. Block 12 requires the revision status of the maintenance data used. Versioning your test procedure alongside the CMM revision it implements means every historical run states which revision of the test it was measured against.
Calibration Traceability by Station
145.A.40(b) requires calibration records and traceability for the test equipment itself, and the audit checklist covers tools, calibration, and alternative tooling explicitly. TofuPilot does not replace your calibration register, but the station identifier on every run creates the link auditors look for: name stations to match the calibration register, and any measurement can be traced to the bench that produced it and from there to its calibration state on that date.
This also answers the ugly retrospective question. When a tool turns up out of calibration past its due date, the shop must review the work that used it. With runs filtered by station and date range, the affected releases are a query instead of a work-order archaeology project.
Retention, Backup, and Integrity
AMC 145.A.55 sets concrete expectations for computer record systems: a backup updated within 24 hours of any new entry, protection against unauthorised alteration, and backup media held in a different location from the working data. A shop running its records on a spreadsheet and a shared drive owns all three of those problems itself, and the control of computer record systems is a standing item on the EASA audit checklist (MOE chapter 2.21).
Structured cloud records shift that burden: runs are immutable once uploaded, storage is replicated, and every record is retrievable by serial number, part number, procedure, station, date range, or result for the full retention period and beyond.
For shops working under FAA approval as well, 14 CFR 145.219 asks for records demonstrating compliance for at least 2 years from return to service, in English, in a format acceptable to the FAA; electronic record systems come under AC 120-78B. The EASA 3-year requirement is the stricter of the two, so a system sized for Part-145 covers both.
What Good Looks Like
In a shop running this way, an auditor asking for the test evidence behind a given Form 1 gets it by serial number in seconds, with limits, values, procedure revision, and station attached. The calibration question traces from any measurement to a named bench. Retention is not a filing discipline but a property of the system. And because the compliance records are structured measurements rather than PDFs, the same data answers the engineering questions too: yield by part number, drift by measurement, and the units that keep coming back.