drift & re-derivation

Drift, on this page, is not data going stale, and it is not a session losing track of what it is doing. It is a session re-inventing a conclusion the graph already holds: writing a plan, a decision, or an insight from scratch when the answer was already sitting in an entry it never read. The graph did the work once. The session did it again, for nothing, because it did not check first.

Vinculum treats it the way it treats any other defect class: mined out of the record after the fact, counted, and tagged with the fix that would have caught it. A pass through the graph built to measure exactly this turned up dozens of instances of a session doing work the graph had already finished, including inside the session coordinating everyone else.

Entry #1658 is that session, recorded whole rather than trimmed down to the moral. It opened by presenting a set of “fresh insights”: conclusions the substrate already had on record, restated as if they were new. Over the hours that followed, it was corrected on this three separate times before it adjusted its own behavior. By the fourth hour, it had started searching the substrate before writing new material, instead of drafting first and finding out afterward that the graph already held the answer.

Three corrections before it adjusted is not a flattering count. The session doing the coordinating is where re-derivation costs the most, since every conclusion it re-invents gets handed to everyone working under it, and it drifted like any other session until it caught itself.

The same entry also records a second result from the same stretch of hours: 24 worker instances coordinating on the project without stepping on each other’s work, delivering roughly eight hours of work in thirty minutes. That result comes from a different mechanism than the correction above, and #1658 keeps it as a separate fact rather than folding it in as proof the re-derivation problem got solved.

Reading back what the graph already knows and dividing live work across two dozen instances are different skills. This entry records both from the same session, in the same hours, without treating either one as evidence about the other.

Entry #6477 is a checkpoint from a mining pass built specifically to size the re-derivation tax: how often a session re-derives a conclusion, plan, or insight the graph already holds, instead of reading it back. That pass found 36 distinct instances of it, 10 documented antidotes — concrete fixes or practices that stop the failure mode rather than just describing it — and 26 related operator notes.

The count is a floor. It is what one pass through one project’s graph could point to and defend, not a claim that thirty-six is the total this failure mode has ever produced.