Skip to main content
A change that shipped can stop being on your site: a redeploy rebuilds the page from an older copy, someone edits the paragraph, a template change drops a meta tag. Nothing about the change’s receipt would tell you, because its checks ended at +30 days. So once a week the agents read those pages again.

​
Which changes are checked

Every week, each workspace’s shipped changes that are either:
  • Moved: the change’s receipt verdict is Moved (a check at +7, +14 or +30 days, past the significance test; an early look never counts), or
  • Linked to a win: a win sits after the change, on its page or its question.
Only a change made to a page (its target is the page’s address) is read. A fix to a file in your repository is not: the file’s source is never on the rendered page word for word, so checking it there would call a live fix gone. When a newer change to the same page and field has shipped, or is on its way, the page is expected to carry the newer words. The older change is recorded as replaced by it, never marked gone, and nothing is re-shipped over the newer one.

​
What the check does

We read the change’s page fresh, through the same page reader the agents use everywhere else, and look for the text the change shipped, with spacing and capital letters ignored and nothing looser. An article is never on its page word for word as it was drafted, so for an article the page answering with content at its address is the check, the same rule the before and after checks use. The weekly check costs you nothing: its reads never draw on your balance, and it runs when your balance is spent. A page we could not read is never marked gone. Only a read that came back with the page can set no_longer_live.

​
The re-ship

A re-ship puts back the change that is gone: the same page, the same words, the same class the original had. It is filed like any other change, so your autonomy level for the lane and your 48-hour veto decide whether and when it ships. Nothing is re-shipped without that path. One re-ship is filed per loss. A change still missing the week after is not filed again; a change that is put back and later goes missing again gets a new one.

​
When a win loses its citation

When the hourly findings see a page of yours stop being cited, and a win sits after a change on that page, the Inbox row for the lost citation names the win and the change, and one defend change is filed for that page and the win’s question. The row still appears as it always has. While that defend change is waiting (for your yes, in its veto window, or shipping), the hourly pass files nothing more, however long the loss lasts. Once it has shipped or been declined, a loss that is still there is defended again only after 30 days.

​
The 90-day refresh

When a win’s change shipped 90 or more days ago and no newer change has been filed for its page, we read the page against our freshness rules and file one refresh proposal:
  • A sentence that calls an old fact new (“our new integration, launched in 2023”) gets a change that cuts the stale word. Updating the fact itself needs a fact only you have.
  • A figure with an old year, or with no year and no source, becomes a question in your Inbox asking for the current figure and where it comes from. We never invent the number. If you already gave the current figure, in the Inbox or as a lasting fact in a chat, you are not asked again: the Inbox row shows your earlier answer and the fact it came from, and Draft the update starts a run that drafts the change from that answer. The change waits for your approval.
  • A page with nothing stale gets nothing. In particular, we never propose a date-only edit: a visible date is not what gets a page cited, and we do not stamp one for its own sake. A page the rules found current is read again after 30 days.
Each shipped change gets at most one refresh proposal in its life.

​
When we cannot read your pages

We decide whose a failed read is only from what your site itself answered. If your site refuses, blanks or errors on the reads of a workspace’s pages on two weekly checks in a row (a retried check in the same week counts once), you get one Inbox row for the workspace: We cannot check that your shipped changes are still live, with what you can do. Usually your site or its firewall blocks automated readers, and allowing ours for your own pages fixes it; otherwise the site moved or its connection was removed, and reconnecting it does. The check keeps running every week either way. A failure on our side never raises this row and never says your site blocks us. If pages where our changes shipped answer not found on two weekly checks in a row, you get one question for the workspace instead, naming the pages: tell us where they moved, or that you took them down on purpose.

​
On the receipt

A receipt shows live_status, last_live_check_at and the read’s evidence: the page, whether the text was found, when, and the re-ship filed when it was not. The receipt’s verdict is not rewritten: what the answers did after the change shipped stays what they did.

​
Over the API and MCP

  • GET /v1/changes/{id} and get on attensira://{workspace}/change/{id} carry live_status (live, no_longer_live, or null before the first weekly read) and last_live_check_at.
  • GET /v1/changes?live_status=no_longer_live, and list with type change and the filter live_status: no_longer_live, list every change found missing. See the endpoint reference.
  • The change.no_longer_live webhook is sent once per change per week it is found missing, with the page, when it was read and the re-ship.
Every read is free and works when your balance is spent.