Skip to main content

​
High-level system description

A Django REST backend with PostgreSQL, with two clients: the main React web application and a separate offline-first PWA used by inspectors in the field. Bulk data arrives through an ingestion pipeline that writes to the database on its own validated path.

​
Domain layers

Internally the backend is organised in layers of Django applications. Dependencies generally point downward: a higher layer uses what is below it, and the layers below do not depend on the modules above.
1

Foundation

Users, projects, and shared plumbing. Who can log in, which fleets they have access to, and the conventions every other part of the system follows. Always present, never visible as a feature in its own right.authentication · user · projects · common
2

Fleet registry

The assets. Vehicle types, the standardised product-group hierarchy, component types, mounting positions, and then the actual vehicles and components in service. This is the backbone — nearly everything else attaches to a vehicle or a component.assets
3

Modules

The working areas. Each adds records that point back at the fleet registry beneath it.servicebook · defects · warranty · measurements · planner · inspections · high_value_components · strategic_kpi · askai
The modules are not independent of each other. defects builds on servicebook, warranty and strategic_kpi build on defects, and askai reads across most of the others.
The downward rule holds for module-level imports but is not absolute. common reaches up into assets and inspections in a few places, using function-local imports to avoid circular-import errors at load time.
The Pages tab follows the application’s own sidebar. What a user sees depends on their assigned roles. Field inspections happen in a separate inspector app rather than in the web application.

​
Data origin

Data can enter the platform in three distinct ways.
The definitions admin sets up: vehicle types, the product-group hierarchy, component types, mounting positions, measurement types and their thresholds, inspection templates. Created and edited in the web application.
The work the platform is actually for: warranty claims and their approval history, component repair-loop updates, inspection findings, maintenance plannings, comments and attachments. Created through the web application or the inspector app.
The daily operational record: defects, odometer readings, mount and dismount events, performed maintenance, measurements, out-of-service periods, cleaning. These arrive as CSV exports from other systems and are read-only inside the platform — they cannot be edited in the application, because the next import would overwrite the change.
Database structure explains the data structure in details, and the file format pages describe exactly what each csv file must contain.

​
Environments

Production runs in its own Azure subscription, behind an Application Gateway WAF with the application tier network-isolated and the database reachable only over a private endpoint. A separate development environment is public and holds test data only. See Environments for the topology, security posture, recovery guarantees, and what an integrating system needs from each.