Reference

Report Management (RM) Messages

The RM shorthands inform other Participants of the sender's report-handling state. Receipt of a Report Submission is the only RM message whose receipt directly triggers an RM state change in the receiver; all others convey the sender's status.

The RM state ladder has two wire expressions: the dedicated report-scoped activities listed below, and the rmState field of an Add(ParticipantStatus) broadcast (see Case State (CS)). Report/Case Accepted (RA) and Report/Case Deferred (RD) additionally take case-scoped verbs — Join(VulnerabilityCase) and Ignore(VulnerabilityCase) — because engaging or deferring is a case-participation decision rather than a report-validity judgment (MSM-01-004, MSM-01-005).

The CASE_MANAGER applies one rule to an RM state whichever of these expressions carries it (RSH-06-006). The state is recorded for the sender, never for the receiver (RSH-08-001), and only when the sender is a participant of the case. A forward move is recorded even when it skips states, and the CASE_MANAGER then asks the sender in a note which path it took (RSH-06-001, RSH-06-004). A backward move is refused and the recorded state stands (RSH-06-002), and the CASE_MANAGER tells the sender in a note that it refused the move (RSH-06-004). Either note is recorded on the case as a case ledger entry. The sender receives it from the ledger, as every active participant does, not as a message addressed to it alone (RSH-06-004). An activity and an Add(ParticipantStatus) that report the same move record it once (RSH-08-002).

When the CASE_MANAGER refuses an RM message because a precondition does not hold, such as a backward move, it also sends the sender the refusal notice (CLP-02-005, CLP-05-001). The notice is a Reject of the refused message, with the reason in summary, and the CASE_MANAGER records nothing of the refused message in the ledger. The note about a refused backward move is recorded alongside the notice, not instead of it (RSH-06-004). The CASE_MANAGER sends no notice when the sender is not a participant of the case, or when the message restates a state already recorded (RSH-08-002).

Occasions

When…	Send	Send to	Sent by	Distinguished by	Details
a Reporter has written up a vulnerability and is about to submit the report	Create(VulnerabilityReport)	an actor outside any case	any actor (usually: reporter)	—	Create report
a Reporter submits a vulnerability report to a Vendor or Coordinator	Offer(VulnerabilityReport)	an actor outside any case	any actor (usually: reporter)	—	Report Submission (RS)
a report receiver has read a submitted report	Read(Offer(VulnerabilityReport))	an actor outside any case	the addressee of the vulnerability report offer (usually: vendor, coordinator)	—	Report Acknowledgment (RK)
a report receiver judges the report valid	Accept(Offer(VulnerabilityReport))	the case manager	a participant (usually: vendor, coordinator)	—	Validate report
a report receiver judges the report invalid	TentativeReject(Offer(VulnerabilityReport))	the case manager	a participant (usually: vendor, coordinator)	—	Invalidate report
a report receiver closes a report no case holds	Reject(Offer(VulnerabilityReport))	an actor outside any case	the addressee of the vulnerability report offer (usually: vendor, coordinator)	—	Close report
a Participant accepts the case for further action	Join(VulnerabilityCase)	the case manager	a participant	—	Report/Case Accepted (RA)
a Participant defers further action on the case	Ignore(VulnerabilityCase)	the case manager	a participant	—	Report/Case Deferred (RD)

Create report

Mints the vulnerability report object. It precedes the Offer that submits the report.

• When… a Reporter has written up a vulnerability and is about to submit the report
• Send: Create(VulnerabilityReport)
• Send to: an actor outside any case
• Sent by: any actor (usually: reporter)
• Seen in: How to Report a Vulnerability
• Mapping status: none

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Create",
  "id": "urn:uuid:1c100b82-9564-4ddc-8cef-e331af5648bc",
  "name": "https://vultron.example/users/finndervul Create FDR-8675309",
  "actor": "https://vultron.example/users/finndervul",
  "object": {
    "id": "https://demo.vultron.local/VulnerabilityReport/e28f4965-7838-4644-b4a8-10604c7ee92f",
    "type": "VulnerabilityReport",
    "name": "FDR-8675309",
    "published": "2026-10-23T20:17:06+00:00",
    "updated": "2026-10-23T20:17:06+00:00",
    "content": "I found a vulnerability!",
    "attributedTo": "https://vultron.example/users/finndervul",
    "@context": "https://certcc.github.io/Vultron/ns/context.jsonld"
  }
}

