Backend modules
Module map
Business ownership, shipped capabilities, scaffolds, and cross-module journeys.
The module map follows business ownership, not technical layers. A module's
living docs/shipped.md inventory is authoritative.
Business modules
| Module | Owns | Status |
|---|---|---|
referential | Carriers, fleet, permits, topology, service catalog, schedules, authorizations, imports | Advanced — 29 capabilities |
rules | Product-declared domains and effective-dated policy versions | Shipped — 2 capabilities |
siv | Display points and reusable presentation profiles | Shipped — 2 capabilities |
allocation | Vehicle and bay commitments for dated departures | Scaffold |
billing | Vehicle-stay invoices, settlement, disputes, evidence | Scaffold |
cycle | Observed vehicle visit and physical movement | Scaffold |
scheduling | Dated departures generated from schedules | Scaffold |
supervision | Operational projections, alerts, operator actions | Scaffold |
ticketing | Inventory, sales, tickets, refunds, boarding, cash sessions | Scaffold |
Platform modules
| Module | Contract |
|---|---|
common | IDs, time precision, query helpers, connection parsing |
web | Errors, validation, request context, OpenAPI customization |
security | JWT resource server, authority mapping, capabilities, CORS |
messaging | Envelope, publication registry, Kafka externalization and consumption |
testing | Shared Testcontainers integration harness |
audit | Reserved boundary; no shared implementation shipped yet |
Cross-module journeys
The arrows are API or event collaboration. They never authorize table access.
Capability status rule
“Scaffold” means the module compiles and has planned ownership. It does not mean its workflows exist. A capability becomes shipped only when the living inventory names behavior, surface, guarantees, limits, and proof.