A changed page is not always news
Our news system needed to tell a new fact apart from a moving view counter, a related story and a new picture. Those are different kinds of change—and readers should see the difference.
The question behind the work
The problem
A news website has to notice developments without pretending that every change is news. A source page can change because someone read it. It can contain another story below the article. Our own page can change because we add a photograph. None of those events, by itself, tells a reader that the reported facts have changed. In AI NewsView, source extraction and front-page selection needed separate evidence for separate jobs.
01
What we tried
- We narrowed source extraction to the article and excluded related-content sections, while retaining substantive list items. We also changed the writing instructions to distinguish an announcement from its deadlines and eventual results.
- We checked the original source date separately from our publication date. One research-grant announcement was dated 25 August, although our own article appeared on 27 September. Publishing an explanation later did not make the announcement new.
- We separated first publication, an evidenced substantive update and technical maintenance in front-page selection. We tested a later publication as a synthetic input, then checked the existing server runner independently.
- When Romanian source pages kept raising review leads, we reconstructed recorded hashes from the current article text while changing only its view counter. We did not have stored historical article bodies. We tested a narrow exclusion for the source site's counter label, Afisari.
- On 3 October, we followed the existing server chain from source intake to publication. We compared its successful run records with the model-call ledger, held items and the public publication journal. We then added a narrow pause for an exactly identified provider credit error, without changing the scheduler, provider or editorial review gates.
- On 4 October, we traced an ordinary failed-run report through the whole worker. The item had been safely deferred by the quota guard, but the outer error handler still labelled the run as failed. We narrowed the correction to that run-status assignment, keeping the credit error visible and genuine technical or editorial failures distinct.
02
What happened
- The September source-boundary and writing corrections were published and checked on the public article. The source's August date remained distinct from our September publication date. The release record proves the correction; it does not measure every earlier extraction error.
- On 1 October, five consecutive normal server cycles completed the front-page step. Across that observation, all 87 protected canonical article records were retained, and the publication journal, feed and sitemap stayed unchanged. That was a production observation of the runner, not an observed new publication.
- On 2 October, that reconstruction matched 14 recorded changes across two Romanian source pages using counter changes alone. Seventeen older unmatched changes remained unproven. We kept that uncertainty instead of classifying the whole backlog as noise.
- The counter repair was checked against the 14 exact pairs and two tests that changed real article text. The executor also ran 20 sensitivity checks. Independent review confirmed the one-file deployed repair and preservation of the existing review queue. No public article was changed by that repair.
- Later on 2 October, read-only server evidence showed ordinary source fetches at 10:15 and 16:15 in Amsterdam time. Both monitored articles returned HTTP 200. The first fetch produced two expected normalization leads; the second kept both normalized article hashes unchanged. Eight other leads came from discovery listings and still required research. All 56 prior review entries were retained.
- The runner completed normally, but its publication journal showed no new automatic publication after the afternoon of 1 October. Fresh leads were still arriving. The model ledger instead contained an explicit provider credit-balance error. This was an account-capacity problem, not evidence that there was nothing worth reporting.
- The worker had treated that error like an ordinary failure and consumed an item's retry allowance. We changed the handling so that a confirmed credit error defers model-dependent work without spending another attempt. A shared pause also prevents repeated calls during the pause. Independent tests covered the pause before any network call and a single recovery-probe lease after it expires.
- Independent review passed the four-file repair. We retained exact rollback copies, verified the deployed files and observed the next ordinary server cycle complete. That cycle had no eligible model stage, so it did not demonstrate the live pause path. The public homepage, news listing and publication journal stayed unchanged. One existing sport-only record's scope explanation was refreshed by the normal worker; its article content and dates were retained.
- A later read-only check on 3 October established the live pause path. Five ordinary recovery calls between 15:33 and 19:39 Amsterdam time still returned the exact credit-balance error, roughly an hour apart. Ten items carried the typed credit-error or pause result and remained at the researched stage. Two evening snapshots showed the same stage and no retry-counter field for those items. All 209 older generic model-error blocked items remained unchanged, and the publication journal still showed no new automatic publication. This later evidence extends the first-cycle observation; it does not turn that earlier cycle into a model-stage test.
- The early-morning run demonstrated that mismatch: an explicit credit pause preserved the item while the worker returned a failure exit. Seventy-two isolated whole-worker cases tested the before-and-after path across four publishing stages. Confirmed credit errors became deferred outcomes; generic provider, source, claim, image, lock and native PHP errors still failed. Independent review passed the one-file correction, and exact deployed and rollback hashes were verified. These tests used synthetic dependencies and no network calls.
- At the first post-activation readback on 4 October, the new worker file matched the reviewed candidate and the other runtime files were unchanged. A normal corrected credit-deferral path had not yet been observed in that initial capture; its live confirmation remained a separate check.
- The later ordinary cycle on 4 October, from 08:37:02 to 08:37:12 Amsterdam time, reached the credit-pause path. The worker now reported deferred credit work, kept the pause error visible and returned a normal completion exit to the runner. The matched item remained researched; its retry-counter field remained absent, and its draft and review were retained. The publication journal was byte-for-byte unchanged. This confirms the corrected run classification in one real cycle, not restored provider credit or a new publication.
03
What we learned
A page-change detector supplies a lead, not a finding. It should tell the newsroom where to look; the newsroom still needs to identify the changed fact and its source.
Three dates answer three different questions: when the source published, when we first published, and when a material development justified an update. A new photo or a fresh technical check belongs outside the news chronology.
Removing noise must not remove the story. A counter exclusion needs tests showing that real body changes still trigger detection. Older changes that cannot be reconstructed must remain unresolved.
A normal server run, a simulated new-publication test and a verified new public article each prove something different. Combining them into one broad claim of autonomous journalism would hide the remaining evidence gap.
A successful scheduled run means the process finished. It does not mean a checked article reached readers. Intake, research, model availability, editorial review and public verification need separate evidence.
A provider credit shortage should pause the affected model stage rather than silently exhaust each story's retries. Local tests and exact deployed files establish the repair; they do not prove that account credit was restored or publication resumed.
An item can be handled correctly while the surrounding run reports the wrong outcome. A credit pause should be visible as deferred work, rather than a broken worker or a successful publication. Correct classification still does not restore provider credit or produce an article.
04 · Outcome
The decision
ADOPT. Keep article boundaries, original dates and material-update evidence as separate publishing controls. Treat a source alert as a research task until the changed facts are checked. Keep technical maintenance from refreshing an old story's news position.
Where the evidence leads
What this means next
Keep deferred credit work distinct from genuine worker failures and verified publication. Provider account capacity remains a separate unresolved dependency. Preserve older generic model-error items until their individual histories can be established, and continue source research and unrelated work while model-dependent publication is paused.
See AI NewsView