• Triggering transition: none (object construction, not a state change).

Report Submission (RS)

Offers the report to a new Participant. The Offer may carry proposed embargo terms.

• When… a Reporter submits a vulnerability report to a Vendor or Coordinator
• Send: Offer(VulnerabilityReport)
• Send to: an actor outside any case
• Sent by: any actor (usually: reporter)
• Seen in: How to Report a Vulnerability
• Formal definition: Report Submission (RS)
• Mapping status: direct

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Offer",
  "id": "urn:uuid:69ed1398-67c6-4e84-9cbf-2eb8a587fcf9",
  "name": "https://vultron.example/users/finndervul Offer FDR-8675309",
  "to": [
    "https://vultron.example/organizations/vendorco"
  ],
  "actor": "https://vultron.example/users/finndervul",
  "object": {
    "id": "https://demo.vultron.local/VulnerabilityReport/e28f4965-7838-4644-b4a8-10604c7ee92f",
    "type": "VulnerabilityReport",
    "name": "FDR-8675309",
    "published": "2026-10-23T20:17:06+00:00",
    "updated": "2026-10-23T20:17:06+00:00",
    "content": "I found a vulnerability!",
    "attributedTo": "https://vultron.example/users/finndervul",
    "@context": "https://certcc.github.io/Vultron/ns/context.jsonld"
  }
}

• Triggering transition: emitted when the sender is Accepted (sender ∈ A).
• Receiver: the receiver does not refuse a new report on the sender's standing; it acts only when it is in the Offer's to (HP-01-010, HP-09-001).
• Proposed embargo terms: the Offer may carry proposedEmbargo, an inline EmbargoEvent whose context is the report; the case owner compares it with its own default at case creation and the shorter wins (EP-04-003, EP-04-004).

Report Acknowledgment (RK)

Acknowledges receipt of the submitted report. Report submission is not replicated through the case ledger, so the acknowledgment is an explicit message.

• When… a report receiver has read a submitted report
• Send: Read(Offer(VulnerabilityReport))
• Send to: an actor outside any case
• Sent by: the addressee of the vulnerability report offer (usually: vendor, coordinator)
• Seen in: How to Acknowledge a Report, How to Report a Vulnerability
• Formal definition: Report Acknowledgment (RK)
• Mapping status: direct

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Read",
  "id": "urn:uuid:fd62ce73-b08f-4b0b-98cf-8b45cfd5fff7",
  "name": "https://vultron.example/organizations/vendorco Read https://vultron.example/users/finndervul Offer FDR-8675309",
  "content": "We've read the report. We'll get back to you soon.",
  "actor": "https://vultron.example/organizations/vendorco",
  "object": {
    "@context": "https://www.w3.org/ns/activitystreams",
    "type": "Offer",
    "id": "urn:uuid:9efd1790-287a-429e-ac17-be4cf3489729",
    "name": "https://vultron.example/users/finndervul Offer FDR-8675309",
    "published": "2026-10-23T20:17:38+00:00",
    "updated": "2026-10-23T20:17:38+00:00",
    "to": [
      "https://vultron.example/organizations/vendorco"
    ],
    "actor": "https://vultron.example/users/finndervul",
    "object": {
      "id": "https://demo.vultron.local/VulnerabilityReport/e28f4965-7838-4644-b4a8-10604c7ee92f",
      "type": "VulnerabilityReport",
      "name": "FDR-8675309",
      "published": "2026-10-23T20:17:06+00:00",
      "updated": "2026-10-23T20:17:06+00:00",
      "content": "I found a vulnerability!",
      "attributedTo": "https://vultron.example/users/finndervul",
      "@context": "https://certcc.github.io/Vultron/ns/context.jsonld"
    }
  }
}

• Triggering transition: receipt of RS; Vultron sends RK only to acknowledge a report submission (RMB-08-003).
• Receiver: the reporter, which holds the Offer, accepts RK only from one of the Offer's addressees and refuses any other sender (RMB-08-004). RK may go to the reporter at any time after the report arrives, whether or not a case exists, but never to the CASE_MANAGER, and it writes no ledger entry (RMB-08-003, PCR-08-001).
• Object: the report's original Offer, not the report itself; a bare Read(VulnerabilityReport) matches no pattern. RK survives as a dedicated wire activity because report submission is not ledger-replicated (MSM-01-008).

