2026-07-27T0110Z-weekly
One pipeline fire, in full · weekly run of 2026-07-27 · sub-agent allocation and telemetry, per-iteration verification verdicts and findings, source-list edits, coverage gaps, bridge invocations — and the run's own verification & coverage notes: what was published, what was dropped at the borderline or judged not relevant (and why), single-source carve-outs, and contradictions. Rendered from runs/2026-07-27/2026-07-27T0110Z-weekly.md.
Run telemetry
- Items returned
- 5
- Duration
- 12m 47s
- Tool calls
- 20 WebFetch16 WebSearch6 bridge
- Cited sources
- none
- Items returned
- 2
- Duration
- 9m 21s
- Tool calls
- 15 WebFetch24 WebSearch6 bridge
- Cited sources
- none
Verification
Deep dive
—
Entries published (this run)
Empty run · no new verified signal; only the run record was published (a healthy outcome).
Sources changed (this run)
Edits this run made to sources/sources.json · promotions, demotions, new candidates, and fetch-method / category / reliability / url corrections (the run record's sources_changed[]). Paginated; 10 per page.
No source-list edits recorded for this run.
Coverage gaps (this run)
Sources this run's brief needed that returned no usable content via any documented recipe. Bridge-recovered or quiet-day sources do NOT appear here. (Distinct from the independent source-accessibility probe at the foot of this section, which probes all active sources regardless of what any run needed.)
No coverage gaps in this run · every source the brief needed returned usable content via its documented recipe.
Verification findings · all iterations
Per-iteration finding detail. Each table is one verifier pass · what was flagged, how the main agent remediated it, and the outcome. Walking the tables top-to-bottom shows the verifier's debugging trail across iterations.
Iteration #? cap-breach
Cap-breach iteration recorded no per-finding detail. The dashboard cannot show WHAT the verifier flagged. See .claude/agents/cti-verification.md § Findings summary for the contract.
Verification & coverage notes
The run record's narrative body, verbatim. This is where the run accounts for its own judgement calls — every borderline drop and judged-not-relevant item with its reason, dedup decisions, single-source items and their carve-outs, contradictions, and per-source coverage gaps — so nothing the run considered disappears silently.
Verification & coverage notesrun record body
2026-07-27T0110Z-weekly · weekly · Claude Opus 5 · 0 entries published
Weekly strategic run — 2026-W30 — DUPLICATE-WEEK (backup fire, overtaken by the primary mid-flight)
Outcome: duplicate-week — no entries published
This backup weekly fire is a duplicate-week no-op: the primary weekly for 2026-W30 landed on origin/main while this fire was mid-pipeline, so all strategic content this fire composed was withdrawn before publish to honour the one-weekly-per-ISO-week / no-duplicate-coverage invariant. The mandatory artifact of the fire — this run record — is published; zero entries are.
The race, precisely. At this fire's Phase 0 (2026-07-27T01:09Z) the backup-invocation guard and the weekly Phase 0 duplicate-week guard both ran git grep "^week: 2026-W30$" origin/main -- runs/ against origin/main at 537d453 and found no match — no -weekly record covered W30 — so the fire correctly proceeded to execute prompts/weekly-summary.md in full. Unknown to it, the primary weekly 2026-07-26T2309Z-weekly had fired at 2026-07-26T23:09Z; its commits (c59bdbc run + d55b237 publish-status amendment) propagated onto origin/main only after this fire's Phase 0 check. This fire discovered the overtaking run at Phase 6, when the pre-push sync (git fetch origin main) advanced 537d453 → d55b237 and surfaced runs/2026-07-26/2026-07-26T2309Z-weekly.md carrying week: 2026-W30, entries_published: 11, publish_status: ok. Per the anti-crash overtaken-run rule (prompts/cti-run.md guard #10) and the duplicate-week invariant, the correct action once the primary has published the week is to withdraw the overtaken duplicate rather than publish a second W30 weekly.
What this fire did before standing down (preserved under work/2026-07-27T0110Z-weekly/ for forensic review). It ran the full weekly pipeline: Phase 0 preflight (prior-coverage index over 14 days, ATT&CK pin check — up to date v19.1); Phase 1 week-in-review over the 46 W30 operational entries (seven working lists → week-review.json); Phase 2 horizon research (W1 returned 5 items, W2 returned 2 — findings YAMLs preserved); Phase 3 triage (triage.json); Phase 4 composed 9 strategic entries (2 top-stories, vuln-rollup, sector-patterns, multi-day, 2 research, policy, looking-ahead); Phase 5.5 mechanical gate to exit 0; and the full Phase 5.7 verification loop to the 8-iteration cap (Opus/Sonnet rotation; truth-defect counts 9 → 2 → 1 → 3 → CLEAN → refuted(1) → CLEAN → refuted(1); every finding a truth/attribution defect, all remediated, no drops). The eight per-iteration verification reports and findings YAMLs, the W1/W2 findings, the week-review.json working lists and triage.json are all preserved under work/2026-07-27T0110Z-weekly/ for forensic review — they fully document the withdrawn entries' content and the verification history. The 9 composed entry files themselves were withdrawn at Phase 6 and never committed to entries/; the primary weekly's 11 W30 entries are the published record for the week.
Overlap with the primary confirms the withdrawal is correct, not a coverage loss. The primary's 11 W30 strategic entries (entries/2026-07-26/weekly-w30-*) cover the same week-defining signal this fire independently reached: AI as autonomous operator and target; state-nexus self-hosted-webmail espionage; the exploited/KEV vulnerability roll-up; CH/EU public-sector third-party-mediated incidents; trusted-infrastructure C2; the npm/AI-toolchain supply-chain and Joomla-extension status; EU procurement-assurance policy (plus a BaFin/TeamViewer disclosure-precedent item); and a looking-ahead. A reader is fully served by the primary; publishing this fire's near-identical 9 would have duplicated W30 coverage.
The one additive change kept. actor:sandworm gains the alias SANDWORM RELIC (Google GTIG's unified two-word cryptonym, 2026-07-24, surfaced by W1). The primary weekly did not record it; it is registry hygiene, not weekly coverage, so it is committed here where it is correct and non-duplicative. The only sources.json change is factual fetch telemetry — last_successful_fetch bumped to 2026-07-27 for the 15 sources W1/W2 successfully fetched today; no lifecycle transition or new candidate is carried (the primary's source-lifecycle pass stands), and there is no cves_seen.json change. source_health.json is left as the primary left it.
Operator note
Two weekly fires ran for 2026-W30 — the scheduled primary (2026-07-26T23:09Z) and this backup (2026-07-27T01:10Z) — because the backup's Phase 0 check preceded the primary's record reaching origin/main. The primary succeeded and is live; the backup detected it at push time and stood down with zero duplicate entries. No action required. If the double-fire is undesirable, the backup schedule can be shifted later relative to the primary so the primary's record has reliably propagated before the backup's Phase 0 guard runs.
← Operations dashboard · run-record contract: docs/pipeline.md