Technical brief · engineering & hiring
Dream interpretation engine
Summary of system design, rigor, and design tradeoffs at a level appropriate for technical evaluation and planning. This is not a build specification; implementation detail lives in the product repository.
System summary
The engine is a server-orchestrated, multi-stage analysis pipeline combining large language models with structured methodology, retrieval-augmented context, and explicit safety and epistemic guardrails. It powers Dream Work in the SkyLune iOS client: users progress through a guided flow (dream text, emotional scenes, personal associations) and receive multi-hypothesis interpretations and integration-oriented outputs instead of a single dictionary-style answer.
The methodology aims to reflect depth-oriented clinical craft—personal meaning first, provisional language, multiple defensible readings—while remaining deployable software with defined session lifecycle, API boundaries, and degradable dependencies.
Architecture
Orchestrated multi-agent workflow. Analysis is not a one-shot prompt. A central orchestrator advances a discrete session through ordered stages aligned with how structured dream work is practiced: stabilize narrative, attend to feeling-tone, anchor symbols in the dreamer’s associations, then introduce curated conceptual material as support rather than authority. Specialized agents own slices of the pipeline (intake/structure, affect, associations, pattern detection, interpretation synthesis, optional amplification, integration planning, quality review, narrative summary). Each stage exposes a narrow I/O contract in structured form to keep behavior testable, auditable, and evolvable without a monolithic rewrite.
Dual retrieval (“dual-RAG”). Semantic retrieval spans multiple curated channels—conceptual material, exemplar cases, procedural guidance—so generation is grounded in an internal library aligned with the chosen methodology, not only in pretrained model prior. Retrieval is selective: it informs hypotheses and framing without collapsing output into generic archetype talk. Knowledge bases, orchestration policy, and generation are intentionally separated.
Methodology and policy layer. Interpretation is constrained by injected axioms and policies (e.g., multiple valid interpretations, non-diagnostic stance, disciplined use of archetypal vocabulary). This layer encodes product ethics as well as architecture: the system avoids false certainty and privileges the user’s own material.
Technical strengths (representative)
| Area | Demonstrated capability |
|---|
| Systems design | Explicit state machine and orchestrator; separation of retrieval, generation, and session persistence; clear API surface for a mobile client. |
| ML product engineering | LLMs applied where language and synthesis add value; structured stages where reliability and UX dominate; hybrid symbolic workflow plus neural generation. |
| RAG | Multi-source retrieval with role-specific use (facts vs. cases vs. instructions), not a single undifferentiated context blob. |
| Safety & governance | Crisis and safety awareness in the pipeline; archetype terminology gated with user-context sensitivity where relevant. |
| Quality / cost | Hybrid strategies including deterministic post-processing for known failure modes to reduce bad outputs and wasted tokens without redundant model calls. |
| Operations | Containerized service, cloud deployment, health endpoints; tolerant fallbacks when optional infrastructure (cache/DB) is unavailable. |
| Cross-stack ownership | End-to-end design: iOS session cache, encoding alignment with server models, timeouts and degraded modes suited to mobile networks. |
Design differentiators
- Epistemic design: Shipping several hypotheses plus integration steps is implemented as data structures and UI contracts, not only product copy.
- Associations as first-class inputs: User-supplied associations drive interpretation before archetypal amplification dominates—inverted relative to typical consumer “AI dream” products.
- Parameterized depth: Analysis depth (e.g., symbol count, optional amplification) maps product tiers to compute and retrieval cost without unrelated code forks.
- Constrained generation: Output stays within retrieve-then-reason boundaries rather than unconstrained storytelling.
Client integration
The iOS app maintains a local-first session artifact synchronized with the engine over HTTPS. The client implements extended timeouts for LLM-heavy steps, graceful degradation under slow network or server load, and schema-level compatibility across Swift and Python stacks—standard distributed-systems practice applied to a multi-screen flow rather than a single form post.
Scope of this overview
This page does not include full state diagrams, prompt libraries, knowledge-base contents, embedding indices, or reproduction procedures; those remain internal engineering artifacts. Implementation documentation (API routes, agent contracts, setup) and deployment context live in the repository’s dream_engine/docs/ tree and deployment notes.
Positioning: a methodology-first, retrieval-grounded, multi-agent dream analysis engine built for accountable LLM use in a consumer ritual product—designed for depth, epistemic humility, and operability rather than black-box one-shot answers.
SkyLune is a native iOS sanctuary for sky, dreams, and reflective reading. The icon is the face of the app; inside, a world map is the hub into three worlds—Astro, Dream, and Wisdom—each wired to its own SwiftUI flows and purpose-built multi-agent engines. Curated knowledge bases and ephemeris-backed detail keep the experience grounded instead of generic, so you can follow the moon, record what you remember from sleep, and sit with short daily reflections when you have a quiet minute.