Validate report

Designates the report as valid, moving the sender's RM state to Valid.

• When… a report receiver judges the report valid
• Send: Accept(Offer(VulnerabilityReport))
• Send to: the case manager
• Sent by: a participant (usually: vendor, coordinator)
• Seen in: How to Report a Vulnerability
• Formal definition: Report Valid (RV)
• Mapping status: expansion

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Accept",
  "id": "urn:uuid:48f1141a-1073-47cf-9952-0a08fd814808",
  "name": "https://vultron.example/organizations/vendorco Accept https://vultron.example/users/finndervul Offer FDR-8675309",
  "content": "We've validated the report. We'll be creating a case shortly.",
  "actor": "https://vultron.example/organizations/vendorco",
  "object": {
    "@context": "https://www.w3.org/ns/activitystreams",
    "type": "Offer",
    "id": "urn:uuid:9f261ea3-3f66-49ce-bd5e-417dec83f2a0",
    "name": "https://vultron.example/users/finndervul Offer FDR-8675309",
    "published": "2026-10-23T20:17:38+00:00",
    "updated": "2026-10-23T20:17:38+00:00",
    "to": [
      "https://vultron.example/organizations/vendorco"
    ],
    "actor": "https://vultron.example/users/finndervul",
    "object": {
      "id": "https://demo.vultron.local/VulnerabilityReport/e28f4965-7838-4644-b4a8-10604c7ee92f",
      "type": "VulnerabilityReport",
      "name": "FDR-8675309",
      "published": "2026-10-23T20:17:06+00:00",
      "updated": "2026-10-23T20:17:06+00:00",
      "content": "I found a vulnerability!",
      "attributedTo": "https://vultron.example/users/finndervul",
      "@context": "https://certcc.github.io/Vultron/ns/context.jsonld"
    }
  }
}

• Triggering transition: Received or Invalid → Valid ({R,I} → V).
• Second wire form: a participant that joined through an Invite sends Accept(Invite(Actor, target=VulnerabilityCase)) instead, answering the full-case Invite (VAM-04-012); see Accept Full-Case Invite. It never validates the original report Offer (CM-11-020).

Invalidate report

Designates the report as invalid, moving the sender's RM state to Invalid.

• When… a report receiver judges the report invalid
• Send: TentativeReject(Offer(VulnerabilityReport))
• Send to: the case manager
• Sent by: a participant (usually: vendor, coordinator)
• Seen in: How to Report a Vulnerability
• Formal definition: Report Invalid (RI)
• Mapping status: expansion

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "TentativeReject",
  "id": "urn:uuid:09e01b1b-0cc4-4c6f-b834-da0fe1440ede",
  "name": "https://vultron.example/organizations/vendorco TentativeReject https://vultron.example/users/finndervul Offer FDR-8675309",
  "content": "We're declining this report as invalid. If you have a reason we should reconsider, please let us know. Otherwise we'll be closing it shortly.",
  "actor": "https://vultron.example/organizations/vendorco",
  "object": {
    "@context": "https://www.w3.org/ns/activitystreams",
    "type": "Offer",
    "id": "urn:uuid:e45f0acd-a9fe-4796-927a-85639e92c8d1",
    "name": "https://vultron.example/users/finndervul Offer FDR-8675309",
    "published": "2026-10-23T20:17:38+00:00",
    "updated": "2026-10-23T20:17:38+00:00",
    "to": [
      "https://vultron.example/organizations/vendorco"
    ],
    "actor": "https://vultron.example/users/finndervul",
    "object": {
      "id": "https://demo.vultron.local/VulnerabilityReport/e28f4965-7838-4644-b4a8-10604c7ee92f",
      "type": "VulnerabilityReport",
      "name": "FDR-8675309",
      "published": "2026-10-23T20:17:06+00:00",
      "updated": "2026-10-23T20:17:06+00:00",
      "content": "I found a vulnerability!",
      "attributedTo": "https://vultron.example/users/finndervul",
      "@context": "https://certcc.github.io/Vultron/ns/context.jsonld"
    }
  }
}

• Triggering transition: Received → Invalid (R → I).
• Second wire form: a participant that joined through an Invite sends TentativeReject(Invite(Actor, target=VulnerabilityCase)) instead, answering the full-case Invite (VAM-04-013); see Tentatively reject Full-Case Invite.

