`logCrossIterationDataRead()` compares only the two jobs' `loop_iteration` integers. It never consults the `loops` stamps, so it cannot tell the three cases BR-6 scopes it to apart — and one of them, a source sharing no loop with the consumer, is behaviour the spec describes as intentional: > (3) a source that shares no loop with the consumer, where the older value is delivered on purpose. That case is SG-19's anti-deadlock arm ("an **empty intersection is never behind**"). It is not a blind spot the barrier cannot see; it is the barrier deliberately declining to gate. It is nevertheless logged at `warning` severity, once per loop iteration, for the lifetime of every run that has one. Cases (1) — the data ports of a trigger-driven consumer (DATA-4) — and (2) — a pipeline predating the `loops` stamp — are genuine gaps, and warning on those seems right. Case (3) is the one in question. Found on `dev-2.x` `0e4e894`. ## Why it is not rare An out-of-loop data source feeding an in-loop consumer is the ordinary shape of an agent loop: durable conversation history, a loaded corpus, a retrieved document, a system prompt assembled once and read every round. Any such workflow emits a warning per iteration per source. A ReAct workflow here — `conversation_buffer` (session-scoped history, runs once, outside the loop) → `message_assemble` (inside the loop) → `conversation_normalize` → `reason` — logs this on every round: ``` Cross-iteration data read on pipeline 83: job 1218 (node message_assemble.1, iteration 1) is satisfied by source node conversation_buffer.4 (job 1213, iteration 0) — an OLDER iteration than the consumer. Delivery is not gated (BR-6); logged for observability only. ``` The loop map for that run confirms it is case (3) — empty intersection, not a stamp problem: ``` loop head conversation_buffer.1 body: [boolean_gateway.1, boolean_gateway.2, chat_output.2, conversation_buffer.1, conversation_buffer.2, conversation_normalize.1, flowdrop_node_processor_reason.1, flowdrop_node_processor_tool_invoke.1, message_assemble.1, prompt_template.1] message_assemble.1 in body → TRUE (consumer) conversation_buffer.4 in body → FALSE (source) ``` `conversation_buffer.4` is *supposed* to run once and be read by every iteration. There is nothing for an author to act on, and no way to silence it from the canvas. 116 of these accumulated in `watchdog` across a handful of short debugging runs on this site. ## Why the memo does not contain it ```php $memo_key = $job->id() . ':' . $source_job->getNodeId() . ':' . $source_job->id(); ``` The consumer's job id is part of the key, and StateGraph mints a fresh consumer job per round (`createLoopIterationJob()`), so the key is new every iteration. The memo suppresses duplicates within a round, never across rounds — which is correct for cases (1) and (2), where each round genuinely is a new unobserved read, but means case (3) scales linearly with iteration count. ## Note on the call-site comment The comment above the call enumerates only two of BR-6's three cases, and its last sentence does not hold for the third: ```php // Observability floor for the staleness the barrier above cannot see: // a pipeline whose jobs predate the `loops` stamp, and the data ports // of a trigger-driven consumer, which readiness never evaluates at all. // Where both stamps are readable and share a loop, the barrier has // already gated the edge and this never fires. ``` In the run above both stamps are readable and they do **not** share a loop, so the barrier correctly does not gate — and this fires. BR-6's own text lists case (3); the comment omits it, which is probably why the severity was never revisited for it. ## Suggestion Give `logCrossIterationDataRead()` the shared-loop test the barrier already has (`LoopRound`'s stamp intersection, as `isBehind()` uses), and treat an empty intersection as the intended delivery it is — `debug`, or no line at all, rather than `warning`. Cases (1) and (2) keep their current severity, and the log stops reporting the anti-deadlock arm as an anomaly. Reasonable to argue the opposite — that any cross-round read is worth a warning regardless of cause — but then the message should say which of the three cases fired, since the remedy differs completely: (1) and (2) mean *possibly wrong data*, (3) means *working as designed*. As written, an author cannot tell which they are looking at, and the common case is the benign one. ## Related - #3592431 — closed; surfaced this warning while verifying that fix.