Northbound Notes
A morning briefing that writes itself
A daily email I use to start the morning: Toronto weather, news, developments in AI, and a small selection of stories worth a closer look. Built with AI to bring some structure to a noisy information feed.
A calmer start to the morning
Start with the real need
The problem was not access to information. It was beginning each morning with too many sources, no clear order, and no reliable stopping point. I wanted one short briefing that could tell me what happened, preserve the source trail, and leave me to decide what deserved a deeper read.
How I shaped the product
A scheduled workflow gathers a small set of recurring inputs, researches the day, drafts a briefing, and delivers it by email. The format is deliberately constrained: local context first, then important developments, then a short selection rather than an exhaustive feed. I use the result myself, which makes weak selection and awkward writing visible quickly.
Decisions that mattered
Constrain the output
A fixed structure and short reading time create a real editorial standard. More stories would make the automation look busier while making the product less useful.
Keep sources close
A summary is only useful when I can inspect the underlying reporting. The briefing is a map into the news, not a replacement for it.
Treat tone as part of quality
A technically correct feed can still be exhausting. The draft has to sound like a calm briefing rather than a pile of search results stitched together.
What this does not prove
- Selection is subjective and can reflect the biases of the sources and instructions.
- A fluent summary can still omit context or state a claim too confidently.
- Daily personal use is useful feedback, but it is not evidence that the format works for a wider audience.
How I would strengthen the evidence
- 01Record which items lead to a deeper read and which are consistently skipped.
- 02Add clearer handling for disagreement between sources.
- 03Test whether a second reader would make the same keep-or-cut decisions.
Interested in the reasoning behind the build?
I share the decisions, failed assumptions, and useful lessons as the work develops.