What Pathrule computes

You write three kinds of thing: memories, rules and skills. That part is deliberate, curated, and yours.

It is also the smaller half. Most of what the layer holds at any moment was not typed by anyone. It is derived from how work actually goes, kept per workspace, and recomputed as the work continues. This page names each derived part, because knowing what is there explains why retrieval behaves the way it does.

A meaning representation for every entry

Every memory, rule and skill also exists as a computed representation of what it means. When a request arrives, the request is turned into the same kind of representation and compared against them directly.

This is the part that makes cross-language matching work. A prompt in Turkish surfaces a memory written in English when the two share an idea and not a single word. Keyword search cannot do that, because there is no shared string to match on. The comparison happens in a space where "the payment webhook retries twice" and "ödeme webhook'u iki kez deniyor" sit near each other.

Entries are re-represented when their content changes, so the match reflects what the entry says now rather than what it said when it was created.

A measured window around every delivery

When Pathrule delivers knowledge for a turn, it opens a record of that delivery. That record holds which entries were sent, on which path, for which kind of intent.

The turn then reports back into the same window:

• which of the delivered entries the assistant actually consulted, as opposed to merely receiving
• how many tool calls the turn took, and how many of them failed
• which files were edited, in workspace-relative form
• how the failures broke down, as short codes rather than error text

That window is the raw material for everything below it. It is also the reason Pathrule can tell a turn that went well from one that went badly without anyone rating anything.

Learned weights, per kind of work

Windows accumulate. Over time each entry carries a weight for each kind of work it has been delivered into, and that weight moves with evidence: up when the entry was consulted on work that went cleanly, down when it was delivered into a turn that struggled.

The consequence is that ranking is not one number per entry. The same memory can rank high for a migration and low for a UI tweak, because those are different kinds of work and the evidence differs. A single "importance" field on a file cannot express that, and a person maintaining one by hand would have to guess at it.

The weights are conservative on purpose. An ambiguous outcome teaches nothing rather than teaching the wrong thing, a single clear miss lowers standing rather than erasing history, and influence fades as the code drifts. How retrieval finds the right knowledge covers that behaviour in detail.

A graph of files that move together

From the paths that turns report, Pathrule builds a picture of which files your team habitually changes in the same piece of work. Knowledge attached to one of those files can then reach a session working on its neighbour.

Nobody declares these relationships and no file is scanned to find them. They come out of logged work, they carry a noise floor so a single coincidence does not count, and they decay when the pairing stops happening. See files that change together.

A friction map

Failures group into a triple: the kind of tool, the file, and a short code for how it failed. Grouped by week, that becomes a picture of where an assistant keeps getting stuck in your codebase and how, and it feeds ranking as a negative signal when a turn that received knowledge still ran into trouble. See files that slow an assistant down.

Episodes, and judgements about freshness

Two more derived layers sit on the same activity.

Work episodes stitch related turns into the story of how something was solved, so "how did we do this last time" has an answer that is not a person's recollection. See how did we solve this before.

Staleness judgements compare what an entry claims against where the code has since gone, and raise the ones that look overtaken as proposed edits rather than silently ranking them down. See suggestions and self-audit.

What none of it is built from

Not your source code. Every derived layer above comes from two things: what your team chose to write down, and what the work reported about itself. No repository is scanned, no file contents leave your machine, and no diff is stored. File paths are normalised to workspace-relative form before anything is kept, so nothing machine-specific travels either.

Why the same files in a folder are not the same thing

You could put the same memories, rules and skills in a directory and point an assistant at it. Teams do. What that directory cannot do is anything on this page.

It does not know what was delivered on the last turn, so it cannot tell what helped. It has no representation of meaning, so a question phrased differently finds nothing. It does not know which files move together, so knowledge recorded on one file never reaches its neighbour. It cannot tell a task type from another, so everything ranks the same for everything. And it grows: every entry added makes every future turn heavier, because a directory has no way to send only the few that matter.

The written entries are the part you control. The derived layer is what turns them into the right few for this turn, and it is the reason the answer improves as the work continues rather than staying exactly as good as the day it was written.