Ubiquitous language
These terms define the shared language for all code, documentation, and conversations in Baseleg. Using the correct term in the right context prevents ambiguity and keeps the codebase aligned with the domain.
When a new term is introduced in code or documentation, update this page.
People context
Member
An individual formally associated with the organisation (e.g. a club member or enrolled student). A Member is the root identity concept — all other roles build on it. A person cannot be a Student or Instructor in Baseleg without first being a Member.
Student
A Member who is receiving instruction or training. Students are associated with training records, lessons, and flight logs.
Instructor
A Member who is authorised to provide instruction and can be assigned to Bookings and Lessons. An Instructor has authorisations that determine what they can teach.
Staff
A Member who performs operational or administrative functions. Staff may be non-flying. The term covers both office staff and operations personnel.
A single person can be a Member who is simultaneously an Instructor and Staff. Roles are additive, not exclusive.
Aircraft context
Aircraft
An aircraft operated by the organisation that is (or was) available for booking. Aircraft have a registration, type, and operational status.
Registration
The official identifier of an aircraft (e.g. ZK-ABC). Unique within the system. Used as the primary human-readable reference for an aircraft.
Grounded
A state applied to an Aircraft indicating it must not be booked or flown. Grounding requires an explicit reason (maintenance, compliance, administrative). Only authorised personnel can ground or unground an aircraft.
“Grounded” is a domain state, not just a flag. The system enforces it: a Grounded aircraft will be rejected at booking time regardless of other conditions.
Available
The default operational state of an Aircraft — it can be booked and flown subject to other constraints (no conflicts, valid authorisations).
Scheduling context
Booking
A scheduled allocation of an Aircraft (and optionally an Instructor) for a Member over a time range. A Booking is the primary scheduling artefact. It carries the who, what, and when.
Time range
A start and end time defining the duration of a Booking or other time-bounded event. Conflict detection operates on time ranges.
Conflict
A state where two Bookings attempt to claim the same Aircraft or Instructor over an overlapping time range. The domain rejects conflicting Bookings.
Assignment
The act of attaching an Instructor (or Student) to a Booking. An Instructor assignment is optional; some bookings are solo flights.
Training context
Lesson
A training event — ground or airborne — associated with a Student and typically an Instructor. A Lesson may be linked to a Booking.
Flight
An actual flown event recorded in the system. A Flight may be linked to a Booking and/or a Lesson. Flights are used to build a Member’s flight time record.
Endorsement
A formal record that an Instructor has certified a Student as competent for a specific operation or rating. Endorsements affect what a Student is authorised to do.
Training progression
The accumulation of Lessons, Flights, and Endorsements that represent a Student’s journey through a training programme.
Compliance context
Currency
A compliance concept meaning “currently valid” for a specific requirement. A Member or Aircraft is current for a requirement when the relevant recency or examination is within its validity period. Examples: flight review currency, medical currency, check ride currency.
The opposite of current is lapsed, not “expired” — prefer “lapsed” in domain language.
Compliance alert
A notification raised when a currency requirement is approaching its validity end date or has already lapsed.
Document expiry
The date after which a certificate, authorisation, or document is no longer valid. Document expiry triggers compliance alerts.
Billing context
Charge item
A single billable line item representing a fee incurred by a Member. Examples: aircraft hourly rate, instructor time, landing fee. Charge items are the atomic unit of billing.
Invoice draft
An invoice that has been compiled from Charge Items but not yet issued. An Invoice Draft can be edited and recomputed before it is finalised.
Invoice
A finalised, issued billing document sent to a Member. Once issued, an Invoice should not be edited (corrections are handled by credit notes or new invoices).
Notifications context
Notification
A message delivered to a Member via one or more channels (email, SMS, in-app). Notifications are triggered by events raised in other contexts — they do not carry domain logic of their own.
Channel
A delivery mechanism for a Notification. Supported channels: email, SMS, in-app.
Delivery
The act of sending a Notification via a Channel. Delivery outcomes (sent, failed, bounced) may be tracked.
Reporting context
Report
An operational summary computed from data across one or more contexts. Reports are read-only views and do not modify domain state.
Export
A downloadable representation of data (typically CSV or similar). Exports are a special case of Report targeted at data portability.
General / cross-context terms
Organisation
The aviation organisation (flight school or aero club) that Baseleg serves. A single Baseleg instance serves one Organisation in v1. Multitenancy is out of scope.
Use case
A discrete application-layer operation that orchestrates domain logic to fulfil a user intent. Use cases live in packages/application/<context>/. Example: createBooking, groundAircraft.
Port
An interface defined by the application layer that infrastructure implements. Ports keep domain and application code free of infrastructure concerns. Example: BookingRepository is a port; BookingRepositoryD1 is the implementation.
Result
A return type representing either success or a typed domain failure. Preferred over throwing exceptions for expected business rule violations. Implemented in packages/shared/result.