Skip to main content
A change is one piece of work an agent filed for you: a page fix, a rewrite, an article, a listing, a pitch, a post. Every door shows the same change: the app, your Inbox, email, Slack, the REST API and the MCP server. Each change carries its lane (own_site, offsite, outreach or social), its class (safe, claim or never, see the classes), and whether it can be undone. Together with the lane’s autonomy level, those decide whether it waits for you.

​
What a change goes through

A change can also end in one of four ways: GET /v1/changes?lifecycle= filters by stage (GET /v1/changes and GET /v1/changes/{id} are served on webapp.attensira.com and not on api.attensira.com yet, which answers 404; over MCP, list with type change and get on a change’s address read through them), and the change.shipping, change.live and change.reverted events follow a change without polling.

​
Reviewing a change

Open a change from your Inbox to read it before it ships: the draft, the page it is for, the evidence behind it and the result of the draft check.
  • Approve ships it as written, Edit ships your version, and Decline takes a reason so the same change does not come back. An approval is bound to the version you read; if the draft was revised since, you are asked to read it again. See Acting on a row.
  • Section by section. A longer draft is split at its headings. You can accept, reject or edit each section, or have the sections nobody decided written again; every edit and rewrite passes the draft check before it is kept. Over the API: GET /v1/changes/{id}/diff and the section actions of POST /v1/actions.
  • A pull request can be read live from GitHub inside Attensira, and merged from there with a second, separate yes. See Reviewing a pull request in Attensira.

​
The 48-hour window

In a lane at L3, a safe change that can be undone is approved for you with a window: it ships 48 hours after it is filed unless you stop it. The change says when (“Ships Wed 21 Oct 12:00 EEST unless you stop it”), and carries ships_at.
  • Stop keeps it from shipping. It takes a reason, which keeps the same change from coming back. A stop that arrives a moment after the change started shipping is refused with veto_lost_race, never ignored: undo it instead once it is live.
  • Ship now ends the window and ships it on the next publish pass, a minute or so later. It is a yes like any other, so it is held to the same rules as approving: a key needs an approve scope covering the change’s lane and effect class, and never ships something that cannot be undone. Over the API: POST /v1/changes/{id}/actions with {"action": "ship_now"}. A change that was stopped, declined or never scheduled is a 409 that says which. Ship now is not on MCP yet.
  • If you lower the lane before the window ends, the change does not ship; it waits for your yes instead.
The full rules, including what happens when a stop and the ship arrive at the same moment, are in Stopping a change in its 48 hours.

​
The Weekly Ship

Once a week, your own site’s changes are put together into one decision: the Weekly Ship. Instead of a row for each fix, you get one row in your Inbox, titled with what is in it, for example “Weekly Ship: 9 changes (4 page fixes, 3 rewrites, 2 articles)”. When. At 09:00 on Monday in your workspace’s time zone (UTC when none is set). A set is only made when at least 2 changes can join it, and holds at most 40; anything past that waits for the next week. What joins. Open changes to your own site (page fixes, rewrites and articles) that are classed safe, can be undone, and that the draft check passes. A change that is waiting for your yes joins, and so does one already counting down its own 48-hour window. A claim, a change that cannot be undone, and a draft the draft check holds never join: each keeps its own row and its own yes, so one change never makes the whole week wait. Listings, pitches and posts are never in a Weekly Ship. Deciding the set.
  • In a lane at L3, the set is scheduled like any other change: it ships 48 hours after it was made, unless you stop it. Joining a set never ends a change’s own window sooner.
  • At L2 or below, the set waits for your yes. Until you decide, changes drafted later in the week are added to it, and its version moves, so a yes always covers the set you read.
  • Approving the set approves each change in it at the version the set took in. Stopping the set stops every change in it. Declining it declines the drafted changes and stops the scheduled ones.
  • The changes in a set are listed with GET /v1/changes?bundle={id} (on webapp.attensira.com); the set itself is a change of kind: bundle.
How it ships. Each change goes out the way it would alone, together:
  • Through a repository: one pull request per repository, on one branch (attensira/weekly-ship-…), with one commit per change, so you can review it commit by commit or as one diff. The pull request lists every change in it. See The Weekly Ship on GitHub.
  • Through your CMS or Notion: each change is written in the same pass, one draft or update each, because those editors have no way to hold several pages as one draft. They are approved, stopped and undone with the set.
  • With nothing connected: the changes go into one paste pack: a single page with each item, the page it belongs on, the passage it replaces and what to paste. One Inbox row says “Your Weekly Ship paste pack is ready: 3 items to put live”. Paste each one into your site, then mark it shipped with its live link, one item at a time; we never say an item is live that you did not mark. Over the API, mark each item with POST /v1/inbox/{id}/shipped and its live URL.
What can leave the set. Before anything ships, each change is asked again everything it would be asked alone: its class, its lane’s level, the caps, the connection, and whether the page changed. One that fails is taken out of the set, with the reason on its own timeline (“Left out of this week’s Weekly Ship: …”), and the rest ship. A change whose page moved since it was drafted comes back with a fresh diff for you to review. A change that was revised after the set took it in needs its own look, because your yes was to the earlier version. A set is closed once every change in it went live, was decided or left it. If none of them went live, it closes saying so, never as a set that shipped.

​
Undo

A change we shipped can be undone for 30 days after we made it. Press Undo on the change, or call POST /v1/changes/{id}/actions with {"action": "undo"} (over MCP, act_on_change with undo). It is the same undo through every door, and asking twice starts nothing new. How the undo works depends on where the change went: An undo never writes over a person’s edit. Before writing, we read the page or file again. If somebody changed it after us, nothing is written: the undo stops and tells you what is there now and how to put it back by hand keeping the edit you want. While it runs the change shows Undoing…, and when it is done, Undone, with what is back on its timeline. A change that is partly undone (a revert pull request that waits for your merge, for example) says which step is yours. If the undo fails after its retries, one row in your Inbox gives the reason and the step to do it yourself. Nobody at Attensira does an undo by hand. On the API, every change carries undo: its state (available, undoing, undone, undo_partial, undo_failed, expired or not_reversible), the sentence a person reads, the step when one is yours, until (when the 30 days end) and url (the revert pull request, once there is one). An undo that finishes sends change.reverted, and the change’s receipt says it was reverted.

​
What cannot be undone

Some changes have no way back that we can take:
  • A sent pitch or email. Mail cannot be recalled.
  • A listing, a profile update, a post or an answer on another site. Those live on someone else’s site or your own account there; you remove them there.
  • Spending money.
These are exactly the changes that wait for your yes at every level. They never ship when a window ends, and they never join a Weekly Ship. For such a change there is no Undo button. Asking for one over the API answers 409 not_reversible with the sentence, and, where we can name the place, the step that does it yourself, for example “Edit /pricing back to how it was.” The same answer comes back for a change past its 30 days (“The 30-day undo window closed on Oct 3.”), with the step for a pull request: “Open pull request #12 on GitHub and use its Revert button, then merge the revert.”