Open Loop Extraction Results

An open loop is an outstanding commitment between two people: something one person owes the other, agreed to in passing in the middle of a conversation and filed nowhere. Finding the promise is the easy half. The hard half is deciding whether it is still live, because a commitment that was cancelled, delegated, or overtaken four messages later reads exactly like one that still stands. The promise text does not change when the obligation dies; only the rest of the thread says otherwise. An extractor that reads the commitment and stops there cannot tell a live loop from a dead one, and it will report both with the same confidence.

Two configurations are reported below. Hosted large is a 70B model reached over a hosted API, so every thread leaves the user's device to be read. Local is a 7B model running on the user's own hardware, where nothing leaves. The gap between those two rows is what a privacy-first deployment costs today, and it is not a uniform discount. The local run is marginally the more precise of the two on the loops it does report, but it recovers about a third as many of them, gets the direction wrong in more than half the pairs it matches, and reports three of every four dead commitments as still live. Reading the columns rather than the averages is the point: keeping the data on the device does not degrade performance evenly, it removes the specific capabilities that make the output safe to act on.