Close report

Closes the report, moving the sender's RM state to Closed. Once a case holds the report, its Case Owner closes the case with Leave(VulnerabilityCase) instead, and every receiver refuses a Close(Report) for it.

• When… a report receiver closes a report no case holds
• Send: Reject(Offer(VulnerabilityReport))
• Send to: an actor outside any case
• Sent by: the addressee of the vulnerability report offer (usually: vendor, coordinator)
• Seen in: How to Advance a Case Through Report Management, How to Report a Vulnerability
• Formal definition: Report Closed (RC)
• Mapping status: expansion

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Reject",
  "id": "urn:uuid:44a69106-18bd-45e5-97f7-9b4d7e605b69",
  "name": "https://vultron.example/organizations/vendorco Reject https://vultron.example/users/finndervul Offer FDR-8675309",
  "content": "We're closing this report.",
  "actor": "https://vultron.example/organizations/vendorco",
  "object": {
    "@context": "https://www.w3.org/ns/activitystreams",
    "type": "Offer",
    "id": "urn:uuid:3e2c0367-6399-4bd4-a281-8e0929799f51",
    "name": "https://vultron.example/users/finndervul Offer FDR-8675309",
    "published": "2026-10-23T20:17:38+00:00",
    "updated": "2026-10-23T20:17:38+00:00",
    "to": [
      "https://vultron.example/organizations/vendorco"
    ],
    "actor": "https://vultron.example/users/finndervul",
    "object": {
      "id": "https://demo.vultron.local/VulnerabilityReport/e28f4965-7838-4644-b4a8-10604c7ee92f",
      "type": "VulnerabilityReport",
      "name": "FDR-8675309",
      "published": "2026-10-23T20:17:06+00:00",
      "updated": "2026-10-23T20:17:06+00:00",
      "content": "I found a vulnerability!",
      "attributedTo": "https://vultron.example/users/finndervul",
      "@context": "https://certcc.github.io/Vultron/ns/context.jsonld"
    }
  }
}

• Triggering transition: Received, Invalid, Deferred, or Accepted → Closed ({R,I,D,A} → C).
• Second wire form: a participant that joined through an Invite closes with Reject(Invite(Actor, target=VulnerabilityCase)) (VAM-04-014); see Reject Full-Case Invite.
• Stub Invite decline: an invitee that declines its stub Invite sends Reject(Invite(Actor, target=VulnerabilityCaseStub)), which is not an RC message. On receipt, the CASE_MANAGER moves the invitee's RM state to Closed (CM-11-007); see Reject invite to case.
• Fault axis: the Reject(Offer(VulnerabilityReport)) activity also appears as an ordinary refusal in the fault-and-acknowledgment mapping (MSM-05-003); see Faults and Acknowledgments.

Report/Case Accepted (RA)

Joins the case, moving the sender's RM state to Accepted. Engaging is a case-participation decision, so the verb names the case rather than the report.

• When… a Participant accepts the case for further action
• Send: Join(VulnerabilityCase)
• Send to: the case manager
• Sent by: a participant
• Seen in: How to Advance a Case Through Report Management
• Formal definition: Report/Case Accepted (RA)
• Mapping status: direct

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Join",
  "id": "urn:uuid:3b44e9e1-2723-46e4-9ba2-0fcba8301140",
  "name": "https://vultron.example/organizations/vendorco Join VendorCo Case #70930046",
  "content": "We're engaging this case.",
  "actor": "https://vultron.example/organizations/vendorco",
  "object": {
    "id": "urn:uuid:d483d06d-400e-47fd-9b8a-9a2643e3a4b0",
    "type": "VulnerabilityCase",
    "name": "VendorCo Case #70930046",
    "published": "2026-10-23T20:17:06+00:00",
    "updated": "2026-10-23T20:17:06+00:00",
    "attributedTo": "https://vultron.example/organizations/vendorco",
    "caseParticipants": [],
    "actorParticipantIndex": {},
    "vulnerabilityReports": [],
    "caseStatuses": [
      {
        "id": "urn:uuid:b1433c7d-659a-48f4-bd42-4fe704585f61",
        "type": "CaseStatus",
        "name": "NONE pxa",
        "context": "urn:uuid:d483d06d-400e-47fd-9b8a-9a2643e3a4b0",
        "published": "2026-10-23T20:17:06+00:00",
        "updated": "2026-10-23T20:17:06+00:00",
        "attributedTo": "https://vultron.example/organizations/vendorco",
        "emState": "NONE",
        "pxaState": "pxa",
        "@context": "https://certcc.github.io/Vultron/ns/context.jsonld"
      }
    ],
    "notes": [],
    "embargoRegister": [],
    "pendingEmbargoProposalIndex": {},
    "caseActivity": [],
    "genesisHash": "3f3a0359462714e6979b2d77ae6e953e1381472e9bef61933073af26469fad37",
    "ledgerPosition": {
      "logIndex": -1,
      "entryHash": "3f3a0359462714e6979b2d77ae6e953e1381472e9bef61933073af26469fad37"
    },
    "parentCases": [],
    "childCases": [],
    "siblingCases": [],
    "activeParticipants": [],
    "@context": "https://certcc.github.io/Vultron/ns/context.jsonld"
  }
}

