STEP 1601 — harvest_lag (arXiv oracle) v0.1

2026-08-31 · 藤本さん directive「harvest_lag = 次 STEP、コンパレータ素子の真の proof」応答 · 検査票 Round 012 向け 3 計器の 2 本目 · STEP 1599 の姉妹

目的

STEP 1599 の source_freshness は「file が新しいか」だけを測った (外部 API 呼出 0)。 本 STEP は外部真値 (external oracle)と照合し「fetcher が真の publisher より遅れているか」を測る。 これが Rei stack 初のコンパレータ素子 (rei-meta divergence-detection の汎用化)。

実装場所

scripts/comparator/
├── lib/
│   ├── oracle.ts        — 抽象 Oracle contract (source-agnostic)
│   └── oracle-arxiv.ts  — arXiv Query API adapter + Atom parser
├── gauges/
│   └── harvest_lag.ts   — delta-time verdict logic
└── run-harvest-lag.ts   — CLI runner (rate-limited ≥3.5s/call per arXiv ToU)

test/step1601-harvest-lag-test.ts   — 25/25 PASS (mock oracle、network 不要)
data/comparator/harvest-lag-latest.json   — live report (chat-Claude fetch 可能)

Verdict semantics (D-FUMT₈ subset)

Delta = (oracle newest published) − (internal newest published)、単位時間。

Verdict条件意味
TRUEdelta ≤ 6h健全 (lag ほぼゼロ)
NEITHER6h < delta ≤ 24haging (watch)
FALSE24h < delta ≤ 72hlagging (action)
ZEROdelta > 72h または internal 0 papersdead pipeline
FLOWINGoracle 到達不可 or 応答空診断不可 (fetcher 失敗ではない)

実測 (2026-08-31 09:07 JST, arxiv-recent 9 feeds)

FeedVerdictDeltaOracle newest
math.NTTRUE0.0h2026-08-27T17:45:07Z
math.LOTRUE0.0h2026-08-27T13:15:12Z
math.DGTRUE0.0h2026-08-27T17:53:27Z
cs.LOTRUE0.0h2026-08-27T14:28:11Z
cs.AITRUE0.0h2026-08-27T17:59:11Z
cs.LGTRUE0.0h2026-08-27T17:46:21Z
cs.CLTRUE0.0h2026-08-27T17:59:30Z
physics.gen-phTRUE0.0h2026-08-24T12:22:20Z
quant-phTRUE0.0h2026-08-27T17:59:51Z

Wall-clock 36.2s、oracle failure 0/9、latency 179-5661ms (中央値 322ms — arXiv 側 variance が可視化)。 9/9 TRUE は週末による publisher 停止 (arXiv は Fri-Sun 論文数少ない) + fetcher が週の最終 publish (Thu 08-27) を正確に捕捉したことの evidence。 physics.gen-ph は 08-24 (Mon) が newest = 6 日前だが、これは publisher cadence の問題であって fetcher lag ではない。

Round 011 検査票の「fetch pipeline gap」への構造的応答

Round 011 検査票 (2026-08-26) は get_arxiv_papers / get_knowledge_stats の arxiv=0 / wikipedia=0 を「fetch pipeline gap」と診断した (daemon 側の話)。 本 STEP は別 pipeline (arxiv-recent cron)について「lag ゼロ、healthy」の evidence を独立に測った。 daemon 側の 0 rows は本 STEP の対象外だが、同じ手法で daemon DB を internal 側に差し替えれば daemon の harvest_lag が測れる (別 STEP 候補)。

コンパレータ素子としての位置

Rei stack に初めて追加された「外部真値と内部を突合する」素子:

Oracle 契約は source-agnostic なので Zenodo / HuggingFace / OpenAlex / bioRxiv 等への extension は adapter 追加のみ (別 STEP)。

検査票 Round 012 進捗

#計器状態
1source_freshness✅ STEP 1599 v0.1 (72 sources: fresh=17 / dead=42 / unknown=13)
2harvest_lag✅ STEP 1601 v0.1 (arXiv 9 feeds: fresh=9 / lag=0h)
3dedup_collision⏳ 次 STEP (arxiv-recent / arxiv-edu / research-radar/arxiv 3 経路 DOI 突合)

chat-Claude 直 fetch URL:

Honest scope (7 件)

  1. Delta は「newest published」時刻差のみ。「N 件見逃し」ではない (cursor-based counting は defer)。
  2. Oracle も arXiv (export.arxiv.org) を叩く = fetcher と同 endpoint。lag 検出は「fetcher cadence + filter drift」の分離のみ、「別 data source との照合」ではない。
  3. FLOWING = oracle 到達不可 or feed 空。fetcher 失敗ではなく「今回 verdict 不能」。
  4. ZERO は 2 経路: delta > 72h または internal 0 papers。後者が最も強い「dead pipeline」信号。
  5. Threshold (fresh=6h / aging=24h / lagging=72h) は publisher cadence 考慮の heuristic (週末 gap を許容)。
  6. arXiv ToU: ≥3s/call。 runner は 3.5s sleep 実装。他 arXiv caller と並走禁止。
  7. v0.1 は arXiv のみ。Zenodo / HuggingFace / OpenAlex adapter は Oracle 契約準拠で別 STEP に extend 可能。

Related