RSS Amplifier

Federica’s Substack · Jun 16, 2026

Notes on Data and Learning — N.23

0
Sign in to vote or save

Federica Gazzelloni · Federica’s Substack

When Priorities Choose Themselves

This week was supposed to be about organization.

Instead, it became a lesson in how priorities emerge.

Much of my time was spent around books: reviewing chapters, checking reviewer comments, validating data, and deciding what required attention first. At the same time, several unrelated activities continued demanding space. Research questions kept generating new directions. Notes accumulated across projects. Mortality analyses opened new lines of investigation. None of these activities appeared particularly urgent in isolation, yet together they created a familiar challenge: deciding what deserved attention before everything else.

What became visible was that priorities rarely emerge from planning documents alone.

They emerge from constraints.

A deadline immediately changes the structure of a project. Activities that appeared equally important suddenly become ordered. Work that could wait is pushed aside. Work that cannot wait becomes visible. This week, book reviews acted exactly like that. One review generated a correction. The correction required checking a source. The source raised a methodological question. The question led back to another project. What initially looked like separate tasks gradually revealed themselves as part of the same chain of decisions.

This was also the week where I spent more time working inside Obsidian.

How deadlines, reviews, data validation, and research questions reveal what deserves attention next.

I have already written about Obsidian as something more than a note-taking environment. What became interesting this week was not the ability to store information, but the ability to expose relationships that would otherwise remain hidden. Looking at the graph view, I was struck by how often apparently unrelated projects were connected through common references, recurring concepts, or shared decisions. A note written for one project suddenly appeared relevant to another. A methodological question linked back to a source I had not revisited in months. The graph did not create these connections. It simply made them visible.

That distinction became important because visibility changes behaviour.

Once relationships become visible, priorities begin organizing themselves. The next task is no longer chosen from a list. It emerges from understanding which decisions depend on which other decisions.

What made this particularly interesting was combining Obsidian with Codex. Rather than asking an AI system to write content, I increasingly found myself asking it to reason about structure. Which notes belong together? Which concepts continue appearing across projects? Which parts of the vault are becoming disconnected from active work? The value was not automation alone. The value came from having another system capable of identifying patterns that remain difficult to notice while operating inside the work itself.

A different reflection emerged while reviewing data.

During the week I encountered a dataset that contained errors. Discovering the issue itself was relatively straightforward. The more difficult question came afterwards.

What should happen once you find something wrong?

Finding an inconsistency is a technical exercise. Explaining it is something else entirely. How certain should the evidence be before raising a concern? How should the issue be communicated? How much context is necessary for someone else to understand why the problem matters? At that point the challenge is no longer statistical. It becomes a question of trust, interpretation, and responsibility.

This struck me because the same pattern appears repeatedly in reviews.

Whether reviewing a manuscript, checking a dataset, or validating an analysis, the objective is rarely identifying mistakes for their own sake. The objective is understanding how those mistakes influence the conclusions built on top of them. An isolated error matters less than the relationships that emerge from it.

Much of the week was also spent looking at mortality data, particularly deaths involving multiple contributing conditions. What initially captured my attention was the number of younger individuals affected by multiple sclerosis and the continuing discussion around possible causes and triggers. Yet the more I explored the literature, the less interesting any single cause became.

What emerged instead was a familiar pattern.

Outcomes rarely arise from isolated factors. Conditions interact. Risks accumulate. Biological, environmental, behavioural, and social influences operate simultaneously. By the time an outcome becomes visible, it often reflects a network of relationships rather than a single identifiable cause.

That observation felt surprisingly close to everything else I had been working on.

In Obsidian, the interesting question was not which note existed, but which notes remained connected.

In data review, the interesting question was not which value was wrong, but how that error influenced downstream interpretation.

In mortality analysis, the interesting question was not which condition appeared on a certificate, but how multiple conditions interacted across a person’s life course.

Different domains were revealing the same underlying principle.

Relationships matter more than isolated observations.

A Working Position

Looking back, this week appeared fragmented on the surface. Books, reviews, project organization, mortality analysis, and data validation seemed unrelated when viewed individually. Yet they all revolved around a similar activity: understanding how separate pieces of work remain connected.

Perhaps this is why priorities so often emerge without permission.

The next task is rarely chosen because it was written at the top of a list. More often, it appears because another piece of work depends on it. Deadlines reveal dependencies. Reviews expose hidden assumptions. Research uncovers unexpected questions. Connections become visible only after enough structure exists to support them.

The difficult part is rarely deciding what to do.

The difficult part is seeing clearly enough to understand what must happen next.

Read the original on federicagazzelloni.substack.com

Comments

Nothing yet. Say the first thing.

    Sign in to join the conversation.