RCV Scenario: Reporter + Coordinator + Vendor
Overview
The RCV scenario introduces a Coordinator who receives the initial report from the Reporter and manages participant onboarding. The Coordinator validates and engages the case, then invites the Vendor. The Reporter is a participant from the moment the case is created, so it receives no invitation. The Vendor carries out the fix; the Coordinator and Reporter manage communication.
Participants:
- Reporter — discovers the vulnerability and submits the report; in the case it holds the Reporter role; the protocol has no separate Finder role (ADR-0078).
- Coordinator — receives the report; validates, engages, and owns the case; invites the Vendor.
- Vendor — receives an invitation; develops and ships the fix.
- Case Actor — the actor that holds the CASE_MANAGER role for this case; it writes every canonical ledger entry and fans it out to the participants. In the demo it runs on the dedicated
case-actorcontainer, but its authority comes from the role, not from where it runs.
Protocol narrative
1. Reporter submits a vulnerability report to Coordinator
The Reporter reports a vulnerability to the Coordinator's reporting endpoint. This is an out-of-band API call; no case-ledger entry is created yet.
Antecedent: Reporter has knowledge of the vulnerability.
2. Coordinator validates and engages the case
The Coordinator reviews the report and confirms it is actionable. A
validate_report entry is recorded, followed by engage_case after the
Coordinator accepts responsibility.
Antecedent: Report received from Reporter.
3. Participant status records are created
Each record seated at case creation is ledgered as a create_case_participant entry, and each later status the Case Actor writes, the Vendor's engagement included, as an add_participant_status_to_participant entry.
The Reporter is one of them: it joins the case as a signatory when the case is created, so the Coordinator never invites it.
Antecedent: engage_case is in the ledger.
4. Coordinator invites the Vendor
The Coordinator identifies the Vendor responsible for the affected product and asks the Case Actor to invite it.
The Case Actor sends the Invite and records it as an invite_actor_to_case entry, the only one in this scenario.
Antecedent: engage_case is in the ledger.
5. Vendor accepts the invitation
The Vendor reviews the invitation and joins the case.
An accept_invite_actor_to_case entry is recorded.
Antecedent: The Vendor's invite_actor_to_case entry is in the ledger.
6. Participants exchange notes
The Reporter, Coordinator, and Vendor communicate through case notes.
Each note is sent as one Add(Note) carrying the note inline, and recorded as an add_note_to_case entry, which attaches it to the case.
Antecedent: engage_case is in the ledger.
7. Vendor develops and ships a fix
The Vendor progresses through the fix lifecycle. Participant status updates reflect the Vendor reaching the fix-ready (VFd) state. No participant deploys a fix in this scenario, so the VFD state stays at VFd.
Antecedent: engage_case is in the ledger.
8. Participants publish and embargo terminates
All participants publish. The embargo exits ACTIVE. The CS PXA state advances.
Antecedent: Vendor has reached fix-ready.
9. All participants close the case
Reporter, Coordinator, and Vendor each close the case with close_case entries.
The Vendor and the Reporter leave first; the Coordinator, the Case Owner, leaves last.
A departure sent after the owner's is not recorded, so every other participant's departure is recorded first.
Antecedent: validate_report and engage_case are in the ledger.
Unobservable edges
| Unobservable step | Why not in ledger |
|---|---|
| Reporter submits report to Coordinator | Report submission precedes the case's creation; no ledger entry exists yet. |