Lucid Dreaming API design: separate research signals from self-reports
An evidence-aware event model for teams documenting dream reports, experimental cues, observations, and uncertain classifications.
LUCID API LAB / TOPIC THREAD
Dream data
Keep the origin attached.
Keep the origin attached.
Dream data can refer to original journal text, a self-reported experience, a generated summary, or a research-related observation. This thread keeps those categories distinct while showing how an application can link them through source identifiers, revisions, and documented meanings.
Begin with the journal-schema guide for records that preserve unknown values. Continue to faithful summaries before adding optional AI transformations. The research-events article introduces a separate event model for observations and annotations. Across all of them, inspect what happens when an account is corrected or deleted: related information should not lose its provenance simply because it moved into another component.
CONNECTED READING04
Field guides following
the dream data thread.
Follow this thread
Lucid Dream AI: build faithful summaries without inventing meaning
Separate extraction, summary, and reflection so generated text remains grounded in the account the user actually provided.
Lucid API architecture: start with the contract, not the model
A practical starting point for separating dream records, AI transformations, and agent actions into an understandable API.
Designing a Lucid Dream API: a journal schema that preserves uncertainty
Model dream reports, revisions, consent choices, and generated annotations without turning missing information into false certainty.