PsychDeep / Psychapp

What the prototype tries to do

The central idea is to turn scattered personal information into a structured analytical workspace. In its current form, PsychDeep can combine different sources of autobiographical data, normalize them into time-stamped items and use AI-assisted prompts to generate hypotheses about psychological patterns.

• Connected sources: Gmail, Google Drive, Google Calendar, Outlook, Microsoft 365, Teams and OneDrive can be connected through OAuth flows when enabled by the backend.
• Uploaded exports: exported files such as messaging histories or text archives can be parsed locally by the frontend before analysis.
• Temporal modelling: the app is designed around time series, periods, trend changes and trigger patterns rather than one-off interpretations.
• Psychological frameworks: the prototype experiments with dimensions such as affective valence, arousal, stress, cognitive complexity, attachment signals, cognitive biases and regulatory patterns.
• Reflective forecasting: once a profile exists, the interface can ask the model to reason about likely reactions to hypothetical situations, always as a probabilistic aid rather than a clinical conclusion.

How it works at a high level

The frontend is a React/Vite application. It lets the user select sources, upload files, connect accounts and launch analysis steps. The backend is a Node service that keeps sensitive API credentials away from the browser and exposes controlled API routes for OpenAI calls and OAuth callbacks.

The application roughly follows this pipeline: collect or connect data, parse it into normalized records, divide the records into periods, extract period-level features, synthesize a profile, identify triggers and allow a structured question-answering mode on top of the generated model. In the current version, this is an experimental architecture rather than a clinically validated workflow.

Why this is only a first sketch

A real version of this project would require more than a working interface. It would need stronger data governance, explicit consent flows, auditable prompt and model versions, clinical review, validation against known outcomes, bias testing and a clear definition of what the system is allowed to infer. The prototype is therefore best understood as a learning artifact and a design study: it explores the shape of a future tool, but it does not yet prove clinical usefulness or safety.

Technical and cybersecurity precautions

PsychDeep touches potentially sensitive personal data. That makes technical caution central to the design. Any future production version should treat emails, files, calendars, private messages and psychological notes as high-sensitivity data.

• No secrets in the frontend: API keys, OAuth client secrets and service credentials must never be exposed as public JavaScript or stored in localStorage.
• OAuth discipline: redirect URIs must be exact, scopes should be minimal and tokens should be stored only in secure, HttpOnly, encrypted server-side or cookie mechanisms.
• Data minimization: the app should request only the data required for a specific analysis and avoid unnecessary retention.
• Transport security: all production traffic should use HTTPS; mixed content and insecure callback URLs should be rejected.
• Prompt-injection awareness: documents and emails can contain hostile instructions. The backend must treat retrieved content as untrusted data, not as developer instructions.
• Auditability: important analysis outputs should be traceable to model version, prompt version, data source and date of generation.
• Deletion and revocation: users should be able to disconnect providers, revoke access and delete previously processed data.

Medical and psychological precautions

The medical risk is not only technical. A psychological model can sound authoritative even when it is wrong. It can overfit, confirm fears, exaggerate patterns, miss acute risk or produce explanations that feel precise without being clinically valid. For that reason, PsychDeep must remain framed as a reflective tool unless it undergoes formal clinical validation.

• No diagnosis: outputs should never be presented as psychiatric diagnosis, prognosis or treatment indication.
• No emergency use: the app is not suitable for crisis triage, suicidality, psychosis, intoxication, withdrawal, acute insomnia or rapidly worsening mental state.
• Professional coordination: clinically meaningful findings should be discussed with a qualified clinician, especially when medication, relapse risk or safety planning are involved.
• Uncertainty must be visible: hypotheses should include confidence, limitations and possible alternative explanations.
• Avoid self-surveillance harm: excessive tracking can worsen anxiety, rumination or compulsive checking in vulnerable users.
• Bias control: language-based inference can be distorted by mood, context, culture, language, substance use, sleep deprivation and incomplete data.

Next steps for a real project

The next meaningful stage would be to convert the prototype into a safer research-grade tool: narrower scope, explicit use cases, better consent screens, local-first processing where possible, structured export/delete controls, evaluation datasets, clinician-facing review modes and careful user experience design around uncertainty.

The long-term idea is not to build an oracle about the self. The useful target is more modest and more rigorous: a system that helps organize personal evidence, makes patterns easier to inspect and supports better conversations between the person, their own reflective process and, when appropriate, healthcare professionals.