Skip to main content

Conformance

This section explains conformance for humans.

Why Profiles?​

Different tools have different jobs:

  • XR runtime logs → real-time + FlatBuffers
  • Biosensing research → heavy metadata, no robotics
  • Robotics control → agent output + real-time streams
  • CV training pipelines → big external media

Profiles let each tool adopt MIND in the way that makes sense.

The Core Profile​

Every MIND file must meet the Core Profile.

This guarantees:

  • valid streams
  • valid metadata
  • valid events
  • correct timestamps
  • schema consistency

If something fails Core Profile validation, it is not a MIND dataset.

Extensions​

Extensions add new capabilities.

Tools say which ones they support.
Datasets say which ones they require.

If a dataset requires something the tool doesn't support → fail.
If a dataset only suggests something optional → ignore safely.

Required vs Optional Features​

Some features are essential (required), some enhance interpretation (optional).

Examples:

  • Required: HandPose
  • Optional: FingerContact

This gives tools freedom while preserving correctness.

Error Classes​

Errors are named so tools can report them clearly:

  • UNRESOLVED_REFERENCE → “Stream references missing metadata”
  • TIMESTAMP_VIOLATION → “Time goes backward”
  • SCHEMA_MISMATCH → “Data doesn't match modality schema”

This helps developers debug quickly.

Machine-Readable Tests​

Tools can validate themselves using official test files:

  • valid → should pass
  • invalid → should fail
  • warnings → should parse with notes

This helps standardize the ecosystem.

Versioned Profiles​

Profiles are versioned just like modalities and metadata.

This lets us evolve:

  • XR profiles
  • Biosensing profiles
  • Robotics profiles
    independently.

Compatibility Levels​

Tools declare their level:

  • Core (minimal)
  • Full (all core features)
  • Complete (including advanced ones like streaming, compression, extensions)

Think of it like a capability badge.

Forward/Backward Compatibility​

MIND is designed to avoid breakage:

  • Ignore unknown optional extensions
  • Keep deprecated fields valid for a full major version
  • Accept future minor versions
  • Only fail on incompatible major versions

This is essential for long-lived datasets.