Baseleg Docs
Guides · Product / v1 scope · 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

  • Person CRUD (create, read, update, deactivate)
  • Type assignment: Student, Instructor, Staff
  • Basic person 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
  • Checkout: dispatch the aircraft, record start meter readings, open a Flight
  • Return: release the aircraft, record end meter readings, report a defect (auto-grounds the aircraft), complete the Flight and Booking
  • Basic list and calendar views

Checkout/Return are fully implemented at the domain/application/D1 layers; no UI screen calls them yet — that’s the next issue on the roadmap. See user journeys for the end-to-end booking → checkout → return flow.

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
BillingUsage Events (hours flown, recorded automatically on every Return) exist as a real, persisted fact; Charge Items and invoice drafts do not yet compute from them — no pricing/rate logic, 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.

See the roadmap for the epic-by-epic backlog this scope was originally delivered against.