Skip to main content

Time and Timestamps

This section is normative.

The MIND Standard is designed to support high-precision, multi-device, real-time and offline processing of human data, including motion capture, computer vision, XR devices, and biosensors (e.g., EEG), as well as real-time agent output for virtual and robotic embodiments. Accurate and consistent timing across these sources is essential.

All rules in this section apply to every timestamp used in Containers, Streams, Samples, and Events.

Clock Domains​

MIND uses multiple clock domains to support robust synchronization.

A timestamp object in MIND MUST support the following fields:

  • t_monotonic (required)

    • A monotonically non-decreasing device or process-local clock.
    • Unit: integer microseconds.
    • Epoch: implementation-defined but consistent within a Container.

  • t_system (required)

    • A wall-clock time aligned to a real-world time scale (e.g., Unix epoch).
    • Unit: integer microseconds since Unix epoch (1970-01-01T00:00:00Z), unless otherwise specified by a Container-level metadata flag.

A timestamp object MAY additionally contain:

  • frame
    • A non-negative integer frame counter, typically for video or fixed-rate capture.
  • sample_index
    • A non-negative integer representing the sample index within a fixed-rate stream.
  • additional_clocks
    • A map from string clock names to integer values (microseconds or device-specific units) for specialized hardware (e.g., FPGA ticks, sensor-specific clocks).

If present, additional_clocks entries MUST NOT conflict with t_system or t_monotonic in meaning.

Required Fields and Resolution​

Every Sample MUST include a timestamp object containing at least:

  • t_monotonic, and
  • t_system.

This dual-clock requirement supports high-precision ordering and cross-device alignment.

Resolution​

All required timestamp fields (t_monotonic, t_system) MUST be representable at microsecond resolution or better:

  • Devices with lower native resolution (e.g., milliseconds) MUST up-sample their timestamps into microseconds without violating the monotonicity requirements in Section 4.3.
  • Devices with higher resolution (e.g., nanoseconds) MAY store full precision by:
    • using microseconds plus an additional offset field in additional_clocks, or
    • internally scaling to microseconds with documented behavior.

Per-Stream Ordering​

For each Stream, Sample timestamps MUST be non-decreasing with respect to t_monotonic:

  • For any two consecutive Samples S_i and S_{i+1} in a Stream:
    • S_{i+1}.timestamp.t_monotonic >= S_i.timestamp.t_monotonic.

Identical timestamps (e.g., for multi-sensor fusion or batch output) are allowed, but implementations MUST NOT rely on insertion order to imply additional temporal ordering when timestamps are equal.

Cross-Stream Alignment​

A Container is intended to support multi-device and multi-modality fusion, including:

  • mocap + video + XR devices,
  • biosignals (EEG, EMG, etc.),
  • real-time agent outputs.

To enable this, all Streams in a Container MUST be mutually alignable via their timestamp information.

Specifically:

  • All Samples MUST include t_system and t_monotonic as defined above.
  • For Streams originating from different physical devices, the Container MUST include enough metadata (e.g., per-device time offset or sync procedure descriptions) to allow reconstruction of a consistent global timeline.

If such alignment metadata is missing or inconsistent, the Container MUST be considered invalid for conformant MIND tools.

The precise structure of alignment metadata may be defined in satellite specifications or extensions (e.g., a “DeviceSync” metadata type), but the requirement to provide sufficient information is core.

Derived Timestamps and Provenance​

Recorders and processing pipelines MAY generate or adjust timestamps when device clocks are inadequate or missing, provided that provenance is explicitly tracked.

When any timestamp field is derived or modified by a component other than the original device:

  • The Container or Stream MUST record provenance information indicating:
    • Which fields were derived or adjusted.
    • Which process or tool performed the derivation.
  • Implementations MUST NOT represent derived timestamps as raw device outputs in user-facing diagnostics without indicating their derived status.

Satellite specifications MAY define a standard metadata structure for timestamp provenance (e.g., TimestampProvenance).

Video, Frame-Based, and High-Rate Biosignals​

For frame-based and high-rate biosignal sources (e.g., video, EEG, EMG):

  • Streams SHOULD use frame and/or sample_index in addition to t_monotonic and t_system, to support:
    • deterministic indexing,
    • efficient random access,
    • alignment with external tools (e.g., video editors, EEG toolchains).

The combination of t_monotonic and frame or sample_index MUST remain consistent:

  • A given frame or sample_index value in a Stream MUST always correspond to the same timestamp within a Container.

4.7 Event Timestamps​

Events (EventPoint and IntervalEvent) MUST use the same timestamp object structure as Samples:

  • Every EventPoint MUST include t_monotonic and t_system.
  • IntervalEvent start and end MUST respect:
    • start.timestamp.t_monotonic <= end.timestamp.t_monotonic.

When Events reference Samples from multiple Streams, implementations MUST use the timestamp model defined here to resolve temporal relationships (e.g., which Sample was “active” at the Event time).

4.8 Summary of Timing Invariants​

All conformant MIND data MUST satisfy:

  1. Every Sample and Event has a timestamp with t_monotonic and t_system.
  2. Required timestamp fields use microsecond resolution or better.
  3. Per-stream timestamps are non-decreasing in t_monotonic.
  4. Streams within a Container are mutually alignable via timestamp information and metadata.
  5. Derived timestamps are explicitly tracked via provenance.
  6. Frame-based and high-rate biosignal Streams use frame/sample indices consistently when present.

This completes Section 4.