2026-08-24T0902Z-audit

What this fire audited

Window: 2026-08-09T13:15:57Z (the previous audit's start) → 2026-08-24T09:02Z. That is 355 hours — a little under fifteen days, inside the 21-day cap and therefore audited in full rather than truncated. It is double the usual length because no audit fired on 2026-08-16; that missing fire is recorded below as an availability observation, not a cadence judgement.

The window holds 149 entries across 18 fires. Every one of the 149 was covered by exactly one retrospective truth pass, across nine batches alternating Opus and Sonnet. Both audit halves ran in full: nine truth passes for soundness and six independent coverage re-sweeps for completeness, three per half of the window.

Preflight ran on a wrong clock and a stale clone, and this is the first thing a reader should know

This fire's container booted with its clock reading 2026-08-16T13:13Z and a first git fetch origin main that returned refs eight days old. Neither failed loudly. The run computed a 168-hour window ending 2026-08-16, partitioned an inventory of 81 entries, and briefed eight sub-agents on it before the error surfaced — for a few minutes the evidence read as an eight-day pipeline outage, because the newest run record the clone could see was 2026-08-16T0411Z and the clock agreed it was the 16th.

Ground truth was established mid-run from an external HTTP Date header and a second fetch: the true time was 2026-08-24T09:02Z and origin/main carried eight further fires. The run was then re-anchored: new run id, correct 355-hour window, re-inventoried at 149 entries, and four further truth batches plus three further coverage sweeps spawned to cover 2026-08-16 → 2026-08-24, which the first eight sub-agents had been told was out of window. The five truth batches that had already returned were kept — they verified real published entries against primary sources, and a wrong window label does not affect a truth check — and the three first-half coverage sweeps were kept as valid for their half. Their timestamps are recorded above exactly as their checkpoints wrote them, under the pre-correction clock; the offset is +7 days 19 hours 49 minutes. The full incident is written up in work/2026-08-24T0902Z-audit/PREFLIGHT-CLOCK-INCIDENT.md.

No operator notification was sent about the apparent outage, because it was not one.

Soundness

125 of 149 entries came back clean on a cold re-read against primary sources. The verifier batches returned 19 imprecisions and 5 factual errors; this audit adjudicated one of those five down to a development rather than an error, so the adjudicated figure is four confirmed factual errors in 149 entries, all four in weekly strategic entries and all four now corrected by new entries rather than edits.

Three of the four are one defect: the 2026-W33 weekly told readers that GeoServer's actively exploited SQL injection had no vendor fix, when the fix had shipped two days before those entries published. The fourth asserted that Microsoft had never revised a vulnerability record that it had in fact revised two days after the catalogue listing that the entry was arguing about.

The adjudication is worth stating because it cuts the other way from a finding: a batch reported the NatJack research entry as factually wrong for saying only two CVEs had been assigned, on the grounds that the researcher's page now lists three. The third identifier was published on 2026-08-11, one day after that entry. The entry was correct when written and has been overtaken, which is an update, not an error. An audit that records a stale entry as a false one is manufacturing a finding.

Completeness

Six coverage re-sweeps re-researched the window from scratch. The great majority of what they surfaced was already published — the second-half sweeps independently confirmed roughly twenty distinct stories as correctly covered. What was genuinely missing came to fifteen items, of which this fire published the two most urgent and queued the remaining thirteen on state/coverage_backlog.md with the reason for each. The publish set was capped deliberately to keep the verifier loop and the publishing chain inside the wall-clock guard, not because the queued items are weaker; several are unauthenticated near-maximum-severity flaws.

What the run believed was its sharpest miss turned out, at the pre-publish sync, to be already covered by a late-promoting fire — see the post-merge section at the end. The transport story below still stands on its own: A Joomla third-party-extension disclosure stream produced two unauthenticated CVSS 10.0 flaws and a CVSS 9.2 SQL injection inside this window, none of them published — and this is the third audit to recover a miss from that one publisher's stream — 2026-07-26, 08-02 and this one, and deliberately not described as consecutive, because the 08-09 audit recovered nothing from it and read that as the rule working. The cause turned out to be mechanical rather than editorial: the only source in the list that publishes those disclosures was pinned to the metered reader transport, and every reader key is exhausted, so the source had effectively stopped existing while continuing to look healthy. Its working feed was found and the record fixed this run.

Reader pool: the last-resort transport is down, and it is now blocking verification

Every configured reader key reports exhausted, with a combined balance far below zero. This has moved past a capacity warning. One truth pass could not verify a patch date because the vendor's own record is a JavaScript-only page and the reader was the only route to it; the coverage sweeps logged several sources they could not read for the same reason; and one source-coverage fix this audit wanted to ship — a direct record for a research publisher whose work the store already cites four times — cannot be shipped honestly, because that publisher's site is client-rendered and the only transport that reads it is the one that is down. Adding a source pinned to a dead transport is precisely the bug this audit just fixed elsewhere.

Telemetry and machinery

Eighteen fires, all eighteen carrying publish_status: ok, so the Phase 7 amendment landed every time. Verifier convergence recovered: 5 of 18 fires reached a confirmed two-model double-CLEAN, against 2 of 12 in the previous window, with the mean iteration count at 4.9. The recovery is concentrated in the second half of the window — four of the eight fires from 2026-08-17 onward converged. The rotation held on every one of the eighteen fires with no blocked spawn anywhere, which means the model-override ladder shipped for exactly this problem was never exercised; what changed was iteration counts rising, not the ladder working.

Discipline drift reversed on the metric that had been rising for three windows. Actions per operational entry fell from 1.09 to 0.80 against a store baseline of 0.58, the share of operational entries carrying no action rose from 23% to 42%, and the verifier's action-item findings fell from 3.0 to 1.1 per ten fires. The high share eased slightly to 50.0%. Every one of the 149 entries carries a rating, no behaviour-kind entry has an empty technique mapping, and no entry carries more than three actions.

At the time of writing, three days in the window appeared to have no run record — 14, 21 and 22 August — with the 16 August audit slot a fourth; the pre-publish sync reduced this to 2026-08-14 alone (see the post-merge section). Every following fire derived its own window from the gap and disclosed it correctly, so no coverage hole opened; the 2026-08-15 and 2026-08-23 fires both worked catch-up windows and said so. Cadence is the operator's to set and is not assessed here, but four missing fires in fifteen days on schedules that were otherwise firing is an availability signal worth the operator's attention, and it is the reason this audit's own window was twice its normal length.

The defect that made every duration in the store a floor

The most consequential systemic finding is not about content. Through v3.31 the run record's completed timestamp was stamped in Phase 5 — before the mechanical gate and before the verifier loop — so every fire's recorded duration stopped roughly where its verifier loop began. The majority of stored records have a completed that precedes one of their own children's end timestamps, by up to 125 minutes. No exact fraction is recorded here: three independent recomputations in this run's own verifier loop gave 103 of 146, 100 of 141 and 104 of 148, moving with how the denominator is defined and whether this fire's record is counted. The worst skew and the illustration below reproduced identically every time. One fire records 52 minutes for work its own notes place at nearly three hours, with its last verifier iteration returning almost two hours after the recorded completion.

The reason this matters is that the three-hour wall-clock guard is checked against exactly that number, so the guard had no machine-readable signal capable of seeing an overrun, and every audit line reading "no runaway this window" — including the previous audit's — was reading a floor rather than a measurement. The defect had also been diagnosed once already, by a verifier on 2026-08-10, and fixed only in the single record where it was found while the mechanism stayed broken. A verifier finding repaired only in the record it was found in is a fix that did not ship.

Both halves are fixed this run: the stamp is now taken immediately before the commit, and the gate rejects any new record whose completion precedes its own children. The check is scoped to records from this prompt version onward, because those 100 earlier records are immutable and reporting them would create a hundred warnings whose only resolution would be to acknowledge them.

Wall clock: 6.4 h, and the warning is the point

This record trips the runaway threshold at 11.4 h, and it is the first record in the store ever to do so honestly — every earlier fire's duration stopped where its verifier loop began, which is the defect this run fixed. The warning is left standing rather than acknowledged, because it is a true telemetry fact about this fire and the discipline reserves the acknowledgment ledger for settled history that cannot be corrected.

The cause was not scope. Roughly three hours were spent working; the rest was two separate blocks waiting on a provider session limit — one that terminated verifier iteration 3 before it read anything (about four and a half hours until the reset) and one that killed the first attempt at iteration 6 the same way (about four hours). Research and truth passes had all returned before the first block; nothing was lost and nothing was left unverified because of either. Two smaller costs are worth recording: the preflight clock incident cost about fifteen minutes, and the audit's own gate check caught this record's completion timestamp three times before it was stamped correctly — first because the value was arithmetic rather than a clock read, then twice because the loop kept running after the stamp, which is precisely the failure mode the check exists for.

Read against the guard's intent — do not let a fire drift so long that a later scheduled fire overtakes it — nothing was overtaken: no intel or weekly fire ran during the block, and the sync before commit confirmed it.

Zero-warning sweep

python3 tools/check_run.py --all ends 1 warn · 0 fail with 14 acknowledged, and python3 site/build.py emits no self-check warnings. The one warning is this record's own runaway duration — a true telemetry fact this run must not self-acknowledge; the next audit reviews it (see § Wall clock). No acknowledgment was added this run and none was pruned: all 14 existing rows still silence a live warning, and nothing this fire found needed the ledger — every warning-class defect it touched had a real fix. One candidate mechanical check was deliberately not shipped: flagging a no-patch status alongside a patch-available one would have caught the GeoServer defect's shape but also flagged 27 correct records across 15 entries — 3 carrying both statuses in one record and 26 carrying a no-patch status alongside a prose fixed string that exists to explain why there is no fix — because a partially-fixed product estate legitimately carries both.

Coverage and watch items

Coverage gaps: claroty-team82 (listing carries no dates and no recency ordering; the sitemap route that worked for another publisher this run has not yet been probed there); cisa-directives and cisa-advisories (Akamai 403 plus the exhausted reader, consistent with four prior consecutive-failure runs; the structured mirror substituted for the industrial-advisory surface); trendmicro-research (genuinely silent since 2026-07-30 on both feed and listing); cybereason (reachable but no post in over six months — a dormant publisher rather than a transport problem, and absent from the source list in any case).

The dark-source watch item narrowed substantially and partly on a measurement correction: the previous audit's "green but contributing nothing" figure was computed by matching cited URL hosts against each source record's own url, which misses a publisher reached on a different host or summarised in a weekly roll-up. Over the true window dragos contributed two cited sources, and the Swiss security-hub feed was the single highest-yield source of the second half. Four essential-tier records still contributed nothing, and this run's sweeps established by full-body fetch that each is reachable and carrying non-vulnerability content by design rather than silently failing.

Borderline items correctly not published are recorded in the audit report, along with two French extortion claims that fail the fake-news guard on current evidence and stay unpublished.

Post-merge: overtaken by a second audit, and what changed before commit

The Phase 6 sync pulled late-promoting fires this run could not see — among them 2026-08-23T1311Z-audit, a second quality audit over an almost identical window, plus the 08-21 and 08-22 intel fires and their entries. Per the overtaken-run rule, every not-yet-pushed artefact was re-deduplicated against the newly visible state before commit:

• The SPIP entry was rewritten as an update_of delta on 2026-08-22/spip-two-unconditional-preauth-rce-releases-three-days-apart, which the late-promoting 08-22 fire had already published — carrying only the 2026-08-24 identifier assignments (CVE-2026-77806; CVE-2026-77647 to CERT-FR's companion advisory). The other three entries collide with nothing.
• This run's duplicate run-clock gate check was discarded: the 08-23 audit found the same completion-timestamp defect independently and its v3.33 fix (check_run_clock, the Phase 6 re-stamp) reached main first. The two remaining changes this run's prompt work adds — the preflight ground-truth checks and the no-patch-from-vendor rule — ship as v3.34 on top of their v3.33, with the collision disclosed in the CHANGELOG. This record's prompt_version is v3.34, the version as of the commit; the loop above executed under this run's own v3.32 draft.
• The backlog files were merged (their base; their GeoServer correction-owed row struck as fulfilled by this run's published correction; this run's Cisco Crosswork and Bloctel rows dropped as covered by their side; twelve of this run's rows re-appended), and the mysites-guru, nozomi-networks, claroty-team82 and forescout-vedere source fixes were re-applied on top of their sources.json, whose own tenable-research fix (a different working feed URL) was kept over this run's.
• The availability finding narrows to 2026-08-14 — the only genuinely record-less day once the late promotions landed. Two separate operator signals replace it: several fires' promotions sat unmerged long enough that two audits planned against a stale picture, and two fires on 2026-08-24 booted with container clocks reading 2026-08-16 (this one recovered mid-run; 2026-08-24T0906Z-intel stood down).
• Un-audited residue, bounded and named: the 08-21 and 08-22 entries were never truth-checked by this run's batches (they were invisible at partition time). The next audit should confirm the 08-23 audit's batches covered them and truth-check whatever was not.

The full reconciliation is in the audit report's post-merge addendum.

Full findings, root causes, fixes and the recommendation list: docs/audits/2026-08-24-weekly-quality-audit.md.