• Triggering transition: Valid or Deferred → Accepted ({V,D} → A).
• Re-engagement: re-engaging a deferred case emits the same activity. There is no separate re-engagement wire form, because DEFERRED → ACCEPTED is a forward transition rather than a retraction of the earlier deferral.

Report/Case Deferred (RD)

Ignores the case, moving the sender's RM state to Deferred. Deferring is a case-participation decision, so the verb names the case rather than the report.

• When… a Participant defers further action on the case
• Send: Ignore(VulnerabilityCase)
• Send to: the case manager
• Sent by: a participant
• Seen in: How to Advance a Case Through Report Management
• Formal definition: Report/Case Deferred (RD)
• Mapping status: direct

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Ignore",
  "id": "urn:uuid:3e2673ed-4db3-491d-b5e6-933a83d0c5c6",
  "name": "https://vultron.example/organizations/vendorco Ignore VendorCo Case #70930046",
  "content": "We're deferring this case.",
  "actor": "https://vultron.example/organizations/vendorco",
  "object": {
    "id": "urn:uuid:d483d06d-400e-47fd-9b8a-9a2643e3a4b0",
    "type": "VulnerabilityCase",
    "name": "VendorCo Case #70930046",
    "published": "2026-10-23T20:17:06+00:00",
    "updated": "2026-10-23T20:17:06+00:00",
    "attributedTo": "https://vultron.example/organizations/vendorco",
    "caseParticipants": [],
    "actorParticipantIndex": {},
    "vulnerabilityReports": [],
    "caseStatuses": [
      {
        "id": "urn:uuid:b1433c7d-659a-48f4-bd42-4fe704585f61",
        "type": "CaseStatus",
        "name": "NONE pxa",
        "context": "urn:uuid:d483d06d-400e-47fd-9b8a-9a2643e3a4b0",
        "published": "2026-10-23T20:17:06+00:00",
        "updated": "2026-10-23T20:17:06+00:00",
        "attributedTo": "https://vultron.example/organizations/vendorco",
        "emState": "NONE",
        "pxaState": "pxa",
        "@context": "https://certcc.github.io/Vultron/ns/context.jsonld"
      }
    ],
    "notes": [],
    "embargoRegister": [],
    "pendingEmbargoProposalIndex": {},
    "caseActivity": [],
    "genesisHash": "3f3a0359462714e6979b2d77ae6e953e1381472e9bef61933073af26469fad37",
    "ledgerPosition": {
      "logIndex": -1,
      "entryHash": "3f3a0359462714e6979b2d77ae6e953e1381472e9bef61933073af26469fad37"
    },
    "parentCases": [],
    "childCases": [],
    "siblingCases": [],
    "activeParticipants": [],
    "@context": "https://certcc.github.io/Vultron/ns/context.jsonld"
  }
}

• Triggering transition: Valid or Accepted → Deferred ({V,A} → D).
• Why a case verb: deferring is a case-participation decision, not a report-validity judgment (MSM-01-004).

Formal messages with no dedicated wire activity

RE — Report Error

• Protocol role: Indicates a Participant received an unexpected RM message.
• Triggering transition: any unexpected RM message.
• Wire activity: none dedicated. Faults are conveyed by Create(ProcessingFault) (not understood), as:Reject (understood but declined), or Add(Note) (needing explanation), partitioned by failure mode rather than by state machine (ADR-0083).
• Formal definition: Message Types.