How CEDM Works
A technical overview of the Cognitive-Emotional Data Manipulation engine — its architecture, state model, and how it processes interactions.
From Input to Neurochemical Context
CEDM sits between the application layer and the language model. When a message arrives, it passes through the CEDM engine first — which reads the current session state, processes the incoming signal, updates the neurochemical context object (serotonin, dopamine, cortisol, and related signals), and constructs a context-enriched prompt before forwarding to the model.
The model's response is returned to the application alongside the updated CEDM state object — giving the application full visibility into the current neurochemical context without needing to infer it from raw text. High cortisol narrows Eden's options and slows pacing. High dopamine opens curiosity. Low serotonin pulls tone toward caution.
The CEDM Processing Pipeline
Message ingestion
The raw user message is received by the API. A session is identified by user_id, and the existing CEDM state for that session is loaded.
Signal extraction
The engine analyses the incoming message for cognitive and emotional signals — tone, sentiment, urgency, and contextual markers — without relying on a separate classification model.
State update
The extracted signals are applied to the current CEDM state object. The state evolves incrementally across turns, accumulating context rather than resetting each time.
Prompt construction
The updated state is used to construct a context-enriched system prompt. This prompt shapes how the language model interprets and responds to the user's message.
Response + state delivery
The LLM response and the current CEDM state object are both returned to the calling application. The application can use the state to drive UI, logging, or downstream logic.
The CEDM State Object
The CEDM state is a structured JSON object representing the current neurochemical context of a session. It models serotonin, dopamine, cortisol, and related signals — updating with each interaction and accessible via the API.
Each field has a defined meaning and a bounded value range, making the state interpretable for logging, auditing, and downstream application logic. The tone field provides a human-readable summary of the current state.
What CEDM Is — and Is Not
Stateful by design
CEDM maintains session state across turns. Each interaction builds on the last, rather than treating every message as an isolated event.
API-first, not embedded
CEDM is a standalone service. It does not require modification of the host application's model or infrastructure — it integrates at the API boundary.
Interpretable outputs
The state object uses bounded numeric fields and defined string enumerations. Outputs are designed to be readable by both developers and downstream systems.
Early-stage prototype
CEDM is a working prototype. The state model, signal extraction logic, and API surface are under active development. Claims about accuracy or clinical utility are not made.
Current Development Status
The CEDM engine is a functional prototype. The core pipeline — message ingestion, modeled signal extraction, state update, and response delivery — is implemented and accessible via the API. The computational signal model and its methods are subject to revision as the prototype matures. No clinical validation, regulatory approval, or production deployment has occurred. Patent pending.
View API ReferencePrototype Notice
CEDM is an experimental computational framework. Its outputs represent modeled computational signals and should not be interpreted as medical diagnoses, psychological assessments, or direct measurements of human neurochemistry or physiological activity. Eden.AI is an early-stage prototype under active development.