4. Data Movement

This section describes runtime data flow sequences.

Architecture principles and ownership rules are defined in Section 3.

4.1 Flow Boundaries

• Registration and Timing do not exchange data directly;
• both flows terminate in Event domain;
• Public Results Portal consumes published data from Event.

4.2 Registration → Event

Typical trigger:

• manual import;
• scheduled/automated sync flow.

Processing model:

• Registration data is transformed into Event participant context;
• Event stores its own participant objects;
• this is snapshot-based transfer, not live shared state;
• current operational baseline is export from Registration and manual import into Event.

Edit-lock behavior after transfer:

• in registration configuration (from the start), organizer defines whether participants are allowed to edit their own application;
• once a participant is transferred to Event, editing in Registration is locked for the transferred scope to prevent cross-domain conflicts;
• after transfer, participant corrections should be handled in Event context, not by modifying already transferred registration data.

Multi-event registration behavior:

• edit lock is applied only to the specific stage/event where the participant was transferred;
• for other stages not yet transferred, participant edits can still be allowed if organizer settings permit it.

4.3 Timing Devices → Timing App → Cloud Timing Storage → Event

Supported capture channels:

• BLE timing;
• RFID timing;
• manual timing;
• external source timing.

Flow:

1. device/source (RFID/BLE/manual/external source) produces timing records;
2. records are persisted locally where applicable and sent to Cloud Timing Storage;
3. cloud checks checkpoint mapping (data subscription) for Event routing;
4. mapped records are forwarded to Event checkpoint storage;
5. Event recalculates results.

Cloud retention behavior:

• mapped records are forwarded to Event and retained in cloud storage;
• unmapped records remain only in cloud storage until mapping is configured.

Operational notes:

• Session start modes

  • file-based mode: create new file or continue existing file;
  • checkpoint-bound mode: select event + checkpoint directly;

• Offline behavior

  • both modes support offline capture after session start;
  • offline session start is possible only in file-based mode;
  • checkpoint-bound mode requires internet only at start/binding;
  • if internet drops later, records are synced automatically when connectivity returns;

• Ownership model

  • in file-based mode, cloud file owner is the timing operator;
  • in checkpoint-bound mode, ownership is bound to event context;

• Routing rule

  • Timing → Event propagation requires checkpoint data subscription mapping and required permissions;
  • cross-domain synchronization is one-way by design, so Event-side corrections are not written back into source-domain records;

• Cloud retention and mapping edge-cases

  • cloud records are always retained; if data subscription is not configured, records are not routed to Event;
  • with sufficient permissions, one file-based cloud log may be mapped to multiple checkpoints (edge-case);
  • file-based cloud logs may also be mapped across checkpoints from different events (edge-case);

• Manual import path

  • timing data can also be manually imported directly to an Event checkpoint.

4.4 Event → Public Results Portal

Flow:

• Event maintains up-to-date result state as new data arrives;
• Public Results Portal (frontend app) requests results from backend endpoints;
• users consume race outcomes via public pages.

Portal output is request-driven (refresh/poll behavior): each request returns the latest available data for the selected query.

Typical query filters include:

• age group or category filters;
• placement ranges (for example, top 100);
• event/race/checkpoint context.
• detailed results for an individual participant.