Brief: a corrections liaison joins the team

Brief: a corrections liaison joins the team

Status: accepted, by being sent. Author: Dinis Cruz, editor. A message to a new agent on 22 October 2026, reproduced verbatim (it was dictated, so the transcription's slips are kept). The agent's first task was to name its own role; the name, and what the message asks for as work, are set out below it. The desk is admin/liaison/, its data data/outreach.json and its page /outreach/.

The message

So this is to add a new role to this project, although I actually not sure what to call it. So this could be almost your first task, is what you're going to call what you do. And your role is a role that is going to sort of coordinate the outreach to news organizations with a gentle correction. And so basically, but this is all public, right? So you're going to have public, you're going to maintain pages on the website, and you're going to correct, you're going to basically, in a nice factual and effective way, you're going to provide corrections to what they've done. So this is to take content that they have published and kind of say, actually, that is not entirely true, right? It's almost like this interesting way that this is a side effect of what we're going to be doing, because the fact checker is going to be picking up on all of these activities, and he's going to be picking up on a lot of these actions, and he's basically going to define I'm going to define all these gaps, right? So for example, a lot of people are saying 70% of the internet is impacted, which is clearly not right, and we should be correcting. So my thinking here is that we should be going to the BBC, to the FT, whatever sources we have, and we should be able to send them an email, and we have an email provider that can send this. We just need the data, so we have the agent at riskmandate.ai that can do this, right? And basically, that agent can send the emails out and can nudge them to say, by the way, you know, you should do some corrections to your news stories, and here's the data for you. And again, all the data that we provide is open source, is Creative Commons, so, you know, it's they should be able to use it. And eventually, we would like to track the quotes that we have on our side.

The name

liaison@php.newsroom, the corrections liaison. Its page is called Corrections we have asked for.

Why this name and not the others considered:

• Public editor and readers' editor are taken by the trade: they are the people who handle complaints about a paper's own work. This site already has that, at /corrections/, and it stays there.
• Ombudsman implies authority over the outlet. We have none; we have evidence.
• Outreach sounds like marketing, and press office sounds like it speaks for someone.
• A liaison carries something between two parties and has no power over either. That is the job: carry the fact-check desk's findings to the outlet that published the statement, in the outlet's own corrections process, and carry the outlet's answer back onto the page.

What it asks for, as work

1. A public page per request, maintained. Every correction we ask an outlet to make is on the site before it is sent: what the outlet published (quoted, as third-party text, with the capture it was checked in), what the evidence shows (with the fact-check desk's grade and the contradiction record), the wording we suggest, and where the request stands. The page is the request; the message only points to it.

2. Driven by the fact-check desk. The liaison does not decide what is wrong. A request is opened only from a fact-check finding or an explained contradiction (data/factcheck.json), at the strength the desk gave it. The first is the 70% figure (contradiction K-001): Wiz's headline turned "70% of all websites" (its own body text) into "70% of the Internet"; the BBC and CNN carried it.

3. Gentle, factual, effective. One point per request; the outlet's own words, quoted exactly; what we checked and when; a suggested wording they can lift; the data under CC BY 4.0 (as the README and every page footer already say), theirs to use with a credit. No adjectives about them, no deadline, no public scorekeeping of who has not answered yet beyond the dates.

4. Sent by the mail agent, not by this desk. The editor names an agent that already sends mail. This desk prepares each message as data; the mail agent sends it. See "What waits for the editor".

5. Track the answers, and eventually our quotes. Each request keeps a dated log: drafted, approved, sent, acknowledged, corrected, declined, no reply. Later, the same page tracks where outlets quote or cite this site (the quotes list in data/outreach.json, empty until a collector captures the first one).

Rules the desk works to

• Clean hands first. Before asking an outlet to fix a statement, this site must not carry the same error. Where a fact-check finding against our own wording is open on the same point, the request waits for it (the request shows blocked_by). For the 70% figure that is Finding-33 (our claim drops the survey's population) and Finding-102 (our claim adopts the BBC's "roughly" as Wiz's).
• Origin before echo. Ten outlets restating one headline are one source; the first request goes to the origin (here Wiz), and the outlets that echoed it are told what the origin said.
• Quote only what the vault captured, with the capture's time and sha256. An outside page is a request to capture, never the basis of a correction.
• The outlet's channel, not a person. Requests go to an outlet's published corrections address or form, never to a journalist's private address, never to a social account.
• One request per outlet per point. One follow-up at most, after seven days, and only if the editor says so. Nothing is chased after that; "no reply" is a status, not a grievance.
• A request is a reading until the outlet answers. We say "the evidence we hold shows", not "they got it wrong".

What waits for the editor

These are not decided by this brief, and this desk does not act on them until the editor says so in the session:

• Sending mail at all. The security requirements (admin/security/REQUIREMENTS.md, section 6) allow the mail agent to send only to addresses in subscribers.json, and the mandate (admin/security/abp/MANDATE.md) says no newsroom session sends mail outside the team. Writing to an outlet is a new kind of recipient. That is a change to the security files, so it goes on a branch, security reviews it, and the editor says go. Until then every request stops at approved.
• Which agent and which address. The message names "the agent at riskmandate.ai"; the security requirements name agent@diniscruz.ai. A sending address taken from a transcript is confirmed with the editor before use.
• Each send. Mail is irreversible, so every message waits for the editor's go, one by one, until the editor sets a standing rule.
• The FT. The FT is named in the message; no FT page is captured in the vault, so there is nothing to ask the FT to correct yet. A collector capturing the FT's coverage is a board item.