Files that change together

Some files travel in pairs. A route and its validator. A migration and the type that mirrors it. A component and the token file it reads. Nobody writes that down, and it is rarely visible in the folder structure, but everyone on the team knows it after a few months.

Pathrule learns it from the work itself. When your agents log what they did, each entry carries the paths it touched. If two paths keep appearing in the same piece of work, Pathrule records that they change together and gives that relationship a weight.

What it does for retrieval

Path scope and meaning-based matching both start from where you are. Co-change adds the files next to it.

When the assistant is working in /apps/api/payments/refund.ts, retrieval already considers what is pinned to that path and what matches the intent. Co-change lets knowledge attached to the paths that habitually move with it rise as well. So a rule about the ledger writer can reach a session that never mentioned the ledger, because in this codebase refunds and the ledger have always been edited together.

This matters most for the knowledge nobody thought to attach in two places. A decision recorded once, on the file where it was made, still reaches the sessions that need it.

How the relationship is measured

A pair counts when both paths appear in the same logged piece of work. Sharing a folder is not enough, and neither is being changed on the same day by different tasks. The unit is one piece of work, because that is what indicates a real dependency rather than a coincidence of layout.

Weights are rebuilt from a rolling window of recent activity. On every rebuild, existing weights decay and fresh observations are added, then pairs that fall below a noise floor are dropped. The effect is that a relationship which stops happening stops mattering, without anyone having to remove it. A refactor that splits two files apart shows up as their weight fading over the following weeks.

What it is built from, and what it is not

The signal is built only from the activity your agents log. Pathrule does not read your source code, your diffs or your commit messages to compute it, and only the file paths from those log entries are used.

That has a practical consequence worth knowing: it needs a real editing history. A workspace where every logged task touches exactly one file produces no pairs at all, because there is nothing to pair. In that case retrieval keeps working from path scope and meaning, and co-change contributes nothing rather than guessing.

It is also per workspace. Relationships learned in one workspace never leak into another, and the whole signal sits behind the same access control as the rest of your knowledge.

Where to look

Co-change works in the background, so there is nothing to configure and nothing to switch on. It becomes more useful as your team logs more work, which is the same thing that makes work episodes and suggestions more useful. If your agents are logging their work, this is already accumulating.