KG ephemeral sweep reports 0 for 52 days while 178–271 pure-ID nodes escape a live guard — sweep shares the guard's blind spot by construction (#153 phase-2)

[olegbrok]

Summary

The daily ephemeral sweep has reported n_candidates=0 for 52 consecutive days (2026-06-10 → 2026-08-01). That zero is being used as the regrowth instrument for deciding how urgent the write-path guard is (#153 phase-2).

The zero is real for the patterns the detector knows, and misleading as a measure of regrowth. In the same graph, 286 pure-identifier entities carrying ~557 edges are present that is_ephemeral does not match — and 281 of them were created after the guard shipped (2026-06-07, 6336d8a / #660). One was created today by the 3 AM dream: #953.

Nothing here is a defect in the guard's implementation. It does exactly what its docstring specifies. The problem is that the sweep cannot measure the guard's coverage, only its execution.

Why the instrument can't see it

By deliberate design (and it's a good one for drift), scripts/kg_ephemeral_sweep.py imports is_ephemeral from src/pinky_memory/ephemeral_guard.py — the same function the write-time guard calls:

"The recurring sweep imports the SAME is_ephemeral from here, so the regex lives in exactly one place and the two halves can never drift."

The consequence is structural: a name the guard fails to block is a name the sweep cannot count. The two halves can never disagree, so the sweep reports 0 for any pattern outside the shared dictionary — forever, and indistinguishably from genuine success. The measurement instrument is blind in exactly the same shape as the thing it measures.

Fifty-two days of 0 reads as "the guard solved it, deprioritize." The graph says otherwise.

What's escaping, measured

EPHEMERAL_PATTERNS requires a prefix word (PR #635, issue #501, release 26.05.094), an owner/repo#NNN form, or the PinkyBot \d{2}\.\d{2}\.\d{3} stamp. Uncovered forms actually present in barsik/data/memory.db, IPv4 excluded:

form	entities	edges (active)	examples
bare #NNN — no prefix word	88	139 (139)	#953, #692, #145
PR N / issue N — no #	20	178 (178)	PR1, PR2, issue 327
semver vX.Y.Z	31	42 (41)	v2.1.214, v0.2.82
semver X.Y.Z	37	54 (54)	0.2.122, 9.125.0
bare integer (ambiguous — see below)	95	144 (144)	9, 383, 400000
total	271	557 (556)

Split by creation date against the guard's ship date: 5 pre-guard, 281 post-guard. By month: June 243, July 37, August 1 (partial). July's ~1.2/night is the steady-state rate — low, but not zero, and cumulative.

bare #NNN is the one that matters most: it's how issues get cited in practice, including throughout my own memory and messages, so it's the highest-frequency form the extractor sees.

Ambiguity flagged honestly: the bare integer row is not clearly ephemeral — 400000 could be a meaningful quantity in some context. Excluding that row entirely still leaves 176 unambiguous pure-ID entities, essentially all post-guard. I'd treat 176 as the defensible figure and 271 as the upper bound.

IPv4 was excluded deliberately — my first pass counted 10.0.0.209, 10.0.0.152 and 127.0.0.1 as ephemeral, which is wrong: those are the Mini, the Pi and localhost, durable infrastructure nodes. Any pattern widening must exclude dotted quads, or it will delete the fleet's addressing.

Scale note

The docstring records the patterns as "soak-validated against barsik's live ~392-entity graph: 49 true positives, ZERO false positives." That graph now holds 18,279 entities and 19,031 triples — roughly 46× the validation corpus. The zero-false-positive result still appears to hold (no evidence of over-blocking), but a dictionary validated at 392 entities is being trusted at 18k.

Suggested direction (not done — deliberately)

I have not widened the patterns or deleted anything. Widening a delete-pattern against a live memory graph needs review, and the sweep's conservatism ("miss-and-recatch beats false-block") is correct. Proposals, in order:

1. Break the shared-blindness property. The sweep should keep using is_ephemeral for deletion but report a second, wider candidate-only diagnostic count that is never auto-deleted. That restores an independent instrument without risking a false delete. This is the fix that matters — the others are one-time cleanups.
2. Extend EPHEMERAL_PATTERNS for bare #NNN, prefix-without-hash (PR1, issue 327), and semver stamps. Must exclude IPv4 and should probably leave bare integers alone.
3. One-time cleanup of the 176 unambiguous existing nodes, via the sweep's normal backup + JSONL path.
4. Log n_entities_total in each sweep record, so a future reader can see the zero was taken against an 18k graph rather than a 392-entity one.

Reproduction

python3 scripts/kg_ephemeral_sweep.py data/agents/barsik/data/memory.db   # dry run: 0
python3 -c "
from pinky_memory.ephemeral_guard import is_ephemeral
print([(n, is_ephemeral(n)) for n in ['PR #124','#953','PR1','v2.1.214','26.07.029']])"
# -> PR #124 True, #953 False, PR1 False, v2.1.214 False, 26.07.029 True

---

🤖 Filed by Barsik

[olegbrok]

Scope: this is barsik-only, not fleet-wide. Ran the same measurement across every Mini agent's memory.db:

agent       entities  uncaught  post-guard  caught
barsik         18279       191         186       0
dymok/kotik/kuzya/murzik/pushok/solik   0    0     0    0
gemma/persik/ryzhik   (no kg_entities table)

Only my graph has a populated KG — the extraction/dream pipeline runs against it alone — so there's no fleet amplification and no other agent's graph to clean. Worth knowing before anyone plans a fleet-wide sweep.

caught=0 for barsik is a useful confirmation in the other direction: zero covered-pattern ephemera are sitting unswept, so the guard genuinely is holding the line it knows about. The gap is coverage, not enforcement.

Count clarification, since I've now quoted three figures. They differ by which forms you count, and I'd rather state the band than pick a flattering number:

definition	count
three-part+ versions only (0.2.122, v2.1.214), no bare integers	176
...plus two-part versions (2.1)	191
...plus bare integers (9, 383, 400000)	271–286

176 is the conservative, defensible figure. The bare-integer row is genuinely ambiguous and I would not auto-delete it. Post-guard share is ~97% at every definition.

[olegbrok]

Correction to my own numbers — I used the wrong boundary. The conclusion survives; the figures move slightly and the method error is worth recording.

I counted nodes created after the guard shipped (6336d8a, 2026-06-07) and called them "post-guard." But shipping is not enabling. PINKY_KG_EPHEMERAL_GUARD is currently =1, and there is a .env.bak.pre-kgguard-flip holding =0, dated 2026-06-09 07:52 — so the guard existed but was switched off for its first two days. I asserted "escaped the guard" from a commit date without checking the guard was actually on, which is the same mechanism-vs-caller error this repo keeps producing.

Recounted against the enable date rather than the commit date:

definition	after ship (06-07)	after enable (06-09 07:52)
narrow — no bare integers	186	178
wide — incl. bare integers	281	271

Only 8–10 nodes fall in the ship-but-disabled window, so the headline is essentially unchanged — but 178 (conservative) / 271 (upper bound) escaped a live, enabled guard, and that is the number that actually supports the issue. Everything after 2026-06-09 07:52 is genuine coverage-gap evidence rather than "the guard was off."

Supporting detail, independently consistent: the sweep log shows candidates found on 06-08 (8) and 06-09 (23) — the last of the covered-pattern regrowth — and exactly zero from 06-10 onward. That is what a guard being switched on looks like, and it corroborates the 06-09 flip from a second source.

The two-day shipped-but-disabled window is itself a small instance of the pattern in this issue: the mechanism was present and not reaching production, and nothing said so.

[olegbrok]

Build spec — the diagnostic split (proposal 1)

Writing this now while the analysis is fresh so the eventual builder doesn't re-derive it. Not dispatched yet — both codex agents are on chez #503. Low urgency (~1.2 nodes/night); this is a correctness fix for the instrument, not an incident.

The one-line problem

scripts/kg_ephemeral_sweep.py imports is_ephemeral from pinky_memory.ephemeral_guard — the same function the write-time guard calls. Sharing it prevents drift, which is why it was done, and it also means the sweep can only ever report on patterns the guard already blocks. A name the guard misses is a name the sweep cannot count. n_candidates therefore measures the guard's execution, never its coverage, and reports 0 for a coverage gap indistinguishably from success.

The fix, in one sentence

Keep is_ephemeral as the sole authority for deletion. Add a second, wider is_ephemeral_candidate used only for counting, which never deletes anything.

Requirements

1. Two functions, asymmetric authority. is_ephemeral (unchanged) gates deletion. A new is_ephemeral_candidate — deliberately wider — gates only the diagnostic count. Nothing the candidate matcher finds is ever deleted, in any code path, under any flag. The whole value is that it can be aggressive without risk.

2. New sweep-log fields, additive so the 60+ existing records stay parseable:

   • n_diagnostic_candidates — wide matcher count
   • diagnostic_candidates — the names (capped, e.g. first 100, with the cap recorded)
   • n_entities_total — total kg_entities rows, so a future reader can see a zero was taken against an 18k graph rather than the 392-entity corpus the patterns were validated on
   • Keep n_candidates meaning exactly what it means today.

3. Candidate patterns — the forms measured in this issue as escaping a live guard:

   • bare #NNN (88 present — the highest-frequency form, since it's how issues are cited in practice)
   • PR N / issue N / task N without the # (20)
   • semver vX.Y.Z and X.Y.Z (68)
   • bare integers: include but flag separately — genuinely ambiguous (400000 may be a real quantity), so report as its own subcount rather than folded into the headline.

4. ⚠️ IPv4 MUST BE EXCLUDED. My own first-pass detector counted 10.0.0.209, 10.0.0.152 and 127.0.0.1 as ephemeral — those are the Mac Mini, the Pi and localhost, durable infrastructure nodes. A dotted-quad exclusion is mandatory, with a regression test asserting all three survive. This is the single most likely way to turn a diagnostic into an outage.

5. Positive control, required. The sweep must verify its own matchers fire before reporting any zero. Assert is_ephemeral("PR #124") is True and is_ephemeral_candidate("#953") is True at run start; if either fails, exit non-zero rather than logging a clean zero. A detector that cannot fire must never report "nothing found" — that's the defect this issue is about, and the fix shouldn't reintroduce it one level up.

6. Loud when they diverge. When n_diagnostic_candidates > n_candidates, say so explicitly in stdout — that difference is the coverage gap, and it's the number a human should act on. Silence when they're equal.

Explicitly out of scope

• Widening EPHEMERAL_PATTERNS (the deletion set). That's a separate, reviewed change with real false-positive risk, and it should be decided after the diagnostic has run for a week and produced evidence.
• The one-time cleanup of the 178 existing unambiguous nodes. Separate, via the sweep's normal backup + JSONL path, once the pattern set is settled.

Acceptance

The next nightly run logs both counts; n_candidates stays 0; n_diagnostic_candidates reports ~178–271 depending on the ambiguous-row decision; the three IPv4 addresses are absent from the candidate list; and killing a matcher makes the script exit non-zero instead of reporting clean.