Baseleg Docs

v1 scope

v1 focuses on the operational spine: People, Aircraft, and Scheduling. Everything else is scaffolded but intentionally lite until the spine is working reliably.

In scope

People

  • Member CRUD (create, read, update, deactivate)
  • Role assignment: Student, Instructor, Staff
  • Basic member profiles with contact information

Aircraft

  • Aircraft CRUD
  • Grounded / available state transitions
  • Grounded protection (prevents booking a grounded aircraft)

Scheduling

  • Booking creation with aircraft and optional instructor/student assignment
  • Conflict detection (no overlapping bookings for the same aircraft or instructor)
  • Booking cancellation
  • Basic list and calendar views

Platform

  • Simple operational dashboard
  • Basic loading, empty, and error states in every view

Lite (scaffolded, intentionally shallow)

These contexts are present in v1 but are not a delivery focus:

ContextWhat’s included in v1
TrainingLesson model and basic UI; no full progression
ComplianceBasic alert model; no automated rule evaluation
BillingCharge items and invoice drafts; no payment processing
NotificationsNotification delivery adapter; minimal trigger coverage
ReportingBasic operational views; no exports or analytics

Explicitly out of scope (v1)

These are ruled out for v1 and should not be designed for:

  • Full billing and payment processing
  • Full multitenancy (organisation isolation)
  • Real-time collaboration or live updates
  • Complex reporting and analytics
  • Event sourcing
  • Microservices or service extraction
  • CQRS everywhere
  • Automated compliance rule evaluation
  • Integration with external training syllabus systems

Rationale

The v1 scope is deliberately narrow. The goal is a reliable, well-bounded operational spine before adding complexity. Building a trustworthy booking system with conflict detection and grounded-aircraft protection provides immediate value to a small flight school, without the operational overhead of premature features.