Approval levels

Approval levels are the IBA’s enforcement mechanism for “this person is qualified to sign for that”. The platform stores each member’s approval authority per programme and consults it every time a logbook entry, currency event, or assessment outcome needs a signature.

This is what makes IBA credentials portable: the rules are uniform across every tunnel and every interaction.

What’s stored

Each member record carries an approval level per programme:

Examiners aren’t stored as a separate approval_level_examiner field in the same shape — examiner authority is treated as the highest tier above trainer (verify against current schema if implementing).

How approval levels are derived

Approval levels are not free-form admin inputs. They’re derived from the underlying skills and currency on file:

1. Skills granted. A member needs the corresponding role’s skills in their logbook (Instructor Level N skill → eligibility for approval_level_instructor = N).
2. Currency active. The role’s currency must be active at the moment of signature (instructor currency, trainer currency, etc.).
3. No administrative suspension. Group 2 (banned/deleted) overrides everything; suspended members have effective approval level 0.

When a member completes a skill that elevates their authority — say, passes their Instructor Level 3 skill — the platform recomputes approval_level_instructor and only updates the field if the new authority is strictly higher than the current value. Approval level doesn’t drop when individual skills lapse; it only drops when currency lapses (in which case the effective approval level is 0) or when an admin intervenes.

The derivation rule (instructor example)

For an instructor:

new_approval_level = max(
  current_approval_level_instructor,
  highest Instructor Level skill currently in logbook
)

effective_approval_level = currency_active ? new_approval_level : 0

In words: the stored approval level is monotonically non-decreasing across a session of skill acquisition (you don’t lose authority by completing more skills). The effective approval level collapses to 0 when currency lapses, even though the stored value is preserved.

Who can approve what (the full matrix)

This is the canonical “is this signature valid?” check.

Where the rule is enforced

The approval-level check happens in three places:

1. At skill request time — when a flyer requests a skill, the platform checks whether the requested approver (selected at the tunnel) holds the required approval level. If not, the request is blocked before reaching the approver.
2. At skill approval time — when an approver signs a logbook entry, the platform re-checks the approver’s effective approval level at the moment of signing. This guards against authority lapsing between request and approval.
3. In aggregate consistency checks — periodic admin tools surface logbook entries where an approver’s level at sign-off was below the threshold (rare; should never happen but worth checking).

Once an approval lands, it’s tied to the approver’s level at that moment. If the approver’s authority later changes — they retire, their currency lapses, etc. — previously-granted approvals are not retroactively invalidated. The signature was valid when made.

Cascading effects of a currency lapse

When a member’s currency lapses, their effective approval level across that programme drops to 0:

• An instructor whose currency lapses → can’t approve any flyer skills until renewed.
• A trainer whose currency lapses → can’t certify new instructors until renewed.
• An examiner whose currency lapses → can’t run assessments until renewed.

The stored approval_level_* field doesn’t change. When currency is renewed, the member resumes operating at the same approval level they had before the lapse.

Special cases

Coach as a flag, not a role_id

Coach approval lives on a flag in the member record, not under role_id = 7 (deprecated). A member can be role_id = 8 (instructor) AND have the coach flag set, in which case they have two independent approval scopes that are checked separately based on what’s being signed.

Military approval

Military approval level (approval_level_military) is checked only for military-flagged skills against military-flagged members. A civilian instructor with military authority off can’t sign for a military skill; conversely, a military trainer signing a civilian flyer skill needs the regular instructor approval-level check, not military.

Administrative override

role_id = 1 (administrator) can grant approvals on behalf of the correct authority via the admin console — this is a deliberate escape hatch for edge cases (e.g. an instructor’s currency lapsed unfairly mid-session due to a clock skew bug). Every admin override is logged in the audit trail as such, so it’s traceable but not invisible.

Anti-patterns

Things the platform doesn’t allow:

• Self-approval — a member can’t approve their own logbook entry even if they hold the authority for it.
• Cross-currency approval — an instructor whose currency is active but whose flyer currency lapsed cannot approve their own next flyer skill (they need an external instructor for it).
• Future-dated signatures — approval timestamps must be at or before the system clock at sign-off; backdating requires admin override.
• Approving above your stored level via “I think they’re ready” — the stored level is the ceiling. There is no informal escalation.

See also

• Currency — how the active/inactive flag feeding into “effective approval level” is managed.
• Skill levels — what skills make up each level, and which programme they live in.
• Logbook lifecycle — how the state-machine pauses entries when an approver’s authority becomes insufficient.
• For the engineering-level reference (table fields, cron behaviour, query patterns), the canonical doc is the API source itself; a curated reference will land under /api/conventions/ once the API Use-Case refactor stabilises.