Skip to main content
TalentID and GKL Platform are separate systems with separate databases, but the Operator Dashboard presents them as one. This page describes every point where they touch.

​
The Two Directions

The Operator Dashboard calls TalentID directly from the browser, not through GKL API. This is different from Vivenu, where every call is proxied. The TalentID URL and a service token are compiled into the dashboard bundle at build time, so the token is visible to anyone with access to the dashboard.
Nothing joins automatically. The two systems are connected by a single identifier carried on both sides: A TalentID competitor points at a TalentID driver, that driver carries the GKL driver ID, and from there the platform can resolve the booking, the ticket and the user. This is the identifier the telemetry converter uses to ask GKL for a power level, and it is what makes timing results attributable to a paying customer rather than to a transponder. That ID does not get to TalentID directly. It is carried out to AlphaTiming in the entries CSV, held against the competitors AlphaTiming creates, and comes back in the results file that TalentID imports. See The AlphaTiming Export. If the link is missing, timing still records fine but cannot be tied back to a booking.

​
Where TalentID Appears In The Dashboard

​
Timing Page

Visible to any signed in dashboard user, including operators who are not internal staff. It lists TalentID events, filtered to those falling inside the selected GKL event, then the sessions within them and the competitors within those. For each competitor it shows lap times, positions, personal bests, penalties and notifications. The page also surfaces session comments. Operators resolve them from the dashboard, and the resolution is written back to TalentID with a reason. Because the resolving user is a GKL admin, the dashboard reads the admin’s name from GKL API to display alongside a comment resolved in TalentID.

​
Comment Types

Comments are not written by hand. TalentID raises them during the timing import, and there are two kinds: NoBookingId is the only comment type treated as an error. It means the entries CSV never carried that driver to AlphaTiming, so nothing links the timing back to a booking. Since no competitor is created, the comment is the only trace that the person raced at all.
A session record is only created when at least one competitor in that class imported successfully. If every competitor in a class lacks a booking ID, there is no session for the comments to appear on, and the class does not show up at all.

​
DAQ Page

Restricted to internal users. The nav item is labelled DAQ and the route is telemetry. It lists the same TalentID events and sessions, but requests competitors with telemetry conversion information included. That gives each run’s conversion status, which is what makes the page a view of the telemetry pipeline rather than of timing. See DAQ Upload and Conversion for what the statuses mean and Timing and Lap Splitting for how conversion works.
A run with no matched timing has no competitor, so it does not appear on this page at all. Those runs are found by querying the TelemetryData collection in TalentID for records with a null CompetitorInfo.

​
What The Dashboard Sends To TalentID

Resolving a session comment on the Timing page writes back to TalentID, carrying the reason and the GKL admin who resolved it.

​
The AlphaTiming Export

This is the mechanism the whole cross system match depends on, and it is worth following end to end, because nothing anywhere sends a driver identity from GKL to TalentID directly. It travels the long way round, through AlphaTiming. From the tickets list, an operator produces an AlphaTiming entries CSV, filtered to a specific eligible part of the event. It is generated by GKL API and downloads as a file named after the event and part. Before exporting, the dialog lets the operator adjust each entrant’s class and power. The operator then uploads that CSV to the AlphaTiming admin website, which sets up the competitors for each class in the event. Because the CSV carries our driver IDs, AlphaTiming now holds them against its competitors, and every results file it publishes carries them back out again.
1

GKL to AlphaTiming, by hand

The operator exports the entries CSV and uploads it to the AlphaTiming admin website, which creates the competitors for each class. Our driver IDs go with them.
2

AlphaTiming to TalentID, automatically

AlphaTiming, running on the timing laptop at the region, uploads the event timing JSON to the ingestion bucket every time results are published, typically as each session finishes. Because the competitors were set up from our CSV, those results carry our driver IDs. TalentID imports the file, creating events, sessions, competitors and laps.
3

TalentID back to GKL

The dashboard reads those results on the Timing page, and the imported timing triggers telemetry reconversion.
If the CSV is not uploaded before an event, or is uploaded without a driver, the timing still records perfectly well but arrives with no booking ID attached. TalentID then raises a NoBookingId comment and does not import that competitor at all, so there are no laps to show, nothing to match back to a booking, and no power level for that driver’s telemetry. See Comment Types.

​
Telemetry’s Use Of GKL API

The telemetry converter also calls GKL API, independently of the dashboard, for whether a run was on a race day and for the driver’s power level. It uses its own API key. See Where GKL API Fits.

​
Notes

  • The dashboard environment carries a timing feature flag, set only in dev by the CDK. Nothing reads it: the Timing page is gated by sign in, and the DAQ page by internal user status. The flag is vestigial.
  • Both TalentID and GKL Platform databases live on the same shared MongoDB instance, but there is no join at the database level. Every link described above is made over HTTP.

​
Key Files

Last modified on September 7, 2026