Logbook
The logbook is each member’s permanent flight record. Every flight, every skill attempt, every approval lives here. It’s the IBA’s source of truth for “what has this member actually done”.
What goes into a logbook
Two main kinds of entries:
- Flight time — minutes flown, where, when, and (if applicable) the booking that produced the entry. For Convergence-integrated tunnels (USA), entries arrive automatically from the booking system; for FuzeMetrix, Tunn3l, and non-integrated tunnels, flight time is added manually by the flyer or instructor.
- Skill attempts — every time a flyer requests, attempts, or is approved for a skill. Each entry carries the skill, the level, the approver, the approval date, and the linked flight time if any.
Both kinds tie back to one member, who is the person the entry is about. Approvals also tie to an approver, who is the qualified instructor / trainer / examiner who signed off. So a single approval shows up in two places: in the flyer’s logbook (who did it) and as metadata pointing back to the approver (who signed).
Entry states
A logbook entry isn’t a fire-and-forget record. It moves through a short lifecycle:
| State | What it means |
|---|---|
| Not Available | The skill exists in the catalogue but the flyer doesn’t yet meet its prerequisites or doesn’t have active currency. |
| Available | Prerequisites met and currency active — the flyer can request this skill. |
| Requested | The flyer has requested the skill; an instructor needs to approve. |
| Open | An instructor has approved and the flyer is actively working toward completion. |
| Not Current | Currency lapsed while the entry was Open — the entry is paused until currency is restored. |
| Suspended | An admin has paused the entry (rare, for irregularities). |
| Completed | Final approval signed; the skill counts toward the flyer’s level. |
| Declined / Expired / Cancelled | The request didn’t make it to approval. The flyer can re-request. |
Most logbook 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”.
Why so much state
Two reasons:
- Audit trail. Every transition is recorded with a timestamp and the actor who made it happen. Years from now, you can reconstruct exactly what was going on with a particular skill.
- Currency-aware behaviour. When a flyer’s currency lapses, the platform doesn’t delete their open skills — it just freezes them. If the flyer renews currency a month later, the skills wake up exactly where they left off.
Editing the past
Once a logbook entry is Completed, it’s effectively immutable. Editing a completed skill’s date, time, or approver requires admin intervention and leaves an audit record of who changed what and why. This is deliberate: the logbook’s value is its trustworthiness, and that erodes the moment people start tweaking history casually.
Where to read more
- The state machine in detail: Tech docs → State machines → Logbook skill lifecycle.
- The domain model used internally: Tech docs → Domain logic → Logbook DDD refactoring.