You are responsible for airworthiness. Now you can see it.

Every maintenance item carries up to three limits: hours, calendar days and landings, whichever comes first. On top of that:

• Warning thresholds and tolerance windows
• Due basis: actual or scheduled
• Which counter it draws on: TTAF, engine hours or prop hours
• One-off items: AD compliance, a one-time re-inspection
• An “unknown” state when there is no baseline yet, so a missing fact is visible instead of hidden

Status is ok, warning or overdue. A daily scan recalculates everything and notifies on every status change. The dashboard shows due bars. The techlog PDF header shows “Next inspection TTAF / NOT LATER THAN”.

When work is done, record the event: date, TTAF, who did it, the CRS reference, the linked document. The item’s last-done values update. The next due moves.

A squawk is a defect. Report it from the flight or on its own, with photos. Lifecycle: open → deferred → closed (or straight to closed).

• Deferral records the Part-ML ML.A.403 reference, the reason, and a limit by date and/or TTAF.
• Closing records a CRS reference and, optionally, the CRS document.
• Pilots acknowledge deferred defects when they open a flight. The acknowledgement is stored.
• An expired deferral raises an alert to everyone who should know.

Roles: any pilot can report. Only the maintenance role or the admin can defer or close.

Certificates in the document store carry an expiry where they have one: the ARC, insurance, the radio licence. You are warned 30 and 7 days before. The AI reads the expiry from the scan; you confirm it.

Every change to an item, an event or a defect is audited with a before/after diff. CRS documents, and anything linked to a flight, a defect or an event, cannot be deleted. That supports the record keeping ML.A.305 asks of the owner; it does not by itself make your records ML.A.305-compliant.