Skip to content

3. Core Architecture Concepts

This section defines architectural principles.

Detailed runtime flow behavior is documented in Section 4.

Current implementation gaps and planned evolution are documented in Section 5 and Section 6.

3.1 Domain Separation

Event Manager is built around three domains with clear ownership boundaries and controlled data transfer:

  • Event Domain;
  • Registration Domain;
  • Timing Domain;

Each domain owns its own data model and responsibility. Cross-domain usage is done through transfer/import, not shared mutable state.

Interaction boundaries:

  • Timing Domain interacts with Event Domain;
  • Registration Domain interacts with Event Domain;
  • Registration Domain and Timing Domain do not interact directly.

3.2 Timing Domain

3.2.1 Capture and Ingestion Principle

Timing data can enter the platform through multiple channels (BLE, RFID, manual, external source), but follows one conceptual path:

  • capture/source;
  • local persistence where applicable;
  • cloud timing storage;
  • Event import for interpretation.

Channel-specific operational details are covered in Section 4.

3.2.2 Offline Reliability Principle

The timing model is offline-first for capture reliability.

  • capture must continue even when internet is unavailable;
  • synchronization to cloud resumes automatically when connectivity returns.

3.2.3 Raw Data Immutability Principle

Raw timing data is treated as immutable source data.

  • raw records are preserved as received;
  • corrections are never written back to raw records;
  • corrections happen on Event-side imported copies.

3.2.4 Routing and Subscription Principle

Cloud timing records are routed to Event via checkpoint mapping (data subscription).

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

3.2.5 Reliability and Recoverability Principle

This model is designed to prevent data loss and preserve auditability.

  • timing capture can run fully offline, with synchronization deferred until connectivity is available;
  • original timing records remain recoverable;
  • Event interpretation errors do not destroy source timing history.

3.3 Registration Domain

3.3.1 Registration-to-Event Interaction

Registration data reaches Event via transfer/import, not via direct shared entities.

  • Event receives imported copies of Registration data;
  • Event-managed participants are separate from Registration entities;
  • updates are applied through explicit re-import/re-sync flows.

3.3.2 Ownership Boundary Between Registration and Event

  • Registration owns registration forms, entries, products, and registration-side participant context;
  • Event owns event-side participants, event configuration, and result interpretation context;
  • same logical person can appear in both domains, but as domain-specific entities.

3.3.3 No Direct Registration-to-Timing Interaction

Registration Domain and Timing Domain do not exchange data directly.

  • Registration does not push data to Timing;
  • Timing does not push data to Registration;
  • both domains independently feed Event through their own transfer paths.

3.4 Event Domain as Result Authority

Event Domain is the authority for interpreted and publishable results.

  • calculation and correction happen in Event context on imported copies;
  • publishable outputs originate from Event;
  • public portal consumes Event-published results.

3.5 Operational Layer vs Ownership Layer

  • UI/navigation is optimized for operator workflows;
  • data ownership remains domain-driven;
  • this avoids coupling operational convenience with data authority.