Skip to content
Reference

RCVCV Scenario: Reporter + C1 + V1 + C2 + V2

Overview

The RCVCV scenario exercises the actor-suggestion flow (ADR-0026). A Reporter reports to Coordinator 1 (C1), who creates the case and directly invites Vendor 1 (V1) and Coordinator 2 (C2). After C2 joins, C2 suggests Vendor 2 (V2) to the case; C1, as the case owner, approves the recommendation and the Case Actor sends V2 a formal invitation.

This five-actor scenario validates the indirect participant onboarding path where C2 acts as a broker for V2 rather than C1 inviting V2 directly.

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 V1 and C2.
  • V1 (Vendor 1) — receives a direct invite from C1; develops a fix (reaches VFd, not VFD).
  • C2 (Coordinator 2) — receives a direct invite from C1; suggests V2 to the case.
  • V2 (Vendor 2 / Deployer) — joins via the actor-suggestion path; develops and deploys a fix (VFD).
  • 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. This is an out-of-band API call; no ledger entry is created.

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 V1 and C2

C1 sends invite_actor_to_case entries to both V1 and C2.

Antecedent: engage_case is in the ledger.

5. V1 and C2 accept their invitations

Each invitee accepts. Two accept_invite_actor_to_case entries appear.

Antecedent: Their respective invite_actor_to_case entries are in the ledger.

6. C2 suggests V2 via the actor-suggestion flow

C2 is aware that V2 is also affected. C2 submits an offer_case_participant entry proposing V2 for case membership (ADR-0026).

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

7. C1 approves C2's recommendation

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

Antecedent: offer_case_participant is in the ledger.

8. Case Actor sends V2 a formal invitation

The Case Actor, acting on C1's approval, sends V2 an invite_actor_to_case entry. This follows the ADR-0026 suggest-actor path.

Antecedent: accept_actor_recommendation is in the ledger.

9. V2 accepts the Case Actor invitation

V2 reviews and accepts the invitation. An accept_invite_actor_to_case entry is recorded for V2.

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. V1 reaches fix-ready; V2 reaches fix-deployed

V1 advances to VFd (fix-ready) but stops there. V2 advances all the way to VFD (fix-deployed). Participant status updates reflect each state change.

Antecedent: engage_case is in the ledger.

12. Participants publish; embargo terminates

All participants publish. The embargo exits ACTIVE.

Antecedent: At least one vendor has reached fix-ready.

13. All participants close the case

All five participants close the case. close_case entries appear for each. V1, V2, 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.