> ## Documentation Index
> Fetch the complete documentation index at: https://docs.attensira.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Keeping changes live

> Every week we read the page of each change that moved its answers, or that a win sits after, and check the shipped text is still there. A change that is gone is marked no longer live and a re-ship is filed for your approval. A page we could not read is never marked gone.

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](https://docs.attensira.com/measure/receipts.md) 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](https://docs.attensira.com/agent/wins.md) 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](https://docs.attensira.com/measure/before-and-after.md) checks use.

The weekly check costs you nothing: its reads never draw on your balance, and it runs when your balance is spent.

| What the read found | What happens |
| - | - |
| The shipped text is on the page | `live_status` is `live` |
| The page answered and the shipped text is not on it | `live_status` is `no_longer_live`, with the page, the date and what we looked for. One **re-ship** change is filed |
| Your site refused us, showed a bot challenge, answered with a page that has no words on it, or answered with its own error | Nothing changes. We retry the read, waiting longer each time, and read again next week |
| Your site says the page is not found | Nothing changes: the change is not marked gone, and nothing is re-shipped onto a page that does not exist. We read it again next week |
| The read failed on our side (our reader, a rate limit, a domain we do not read) | Nothing changes and nothing counts against your site. We retry, and fix it on our side if it keeps failing |

**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](https://docs.attensira.com/agent/approval.md) 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](https://docs.attensira.com/agent/findings.md) 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](https://docs.attensira.com/api/endpoints.md#get-/v1/changes).
* The `change.no_longer_live` [webhook](https://docs.attensira.com/api/webhooks.md) 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.

## Related

* [Receipts](https://docs.attensira.com/measure/receipts.md): what each change did.
* [Before and after](https://docs.attensira.com/measure/before-and-after.md): how the checks are measured.
* [Findings](https://docs.attensira.com/agent/findings.md): the hourly rules, including a lost citation.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.