Tunnel booking rules

A booking is a scheduled chunk of flight time for a specific member at a specific tunnel on a specific date. The IBA doesn’t run tunnels or own the booking workflow — it accredits the people, validates them at check-in, and (in some integrations) records the resulting flight in the member’s logbook.

Three booking-system contexts

The rules differ by which system the tunnel uses:

Tunnel type	Booking system	What the IBA does
USA tunnels	Convergence	Validate at check-in; receive booking events; create logbook entries automatically.
Non-USA integrated tunnels	FuzeMetrix	Validate at check-in only. Logbook entries via other paths.
Coming soon (USA + global)	Tunn3l	Not yet integrated.
Non-integrated tunnels	(none)	Members log their own flight time; instructors approve manually.

The currency split (the load-bearing rule)

The most consequential rule in any booking integration is the currency split:

Member’s flyer currency at booking time	Logbook entry created?	Email sent
Active	Yes — entry created automatically	”Active” template — confirmation + one-time edit link
Not current	No — entry suppressed	”Inactive” template — recurrent training required first

This is deliberate. If the IBA created entries for not-current members, those flights would silently count toward re-establishing currency — which is the opposite of what the cycle is for.

Validation at check-in (any integrated system)

Before a flight, the integrated tunnel hands the IBA a flyer’s member ID and IBA PIN. The IBA responds with:

Whether the member is valid (Group 1 / 6 / 11 / etc., not banned, not pending).
Their current standing — level, currency status.
A name to display at the tunnel.

This is what stops a non-member from showing up at a tunnel and pretending they’re qualified. It’s also what enforces the Member lifecycle gates at the tunnel boundary: a Group 2 (banned) member returns not-found; a Group 4 (pending verification) member returns not-found; only fully-onboarded members get a positive validation.

What integration adds beyond validation

Capability	Convergence	FuzeMetrix	Tunn3l
Member validation at check-in	✅	✅	(planned)
Member-specific custom booking links	✅	—	TBD
Group-based affiliate-store pricing	✅	—	TBD
Auto-create logbook entry on completed booking	✅	—	TBD

For Convergence, member-specific pricing flows from the member’s Convergence group (a tier derived from booking history). See Overview → Convergence for that part of the flow.

End-to-end booking flow


Member books flight at integrated tunnel
   │
   ▼
Tunnel validates IBA member ID + PIN  ──►  IBA responds with member status
   │
   ▼
Flight happens at the tunnel
   │
   ▼
(Convergence only:) Tunnel reports actual flight time back to IBA
   │
   ▼
IBA checks flyer currency
   │
   ├── current ──► Logbook entry created, "active" email sent
   │
   └── not current ──► No logbook entry, "complete recurrency" email sent

The reporting back step happens automatically for Convergence; for FuzeMetrix and Tunn3l (when live), logbook entry creation is via other paths.

Sub-page

Tunnel booking sequence — full sequence diagram of the booking lifecycle including the integrated-system swim lane.