Dear Diary, You Remember Nothing: I Built a Journal That Does-horizon

Harsh Srivastava — Sun, 04 Oct 2026 20:46:28 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

A journal is good at remembering what happened.

But after months of writing, it becomes surprisingly difficult to remember what kept happening.

I built Horizon, an intelligence layer on top of a personal journal. The journaling experience stays familiar, and the journal becomes more useful the longer you write in it.

Instead of only asking:

"What did I write?"

you can ask:

"What have I been repeatedly thinking about?"

"What have I been putting off?"

"What has been taking most of my attention lately?"

Horizon answers using your own journal history, and every answer links back to the entries it came from.

Who I built it for

The challenge is "Build for a Friend", and the honest answer is that the friend is me. Horizon grew out of a private journal app I built for myself, and I wanted that journal to remember things I might have forgotten: ideas I mentioned once and dropped, and things I said I would do and never did.

To show Horizon without exposing my real journal, the public demo uses a fictional student's five weeks of entries, which I wrote for this purpose.

Ask My Journal

Ask questions about your journal and get answers grounded in relevant past entries. Each answer shows the entries it is based on, with a label for how strong the evidence is. When the entries don't answer the question, Horizon says so instead of guessing.

Memory

Horizon identifies recurring ideas, goals, projects, people, interests, and topics across entries. It surfaces things you may have mentioned once and forgotten, as well as ideas that keep coming back.

Open Loops

While journaling, people naturally write things like:

"I still need to finish my portfolio."

"I should apply for that internship."

"I need to call Rahul."

Horizon identifies these unresolved intentions and tracks them over time. A loop can be marked resolved or dismissed by you, or marked finished when a later entry says it was done. Nothing is deleted, so you keep the history.

Weekly Reflection

The existing weekly page gets an evidence-backed reflection. It separates what was observed (days written, topics that came up on more than one day, things finished, loops still open) from the model-written reflection, and each pattern links to its entries.

The goal isn't to build another AI chatbot. The goal is to make a journal more useful the longer you use it.

Demo

Live Demo:
https://horizon-theta-vert.vercel.app

Demo password: hackmyfriend@7007

The demo is already seeded. It contains five weeks of fictional journal entries written for this challenge, so every feature has real history to work with. It is a separate database from my own journal, and none of my private writing is in it.

Video Demo:

A quick way to explore it:

Open the live demo and enter the password above.
Go to Insights and ask: "What have I been avoiding?" Then click any date chip to open the entry behind the answer.
Open Memory to see how often the event-discovery idea came back.
Open Open Loops to see what the writer said they'd do and never finished.
Open Weekly, scroll to Your Week, write a reflection, and compare an earlier week with the latest one.

Code

GitHub:
https://github.com/harsh373/Friend

How I Built It

Horizon is built with React and TypeScript on the frontend, Node.js and Express on the backend, and MongoDB Atlas as the data layer.

The AI system works in stages, and the model never sees the whole journal:

Journal Entry
      ↓
Extraction (topics, intentions) + Embedding
      ↓
MongoDB Atlas
      ↓
Question → Embedding → Similarity search on the server
      ↓
Most relevant entries only
      ↓
Open-weight model
      ↓
Grounded answer + links to the original entries

When an entry is saved, one model call extracts structured notes from that single entry (recurring topics, intentions, and completions) and an embedding of the entry is stored. When you ask a question, Horizon embeds the question, compares it with the stored entry embeddings, and passes only the closest entries to the model.

MongoDB Atlas stores the entries, their embeddings, memories, open loops, and weekly reflections. The similarity search runs in server code over the stored vectors, which is enough at journal scale. Atlas Vector Search would be the natural next step as the data grows.

Keeping the AI honest

A journal is the wrong place for confident guesses, so the checks are in code and not just in the prompt:

Every extracted item must include a quote that appears word for word in the entry, otherwise it is dropped.
Source entries come from the database, never from the model. The model only picks entry numbers, and the server maps them back to real dates.
Observations with no valid source are discarded, and the evidence strength (limited, moderate, strong) is computed from how many entries support it.
A weekly pattern needs at least two entries behind it.
When the entries don't support an answer, Horizon says "not enough evidence".
The model is told never to diagnose or comment on mental health, only to describe what is written.

Models

For generation, Horizon uses OpenAI's open-weight gpt-oss-20b served through Groq. For embeddings, it uses BAAI's bge-small-en-v1.5 through Hugging Face Inference. Both are hosted, because my development laptop cannot practically run a large language model.

The model name, endpoint, and API key are configuration values, and the app talks to a small provider interface, so switching to another model or host means editing configuration, not rewriting the app.

Why Does Open Innovation Matter?

A journal can contain some of the most personal information a person creates: thoughts, failures, goals, relationships, and changes in perspective.

For Horizon, AI isn't a decorative feature. It is the intelligence layer that turns a collection of entries into something you can explore over time. I chose an open-weight model because I wanted that layer to stay replaceable. The retrieval system, memory layer, journal data, and evidence checks keep working while the underlying model changes. That leaves room for different models, different inference providers, and eventually self-hosted inference when suitable hardware is available.

There is a trade-off, and I'd rather state it than hide it. Inference here is hosted, so the entries selected for a question or a reflection are sent to the inference provider. The whole journal is never sent, only the few entries relevant to the task. A fully private setup would need a self-hosted model, and this architecture is built so that move is possible.

Prize Categories

Best Use of MongoDB Atlas

DEV Community: Harsh Srivastava