Skip to content
Reference

RCCV-extension Scenario: Reporter + C1 + C2 + Vendor

Overview

The RCCV-extension scenario exercises a two-coordinator case where the second coordinator (C2) acts as a broker for the Vendor via the actor-suggestion flow. The Reporter reports to C1 (the initial coordinator and case owner). C1 invites C2; C2 then suggests the Vendor to the case. C1 approves the suggestion and the Case Actor formally invites the Vendor.

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).
  • C1 (Coordinator 1) — receives the report; validates, engages, and owns the case; invites C2.
  • C2 (Coordinator 2) — joins via C1's invitation; suggests the Vendor.
  • Vendor — joins via the actor-suggestion path; develops and ships a 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-actor container, but its authority comes from the role, not from where it runs.

Protocol narrative

1. Reporter submits a vulnerability report to C1

The Reporter reports to C1's endpoint. No ledger entry is created yet.

Antecedent: Reporter has knowledge of the vulnerability.

2. C1 validates and engages the case

C1 reviews the report and accepts it. validate_report and engage_case entries appear in the ledger.

Antecedent: Report received from Reporter.

3. Participant status records are created

The Case Actor records the engagement's status as an add_participant_status_to_participant entry; each record seated at case creation was ledgered as a create_case_participant entry.

Antecedent: engage_case is in the ledger.

4. C1 invites C2

C1 sends C2 an invite_actor_to_case entry.

Antecedent: engage_case is in the ledger.

5. C2 accepts the invitation

C2 joins the case. An accept_invite_actor_to_case entry is recorded.

Antecedent: invite_actor_to_case is in the ledger (step 4).

6. C2 suggests the Vendor

C2 identifies the Vendor as an affected party and submits an offer_case_participant entry proposing the Vendor for membership (ADR-0026).

Antecedent: C2's accept_invite_actor_to_case entry is in the ledger.

7. C1 approves the recommendation

C1, as case owner, reviews and approves the suggestion. An accept_actor_recommendation entry is recorded.

Antecedent: offer_case_participant is in the ledger.

8. Case Actor invites the Vendor

The Case Actor sends the Vendor an invite_actor_to_case entry.

Antecedent: accept_actor_recommendation is in the ledger.

9. Vendor accepts the invitation

The Vendor joins the case. An accept_invite_actor_to_case entry is recorded.

Antecedent: The Case Actor's invite_actor_to_case entry is in the ledger.

10. Participants exchange notes

All participants 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.

11. Vendor reaches fix-ready

The Vendor advances to VFd (fix-ready) status.

Antecedent: engage_case is in the ledger.

12. Participants publish; embargo terminates

All participants publish. The embargo exits ACTIVE.

Antecedent: Vendor has reached fix-ready.

13. All participants close the case

close_case entries appear for each participant. The Vendor, C2, and the Reporter leave first; C1, 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 C1 Report submission precedes the case.