Skip to Content
Business logicLogbookLogbook rules

Logbook rules

The logbook is the IBA’s source of truth for “what has this member actually done”. Every flight, every skill attempt, every approval is a logbook entry. The rules in this module govern how entries are created, how they transition through states, and how they remain trustworthy over time.

Entry kinds

Two main kinds of entries:

  • Flight time — minutes flown, where, when, and (if applicable) the booking that produced the entry. For Convergence-integrated USA tunnels, entries arrive automatically from the booking system. For FuzeMetrix, Tunn3l, and non-integrated tunnels, flight time is added manually.
  • Skill attempts — every time a flyer requests, attempts, or is approved for a skill. Each entry carries the skill, level, approver, approval date, and linked flight time.

Skill entries reference an approver — the qualified instructor / trainer / examiner / coach / military-trainer who signed off. Each approval lands in two places: the flyer’s logbook (who did the skill) and as metadata pointing back to the approver (who signed).

Entry lifecycle (state machine)

A logbook entry isn’t a fire-and-forget record. It moves through a short lifecycle:

StateMeaning
Not AvailableSkill exists in the catalogue but the flyer doesn’t yet meet its prerequisites or doesn’t have active currency.
AvailablePrerequisites met and currency active — the flyer can request this skill.
RequestedThe flyer has requested the skill; an instructor needs to approve.
OpenAn instructor has approved and the flyer is actively working toward completion.
Not CurrentCurrency lapsed while the entry was Open — the entry is paused until currency is restored.
SuspendedAn admin has paused the entry (rare, for irregularities).
CompletedFinal approval signed; the skill counts toward the flyer’s level.
Declined / Expired / CancelledThe request didn’t make it to approval. The flyer can re-request.

Most entries spend their lives quietly in Open → Completed. The other states exist so the platform can be honest about edge cases: “this almost happened but didn’t”, or “this was real but the flyer’s currency lapsed before they finished”.

For the full state diagram and every transition, see skill lifecycle.

Currency-aware behaviour

The logbook’s behaviour depends on the actor’s currency:

  • Flyer currency lapses while a skill is Open → entry transitions to Not Current. The work isn’t lost; when the flyer regains currency, the entry transitions back to Open exactly where it left off.
  • Approver’s currency was inactive at sign-off → the approval is rejected before it lands. There’s no “we’ll fix it later” path; the approver re-signs after restoring their currency.
  • Booking-driven flight while currency is inactive → no logbook entry is created. The member is emailed about recurrent training instead. (See tunnel bookings.)

Audit trail

Every state transition is recorded with:

  • The timestamp of the transition.
  • The actor who triggered it (member, instructor, admin, cron).
  • For approvals: the approver’s role and authorised level at the time of the signature.

This last point matters: the IBA’s promise is “the signature was valid at the moment it was made”. An instructor whose authority later lapses or even decreases doesn’t retroactively invalidate skills they previously approved.

Immutability rules

Once a logbook entry is Completed:

  • The skill, date, time, approver, and source flight are effectively immutable.
  • Edits require admin intervention via the admin console and produce an audit record (who changed what, when, why).
  • Wholesale deletion of a completed entry is exceptional and requires the same admin intervention.

This is deliberate. The logbook’s value is its trustworthiness, and that erodes the moment people start tweaking history casually.

Sub-pages in this module

Last updated on