> ## Documentation Index > Fetch the complete documentation index at: https://playbook.smedleygroup.com/llms.txt > Use this file to discover all available pages before exploring further. # The Domain Model > The entities GKL Platform is built from, how they relate, the identifiers that join them, and the vocabulary the rest of the documentation assumes. This page is the vocabulary. The other GKL pages assume these terms, and so does the code. ## The Central Distinction **A user is not a driver.** A user is the account holder who logs in and pays, usually a parent. A driver is the person who actually races. One user can hold several drivers, and almost every rule in the platform applies to the driver rather than the account. ## The Entities | Entity | What it is | Comes from | | - | - | - | | **User** | Account holder. Logs in, pays, owns drivers | Registration on the booking website | | **Driver** | The person racing. Date of birth, weight, height, sex, experience level, class code and power level | Created by the user, or by an operator | | **Event** | A race or test day, with its ticket types and categories | Mirrored from Vivenu by webhook | | **Ticket** | One driver's entitlement to at least one part of one event | Mirrored from Vivenu by webhook | | **Checkout** | An completed checkout | Mirrored from Vivenu by webhook | | **Transaction** | A completed transaction | Mirrored from Vivenu by webhook | | **Admin** | An Operator Dashboard login | Created by request, managed in the database | | **Configuration** | Business rules and per region settings | Edited through the dashboard | Alongside those sit `Audit`, which records changes, and the driver files and duplicate driver collections used by the dashboard's triage screens. ## What Joins Them | Link | How | | - | - | | User to Driver | The driver carries the user's ID | | Ticket to Driver and User | Set from Vivenu metadata on first arrival, then owned by us. See [How A Sale Happens](/software/developer/estate/systems/gkl/how-a-sale-happens#the-driver-linkage) | | Ticket to Event | The Vivenu event ID | | Ticket to Transaction | The Vivenu transaction ID | | Driver to TalentID | The driver's `metadata.gklDriver`, which reaches TalentID by way of AlphaTiming. See [TalentID in GKL Platform](/software/developer/estate/systems/gkl/talentid-in-gkl) | Everything is keyed on Vivenu's identifiers rather than our own, because Vivenu is the source of truth for anything to do with a sale. ## Ticket State Every ticket resolves to a state, and the Operator Dashboard is essentially a queue of everything that is not `Fine`: | State | Meaning | | - | - | | `Fine` | Nothing to do | | `NewDriver` | Attached to a driver created for this purchase | | `NoMatchDriver` | No driver could be resolved | | `DriverClassNotAllowed` | The driver may not race the class this ticket grants | | `DriverOutOfLimits` | The driver falls outside the class limits on age, height or weight | | `Problematic` | Needs operator attention | | `Warning` | Worth a look | | `Invalid` | Cancelled or invalidated | | `NoEvent` | No matching event | That triage screen is the product. A new person should understand this table before anything else. ## The Racing Vocabulary **Class code.** The racing class a driver competes in, with hard limits on age, height, weight and permitted power levels. Configured per hub region. **Power level.** A performance tier. It gates which classes a driver may enter and which kinds of race they may contest. It is also what the telemetry converter asks GKL for when filing a run. **Eligible parts.** Tags on a ticket type describing what it grants, for example a race or a practice session. Two tickets sharing an eligible part are buying the same track time, which is how conflicts are detected. A ticket is a race ticket if any of its eligible parts is a race. **Eligible classes.** Which class codes a ticket type admits. **Championship.** An event flagged as a championship, with child events. A separate configuration document maps a championship to its rounds. A championship ticket grants access to the rounds it contains, and an individual event can belong to more than one championship. ## Where The Data Lives One MongoDB database per environment, `GklPlatform_DEV` and `GklPlatform_PROD`, both on the shared instance. Collections map closely onto the entities above: `Users`, `Drivers`, `Events`, `Tickets`, `Checkouts`, `Transactions`, `Admins`, `Configurations`, `Audit`, `DriversFiles` and `DistinctDrivers`. > [!NOTE] > > There is no schema migration framework. Changes to configuration documents are applied by writing a migration script and running it by hand against the production database through Studio 3T. See [Configuring a New Hub Region](/software/third-party/vivenu/hub-deployment/development/configure-new-hub-region) for a worked example. ## Related Documentation | Page | Relevance | | - | - | | [How A Sale Happens](/software/developer/estate/systems/gkl/how-a-sale-happens) | How tickets, checkouts and transactions are created | | [Ticket Eligibility](/software/developer/estate/systems/gkl/ticket-eligibility) | How class codes and power levels are actually applied | | [Hub Regions and Configuration](/software/developer/estate/systems/gkl/hub-regions-and-configuration) | The configuration documents and what is per region | This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.