11. Notice standard

FM-11.1 Purpose#

A notice is the public page for one incident. It lets anyone targeted by the same agents recognise the activity in their own logs, tells the public whose agents were involved at the stated strength and, once their naming lead has run, which organisations were affected, and keeps a permanent, dated record of what was known when. One incident has one notice.

FM-11.2 Structure#

A notice is published in two stages (FM-10.2): the indicator notice, then naming updates appended to it.

Front matter: the notice id, the status (FM-11.3), the providers named (with label), the affected hosts named so far, the scope finding and agent grade of the clusters it covers (FM-15.4), and the dated updates.

Body of the indicator notice, in this order:

1. Summary. What happened, to what classes of target, when, and the attribution Conclusion with its label and likelihood words.
2. Targets. Each affected endpoint by target class and sector only (FM-15.2), with what it saw: compromised, targeted or historical.
3. Attribution. Each layer that has a claim (FM-7.1), with tagged claims (FM-7.6).
4. Timeline. Clusters and runs with first and last seen, naming the timestamp kind.
5. What to look for. Indicators safe to publish: relays, carriers, tactics, payload families and shapes, run tags already published elsewhere that are not credentials, the kinds of callback service used.
6. Withheld. What was withheld, by category, and why (FM-11.4).
7. Method and limits. The method version (cite this manual), the rules version, the limits that bear on the claims (chapter 14), and that the notice was reviewed by a second reviewer before publication (FM-10.9).
8. Updates. Dated entries, oldest first, never rewritten.

The indicator notice names and locates no affected party: no organisation name, host (defanged or not), registrable domain, IP address or network of a target, and no target URL or path that contains an affected host.

A naming update names the affected organisations whose naming lead has run or who consented, each with its defanged hosts and what its endpoints saw. Later naming updates name the rest; an operator the practitioner decided never to name is not named.

Hosts are defanged (a[.]b) and no URL from a record is a link.

Who is named, and how.

• An affected organisation is described as targeted or affected, never as the actor. "Compromised" appears only for an endpoint classified so on a recorded basis beyond the requests it received.
• An endpoint seen only in records anyone could have submitted is named only with the practitioner's logged reason, as "URLs targeting <organisation>'s hosts were submitted to public scan services".
• A provider below shared identifiers is the party notified, in these words: "Requests in this cluster identify themselves as using <model> from <provider>. Self-identification is the weakest evidence we use. We have not confirmed that <provider> operated, deployed or authorised them. <provider> has been sent the full evidence." The title never names it.
• At provider infrastructure, the notice says the requests came from infrastructure that the provider operates, and keeps who deployed them separate.
• The activity is described as suspected AI agent activity. "Misaligned" appears only where FM-15.4 allows it.

Toolkit: case notice drafts the indicator notice from the case, and the admin edits it. The draft's attribution section gives each host claim, and each developer claim that passes the naming gate, with its layer, label, claim tag and evidence, and a Conclusion line for each named developer; a developer below shared identifiers gets the notified-party line, with its label and tag, and the sentence about the evidence only when a send to the provider is recorded; harness and model-family candidates are left out. Claim tags outside the attribution section are added by hand. The naming update is drafted into the case's naming.md and appended with notice update --naming (notices).

FM-11.3 Status lifecycle#

Every status change is a dated update with its reason. Toolkit: the watch matches new records against each case's indicators and proposes status changes; the admin applies them (watch).

FM-11.4 What a notice withholds#

Content from a source whose terms forbid redistribution is never quoted; the notice links the record and gives derived indicators (FM-3.4). Private reports carry what the recipient needs, including what the notice withholds (FM-10.1).

FM-11.5 Lint#

Every notice is checked by a program before publication and on every later change, for: callback channel identifiers, e-mail addresses other than role mailboxes, credential shapes, well-formed front matter with updates in date order, attribution statements without a layer, label or tag, likelihood words stronger than their labels allow, a title naming a provider the notice does not name as a developer, an affected host in the indicator notice, and the word "misaligned" without the scope finding and agent grade that FM-15.4 requires. A notice that fails is not published.

Before publication, the self-review checklist and the second review cover what the notice alone cannot show (FM-10.9). The lint is a last check, not the withholding itself: the draft is built from a withholding view, and the lint catches what got through (notices).

FM-11.6 Corrections and retractions#

A published notice is never rewritten. Each change is an appended, dated update of one kind:

The feed carries every update, so a reader who saw the original sees the correction. A withdrawn attribution stays visible as withdrawn (FM-2.6).

FM-11.7 Permanence#

A notice id, once published, keeps its address. Notices are published from a version-controlled repository, so every state of every notice is recoverable. Committing a notice publishes it; nothing else does (notices). A notice is published, and each operator named, no earlier than the lead times allow (FM-10.2), and its first update says who was reported before it and for whom no contact could be found.

Every section by id, with search

Source: docs/manual/11-notices.md