← Blog
03 / PERSONAL CURATOR INDEPENDENT PROJECT

Personal Curator

From news consumption to cumulative research.

PythonSQLiteClaude CodeJinja2

Why I built it

I started Personal Curator to deal with information overload. I wanted to read more of what mattered to me without spending so much of my day on it. I follow markets closely, but reading more news doesn't always lead to a better understanding of what's happening. Stories evolve, headlines repeat, and important context gets buried.

I wanted a way to track what changed, what mattered, and what I might have missed.

How it works

Curator brings related reports into one brief, keeps their sources and different perspectives, and connects new developments to the story so far.

Weekly, monthly, and quarterly reports build on that history, connecting developments into timelines and longer-term narratives.

Illustrative flow: different news sources come together in one brief, keeping shared facts, distinct viewpoints, open questions and source links. Later updates connect back to the same story.
Bring the reporting together. Keep the differences visible.

From collected sources to a shorter read

Before there can be a useful digest, there has to be something to read. Curator collects news into a local store, then the editorial workflow brings related material together. I want that shorter read to preserve different perspectives and enough context to help me decide which sources deserve more attention.

Conceptual workflow: source collection, normalize and store, group and compress, then a source-linked digest. Several source records converge into a brief while source links remain available.
Collection and editorial interpretation are separate stages.

The compression happens around an event, rather than by shortening each article in isolation. Related reports can contribute context, new developments, or a competing interpretation to one brief. Source links keep the path back to the reporting open. Grouping two articles about the same event is also different from removing a duplicate: both may be worth keeping because they add different things.

That is the reading experience I’m trying to build. A shorter version can lose qualifications or miss something altogether, so I still need to return to the sources and make my own judgment.

A durable boundary between interpretation and presentation

The editorial workflow produces structured report JSON. That intermediate is a durable artifact, not just a step on the way to HTML: a report can be rendered again without regenerating its interpretation.

ARCHITECTURE OVERVIEW
  1. CollectPython ingestion
    SQLite storage
  2. InterpretClaude Code
    Editorial workflow
  3. PreserveStructured
    report JSON
  4. PresentJinja2 HTML
    Source-linked reports

Editorial judgment stays separate from calculation and rendering.

Clustering and priority are assigned by the editorial skill, not by the renderer. Python handles calculations and presentation. A cached price module generates SVG charts with report-window highlights and event markers that link back to the relevant reports.

How the project evolved

The repository retains an earlier MCP retrieval backend with semantic and recency-based retrieval. The current direction shifts the center of gravity from asking for individual results to an intentional reading rhythm: daily context, weekly narratives, and longer-period reviews.

That shift is the product lesson for me: collecting more information is not the same as designing a useful way to return to it.

A personal approach

It's still a personal tool, shaped by the markets and topics I follow. I don't know whether the same reading experience would work for everyone. But building it has changed how I think about AI-assisted research: summarization is useful; preserving context across time is where it starts to become interesting.

Source code Repository access may be required.