Modes
A site the table does not list is
copy_kit.
Today a listing or profile update goes out one of two ways. On an api_oauth row it is filed through the site’s official integration. On every other row you file it yourself from a copy kit. There is no route that files anything in a browser on another site, so a row in a browser mode would also get the copy kit. The only browser work agents do is the weekly walk of your own site, which this table does not govern because the site is yours.
Rules every row follows
- Your accounts only. An agent acts only on an account you own. It never creates one.
- A browser mode needs a review. A row can be
browser_fullorbrowser_assistonly if all of these hold: the site’s terms allow automation or say nothing about it; the site does not verify a person during the action (by phone, ID, video or post); and someone read the terms, quoted the clause the row rests on and recorded the date, less than 180 days ago. When a review turns 180 days old, the row drops tocopy_kituntil it is reviewed again. - Five sites never get a browser mode: LinkedIn, Reddit, Yelp, Wikipedia and Quora, including their subdomains. No row, override or review can change that. Agents never post on Reddit, forums, communities or Q&A sites.
- A subdomain is capped at
copy_kit. It inherits its parent’s limits but not its automation, because a subdomain is often a different product with different terms. - Request reviews means preparing a review-invite kit that you send to every customer through the platform’s own tool. No agent ever sends one.
- Disclosure. Some rows carry a disclosure rule, for example never ask for reviews in exchange for anything. Anything filed on that site follows it.
- Rate limits. Each row caps actions per workspace per day, and across all workspaces per day.
The table
Every row is currently unreviewed. We have not yet read these sites’ terms and quoted them, so each stance isunknown and no clause is quoted. Nothing here is api_oauth or a browser mode yet. A row moves up only through a reviewed change to the table.
Each
copy_kit row allows one prepared kit per workspace per day. The live table, with each row’s terms page, handoff steps and how it applies to your workspace, is at GET /v1/site-policies.
When a site changes its terms
Every Monday we check each row’s terms page again, if the site’srobots.txt allows it, and compare it with the version we last saw. Markup and layout changes don’t count. Only a change to the text does.
When the text changes, that row drops to copy_kit (or stays stricter) for every workspace at once, within that same check. You never wait for us: a copy_kit site is one you can file on yourself straight away, with the steps the row gives you. The row goes back up only after someone reads the new terms and records the review in the table.
If a terms page can’t be read, or its robots.txt asks us not to, the row keeps its mode and we are told once, when it stops being readable.
Read it yourself
The table is read-only on every door. No API call, MCP tool or app screen can raise a row.api.attensira.com the same rows are objects of type site_policy: GET /v1/objects/site_policy lists them and GET /v1/objects/site_policy/g2.com reads one, each wrapped as {uri, type, workspace_id, data}. Over MCP, list with type site_policy and get on attensira://{workspace}/site_policy/{domain} read the same.
Each row gives mode (as written in the table) and effective_mode (what applies to your workspace now). If they differ, downgrades lists each step and why: subdomain, review_expired (the row no longer meets the bar for its mode, usually a review past 180 days), tos_changed, never_browser, overrides_unreadable (we could not read the downgrades just then, so every site is treated as copy_kit or stricter), or a downgrade set for your workspace. A domain not in the table answers with known: false and effective_mode: "copy_kit".