Everyone here measures what goes into agent memory. I measured whether the agent actually obeys it. 737 warnings, 0 violations, thresholds written down first.

A lot of the memory work in this sub, including some genuinely good posts this week, is about what gets into the store: provenance, grounding, receipts, proving a claim traces to a source. I've argued that side here myself. This is the other half, and I can't find anyone measuring it. A rule reaching the model is not the same as the model following it. Retrieval metrics tell you a lesson was shown. They say nothing about whether it was obeyed. So I built the meter and ran it on myself for two months. Mechanism. Lessons live as files in the repo, anchored to specific code: a symbol, a path, a pattern. A pre-edit hook injects only the lessons anchored to the code being touched right now. Nothing global, no context budget burned on rules about files you aren't in. The measurement. A lesson can carry a machine-checkable regex describing the forbidden construct. A post-edit hook runs it against the resulting diff. Two events per lesson: fired: injected before the edit violated: the forbidden construct appeared anyway Fired-without-violated is compliance. Both is a logged, countable disobedience. Note the asymmetry, because it limits the claim: only disobedience is observable. The rate is a floor, never a proof. Thresholds first. Before looking at data I wrote the rule down: F >= 20 firings with V/F <= 0.2 publishes as a compliance result; worse publishes as a postmortem; under 20 publishes as "the instrument exists" with no claim at all. Picking the bar after seeing the number is how you launder a result into a finding. Fourteen-day window: Slice Fired Violated Armed lessons, gated by arming date 737 0 Dropping the one over-broad lesson behind 716 of them 21 0 The second row is the actual claim. One lesson with a repo-wide anchor inflates the count 34x, and cutting it entirely still clears the pre-registered bar. It passes on the harsh cut, not the flattering one. Three caveats that ship with it, not buried at the bottom. The 737 is not reproducible from my own CLI. The log never recorded whether a lesson carried a tripwire when it fired, so I reconstructed arming dates from git history by hand. Run the tool on that window today and it reports armed_firings: 0, because every row predates the field and it refuses to guess rather than backfill in the direction that flatters me. What you can re-run: 1,678 firings across 23 repos, 0 violations, same window. The meter is not inert. Outside the window it has logged 20 violations. Twelve come from a false-positive class where a lesson's own text quotes the construct it forbids, and 8 real ones on actual source files. It catches things, including against me. That is the reason to believe the 0. And while auditing the instrument I found it had been wrong seven times, three of them with a fully green test suite, because I'd written the fixtures from the same mental model that produced the code. The worst: an installer bug silently removed the input half of the pipeline while the output half kept logging, so for four weeks it produced confident numbers describing nothing. The fix that generalises is not more tests. It's encoding impossible states. Violations recorded while the input half observed nothing is impossible by construction, so that number is now refused rather than computed. One line, and it would have caught the outage on day one instead of week four. n=1, my own repos. No claim about your setup. It's open source precisely so you can run it on yours. uv tool install scar-cli then scar init, which writes hooks for Claude Code, Codex, Cursor or Windsurf. MIT. github.com/Daily-Nerd/Scar Disclosure: I maintain it. The question I actually came to ask: has anyone here measured whether your agent follows what you inject, as opposed to whether the injection landed? Every number I can find in this space stops at retrieval. I'll be in the comments.