Lucid Dreaming APIKnow the source.
Keep the uncertainty.

Describe what the interface actually carries

A Lucid Dreaming API design may represent experimental cues, device observations, participant reports, or later annotations. These records can belong to the same session without making the same claim. An event saying a cue was presented does not establish that it was perceived. A self-report remains distinct from an independently recorded observation.

The research-events article links directly to a university account of controlled lucid-dream communication research and explains its limits. The purpose of this topic page is data architecture, not instructions for inducing dreams or operating equipment with sleeping participants.

Model origin before interpretation

Prefer event names that describe observable or reported actions, such as cue_presented, device_sample_received, and participant_report_added. Keep a classification or reviewer interpretation in a separate record with its own origin, configuration, and revision history.

If an estimate changes, do not alter the original observation to make it match. Preserve the relationship between the observation and the interpretation. This allows later review to reconstruct how a conclusion was reached instead of encountering an apparently certain value with its history removed.

Treat time as contextual information

Occurrence time, receipt time, and annotation time describe different events. Retain time-zone information, source sequence numbers, and known limitations of clock synchronization when they are available. Do not manufacture second-level precision for a report that only identifies a night or approximate interval.

Expect gaps and repeated delivery

An event consumer should have a documented way to recognize duplicates, delayed records, and missing sequences. Keep an event's identity stable through re-delivery. A chart should not conceal gaps by presenting an uninterrupted trace without explanation.

Attach protocol and configuration identifiers where interpretation depends on the collection procedure. Mark synthetic records explicitly and preserve that label in exports. A development fixture should never become indistinguishable from an observed session after it passes through the application.

Keep passive data access separate from control

Reading records and changing equipment behavior are different capabilities. This site offers reference material and synthetic examples, not device control or a validated research system. A team developing an operational research implementation needs the appropriate institutional, participant, and technical safeguards for that setting.

For ordinary development, a recorded synthetic session can exercise schemas, ordering, annotations, and exports without live equipment. Use the testing guide to check whether the application preserves uncertainty across its API, charts, and downloads. Use Lucid Dream API for the separate schema of a person's own journal account.