Extensions

The extensions object is a reserved namespace for capabilities not yet defined in the core specification. Its presence is optional. Its contents are implementation-defined.

A LIFE parser must silently ignore any extension field it does not recognise. It must not fail, warn, or alter its output as a result of encountering an unknown extension. This ensures forward compatibility.

This is deliberate. LIFE is designed to last. The extensions system means the format can grow without breaking existing files.

Reserved keys

The following keys are reserved for future versions of the specification. Implementations must not use them for other purposes.

Field	Type	Reserved for
polarisation	object	Electromagnetic polarisation state of each voice. Version 1.1.
phase	float	Phase offset in radians. Version 1.1.
coherence	float	Degree of coherence for laser or wave-specific outputs. Version 1.1.
spatial	object	3D spatial position of each voice source. Version 1.2.
chemical	object	Chemical frequency encoding for molecular communication research. Reserved.
origin	string	Source attribution. Instrument name, location, or spectrometer ID.

The chemical extension

The chemical extension is worth noting specifically. One of the open questions in LIFE is whether chemical signals - the kind transmitted through mycorrhizal networks beneath forests, or through volatile organic compounds released by stressed trees - can be encoded in the LIFE format.

Chemical signalling operates on frequency principles. Molecular oscillation rates are measurable. The question of whether a LIFE-style codec could bridge acoustic or electromagnetic frequencies to chemical frequencies is genuinely open.

The field is reserved. The question remains.

Example

"extensions": {
  "polarisation": null,
  "phase":        null,
  "coherence":    null,
  "spatial":      null,
  "origin":       "Spectrometer capture, dawn chorus, Burnaby BC, 2026-05-05"
}

Custom extensions

Implementations may define their own extension keys provided they do not conflict with the reserved keys above. Custom keys should be namespaced to avoid future conflicts - for example "myapp_custom_field" rather than "custom_field".

Custom extensions are ignored by parsers that do not recognise them. This is a feature, not a limitation.