Reference

Vultron Protocol

This page is normative

This page is considered a core part of the Vultron Protocol. This is a normative section of the documentation.

The whole specification on one page

The specification is also published as a single page that holds every section and annex in order, for printing or for searching the whole text at once.

This page holds section 14.1 of the Vultron Protocol Specification, part of its Requirements Catalog. Each row is one requirement, and the rest of the documentation links a requirement to its row here.

14.1 Vultron Protocol

The requirements of the core Vultron protocol: the Report Management (RM), Embargo Management (EM) and Case State (CS) models, the messages that move them, and the rules that couple them.

Vultron Protocol

Requirements extracted from the Vultron Protocol documentation, covering participant state tracking, Report Management (RM), Embargo Management (EM), CVD Case State (CS) messaging, model interactions, and implementation guidance. This is the normative source for protocol behavior requirements that implementations must satisfy.

Participant State Tracking

ID	Priority	Requirement	Related
VP-01-001	SHOULD	Participants SHOULD track the state of other Participants in a case to inform their own decision making A participant's next move depends on where the others stand: whether a vendor has a fix, whether anyone has published, whether a coordinator has left. Without tracking their states a participant acts on a stale picture and may, for example, publish before a vendor is ready.
VP-01-002	SHOULD	Participants SHOULD track the RM states of the other Participants in the case RM state says whether each participant is still engaged with the report. Knowing it tells a participant who will still act on the case, whose replies to expect, and when a vendor has stopped work.
VP-01-003	MUST NOT	Correct operation of the protocol MUST NOT depend on perfect information across all Participants Participants in a distributed CVD case never all see the same state at the same moment: messages are delayed, lost, or withheld by embargo scope. A protocol that needed perfect shared information would stall or misbehave in every real case, so each step must be safe on the partial view a participant actually holds.

Report Management (RM): Receiving Reports

ID	Priority	Requirement	Related
VP-02-001	MUST	Coordinators MUST have a formally documented, publicly available mechanism for receiving reports A reporter can coordinate only with a coordinator it can reach. Taking reports from anyone is the coordinator's role, so an undocumented or private intake path leaves reporters no way in and pushes them toward uncoordinated public disclosure.
VP-02-002	MUST	Participants MUST assign Valid cases a higher processing priority than Received (untriaged) cases and Closed cases in their case-management workflow. Valid reports are the ones known to need work, so effort spent on them is what reduces harm. Received reports are not yet judged and Closed reports need nothing more; letting either crowd out Valid work delays fixes for confirmed vuls.
VP-02-003	MUST	Participants initiating CVD with others MUST do so from the Accepted state Accepted is the RM state in which a participant has committed to work on the report. Drawing others into a case from an earlier state would commit them to coordination the initiator has not itself agreed to pursue.
VP-02-004	MUST NOT	Participants MUST NOT close cases or reports from the Valid state Valid means the report is real and in scope but no engage-or-defer decision has been made. Closing straight from Valid would let a confirmed vul be dropped without that prioritization decision ever being taken or announced, so the report must pass through Accepted or Deferred first.
VP-02-005	SHOULD	Vendors SHOULD have a clearly defined and publicly available mechanism for receiving reports Reporters can disclose privately to a vendor only if they can reach it. Without a known intake channel, reports are lost, sent to the wrong place, or published without coordination.
VP-02-006	SHOULD	Participants SHOULD subject each Received report to a validation process resulting in a valid or invalid designation Not every report describes a real vul in the recipient's scope. Validation separates real reports from noise, so that case creation, embargo commitments and coordination effort go only where they are warranted.
VP-02-007	SHOULD	Participants SHOULD have a clearly defined process for validating reports in the Received state A defined validation process makes valid and invalid decisions consistent and explainable to reporters. It also lets other participants trust what a Valid or Invalid announcement means.
VP-02-008	SHOULD	Participants SHOULD have a clearly defined process for transitioning reports from the Received state to the Valid or Invalid states Other participants read RM transitions as signals. If the move out of Received follows no defined process, those signals carry no reliable meaning and reports can sit in Received indefinitely.
VP-02-009	SHOULD	Participants SHOULD proceed only after validating the reports they receive Acting on an unvalidated report spends embargo commitments, coordination effort and other participants' attention on something that may not be a vul at all.
VP-02-010	SHOULD	Participants SHOULD transition all valid reports to the Valid state and all invalid reports to the Invalid state The RM state is how a participant tells others what it concluded about a report. A report left in Received, or put in the wrong state, misinforms every participant that tracks it (VP-01-002).
VP-02-011	SHOULD	Once a Vendor confirms that a reported vulnerability affects one or more of their products or services, the Vendor SHOULD designate the report as Valid The vendor's confirmation that its product is affected answers the question validation asks. Designating the report Valid then moves it on to prioritization and tells other participants the vendor has a real vul to fix.
VP-02-012	SHOULD	Participants SHOULD temporarily hold reports that they cannot validate pending additional information Many reports cannot be judged on first read because details are missing. Holding them, rather than marking them Invalid, keeps a real vul from being discarded only because the reporter has not yet supplied enough information.
VP-02-013	SHOULD	Participants SHOULD provide Reporters an opportunity to update their report with additional information before closing it Reporters can often supply the missing detail if asked. Closing without giving them that chance throws away real vuls and discourages reporters from using the coordinated channel next time.
VP-02-014	SHOULD	For Valid reports, the Participant SHOULD perform a prioritization evaluation to decide whether to accept or defer the report A valid report still competes with all other work for limited capacity. An explicit prioritization decision turns "this is real" into "we will work on it now" or "later", and gives the participant a decision to announce (VP-02-024).
VP-02-015	SHOULD	Participants SHOULD create a case from reports entering the Valid state to track the report's progress through the CVD process A case is the object that carries participants, embargo and CS state through the rest of the CVD process. Without one, work on a valid report has nothing to record progress against or to coordinate around.
VP-02-016	SHOULD	Participants SHOULD have a bias toward accepting rather than deferring Valid cases up to their work capacity limits Deferring a valid report leaves a known vul unaddressed and its reporter waiting. Accepting when capacity allows keeps real vuls moving toward a fix.
VP-02-017	SHOULD	Reports SHOULD exit the Deferred state when work is resumed (to Accepted) or when the Participant has determined no further action will be taken (to Closed) Deferred is meant as a pause, not a resting place. Leaving reports there indefinitely hides whether work will ever resume, so the participant moves them on once that is known.
VP-02-018	SHOULD	Reports SHOULD be moved to the Closed state once a Participant has completed all outstanding work tasks and has determined that no further action will be taken on the report Closed tells other participants that this participant will do no more on the report. Closing before outstanding work is done, or keeping finished reports open, misinforms the participants who track RM state.
VP-02-019	SHOULD	CVD Participants SHOULD announce their RM state transitions to the other Participants in a case Other participants plan their own work around who is engaged with a case (VP-01-002). Announcing RM transitions is how they learn of them; an unannounced close or defer leaves them expecting work that will not happen.
VP-02-020	SHOULD	Participants SHOULD create a case for all Valid reports Every valid report needs a place to track its participants, embargo and progress. A valid report without a case can fall out of view and gives other participants nothing to join.
VP-02-021	SHOULD	Participants SHOULD act in accordance with their own policy and process when deciding when to transition RM states Organizations differ in capacity, risk tolerance and published disclosure policy, and the protocol cannot know those. Leaving transition decisions to each participant's own policy keeps the protocol usable across them, while other requirements still make the decisions visible.
VP-02-022	SHOULD NOT	Participants SHOULD NOT mark duplicate reports as invalid A duplicate still describes a real vul. Marking it Invalid would tell its reporter, and every participant tracking the state, that the report was wrong, and would discard any new detail it carries.
VP-02-023	SHOULD	A Participant SHOULD move a duplicate report through the RM Valid state. Passing through Valid records that the duplicate describes a real vul, so the duplicate's reporter learns that the report was sound.
VP-02-036	MAY	After a duplicate report reaches RM Valid, a Participant MAY defer it in favor of the original report. Deferring a duplicate in favor of the first report of the same vul avoids working the vul twice, while the duplicate's reporter stays informed.
VP-02-024	SHOULD	Vendors SHOULD communicate their prioritization choices when making either a defer or accept transition out of the Valid, Deferred, or Accepted states Reporters and other participants plan around whether a vendor will act now or later. Stating the prioritization choice lets them adjust, for example by seeking a coordinator or different embargo terms, instead of guessing from silence.
VP-02-025	MAY	Participants MAY perform a more technical report validation process before exiting the Received state Some reports cannot be judged credible without reproducing or examining them. Allowing deeper technical checks before leaving Received keeps the Valid designation meaningful.
VP-02-026	MAY	Participants MAY create a case object to track any report in the Received state Some participants need a record of a report and its correspondence from the moment it arrives, for example to show response times. A case at Received gives them that record without forcing it on everyone.
VP-02-027	MAY	Participants MAY set a timer to move reports from Invalid to Closed after a set period of inactivity Invalid reports that receive no new information need no further work. A timer moves them to Closed so they do not pile up as open items, while still leaving the reporter a window to respond.
VP-02-028	MAY	Participants MAY choose to perform a shallow technical analysis on Valid reports to prioritize further effort Prioritization is better informed when the participant knows roughly how severe or widespread the vul is. A shallow analysis gives that without committing to full work.
VP-02-029	MAY	A report MAY enter and exit the Accepted state a number of times as a Participant resumes or pauses work Work on a report is often paused and resumed as priorities change. Allowing repeated entry into Accepted lets the RM state follow the real work instead of forcing a single pass.
VP-02-030	MAY	A report MAY enter and exit the Deferred state a number of times as a Participant pauses or resumes work Work on a report is often paused and resumed as priorities change. Allowing repeated entry into Deferred lets the RM state follow the real work instead of forcing a single pass.
VP-02-031	MAY	CVD Participants MAY set a policy timer on reports in the Deferred state to ensure they are moved to Closed after a set period of inactivity Deferred reports are easily forgotten. A policy timer moves them to Closed after inactivity, so open work lists reflect reality and other participants learn this participant has stopped work.
VP-02-032	MAY	Participants MAY create a case for Invalid reports A case for an invalid report keeps the decision and correspondence on record. That record helps if the report is later revalidated (VP-02-033) or a duplicate arrives.
VP-02-033	MAY	Participants MAY periodically revalidate Invalid reports to determine if they have become Valid A report judged Invalid may become valid as new information, product versions or exploitation evidence appears. Periodic revalidation stops an early wrong call from becoming permanent.
VP-02-034	MAY	Participants MAY re-prioritize Accepted or Deferred cases Priorities change as information arrives, such as exploitation evidence or newly affected products. Re-prioritizing lets a participant's work, and the RM state it announces, follow that change.
VP-02-035	MAY	Participants MAY close Accepted or Deferred cases or Invalid reports Accepted or deferred work ends, whether fixed, out of scope or abandoned, and invalid reports may need nothing more. Closing marks that end so other participants know no further action is coming from this participant.

RM Messaging

ID	Priority	Requirement	Related
VP-03-001	MUST	Participants MUST be in RM Accepted to send a Report Submission (\(RS\)) message to someone else An \(RS\) hands a report to someone else and draws them into coordination. Requiring Accepted means only a participant that has committed to work on the report can pass it on, so reports are not forwarded by someone who has not judged them worth pursuing.
VP-03-002	MUST	Vendor Recipients receiving a new Report Submission MUST transition their CVD Case State to Vendor Aware (\(q^{cs} \xrightarrow{\mathbf{V}} Vfd\cdots\)) Vendor awareness is the first CS event and starts the vendor's response timeline. If receiving a report did not set it, the case would understate what the vendor knows, and every later CS-based decision, including embargo eligibility and fix tracking, would start from a wrong state.
VP-03-003	SHOULD	Participants SHOULD send \(RI\) when the report validation process ends in an invalid determination The reporter and other participants need to know a report was judged invalid, so they can supply more detail or pursue other channels. Without \(RI\) they cannot tell an invalid finding from no response at all.
VP-03-004	SHOULD	Participants SHOULD send \(RV\) when the report validation process ends in a valid determination \(RV\) tells the reporter and other participants that the report is real and in scope. That is what lets them plan the next steps, such as embargo terms and fix timing.
VP-03-005	SHOULD	Participants SHOULD send \(RD\) when the report prioritization process ends in a deferred decision \(RD\) tells others that this participant will not work the report now. They can then adjust embargo expectations or seek another route instead of waiting.
VP-03-006	SHOULD	Participants SHOULD send \(RA\) when the report prioritization process ends in an accept decision \(RA\) tells others that this participant has committed to work on the report, which is what they need to plan fix and publication timing.
VP-03-007	SHOULD	Participants SHOULD send \(RC\) when the report is closed \(RC\) tells others this participant has stopped work. They stop expecting fixes or replies from it and can judge whether its exit affects the embargo.
VP-03-008	SHOULD	Participants SHOULD send \(RE\) regardless of state when any error is encountered A protocol message that cannot be processed otherwise fails silently. Sending \(RE\) in any state tells the sender something went wrong, so it can correct or ask instead of assuming the message took effect.
VP-03-009	SHOULD	Recipients SHOULD acknowledge the \(R*\) messages they receive, other than \(RK\) itself. \(RK\) acknowledges only \(RS\): an addressee of the report's Offer sends it to the reporter (RMB-08-003). No other \(R*\) message is acknowledged with \(RK\); once a case exists, its acknowledgment is the CASE_MANAGER's ledger entry for it, fanned out to the participants. Before a case exists there is no ledger, so the reporter learns that its report arrived only from an \(RK\) (RMB-08-003). Once a case exists, every \(R*\) message goes to the CASE_MANAGER (PCR-08-001), and the ledger entry it commits already tells every participant the message was received; a separate \(RK\) would only add traffic and a second acknowledgment that could disagree with the ledger.
VP-03-010	SHOULD	Recipients who receive an \(R*\) message (other than \(RS\)) while in RM Start (\(q^{rm} \in S\)) SHOULD answer it with Create(ProcessingFault) (ASK-07-001). The fault tells the sender that the recipient holds no report the message could be about. \(RE\) has no wire activity of its own (MSM-05-001). An \(R*\) message from a party the recipient has no report from means the two disagree about whether a report was sent. A fault lets the sender re-send the report. No \(RE\) message exists, because faults are grouped by failure mode (MSM-05-001). The rule is a SHOULD, not the MUST of ASK-07-001, because a recipient that understands the message can decline it with as:Reject instead (MSM-05-001). It never permits silence: a recipient that cannot process the message falls under ASK-07-001.
VP-03-011	SHOULD	Recipients of an \(RE\) message SHOULD inquire (\(GI\)) as to the nature of the error. They do not acknowledge it with \(RK\) (VP-03-009); once a case exists, its acknowledgment is the CASE_MANAGER's ledger entry for it, fanned out to the participants. An \(RE\) says something went wrong but not what, so asking (\(GI\)) is how the two sides find and fix the problem. No \(RK\) is needed: \(RK\) acknowledges only \(RS\) (VP-03-009), and once a case exists the CASE_MANAGER's ledger entry already acknowledges the case event.
VP-03-012	SHOULD	Participants whose state changes in the RM, EM, or CVD Case State Models SHOULD send a message to other Participants for each transition Each participant decides from its picture of the others' states (VP-01-001). Announcing every RM, EM and CS transition keeps those pictures current; an unannounced transition, such as a fix becoming ready, leaves others acting on stale information.
VP-03-013	MAY	A recipient MAY ignore any message it receives on a Closed case, whatever its class: RM (\(R*\)), EM, CS or general-inquiry (\(GI\)). A closed case has no further work, so a recipient gains nothing by processing late traffic of any class. For the CASE_MANAGER, owner close is a hard kill switch, not a permission: after its own RM.CLOSED entry is committed it records no later inbound message for the case (CM-23-013). No principled line separates note-like traffic (\(GI\)) from state-changing traffic, so the boundary covers every message (ADR-0085).

Embargo Management (EM) Process

ID	Priority	Requirement	Related
VP-04-001	MUST	Every embargo that a Participant accepts MUST specify an end time (endTime). An embargo with no end time never frees participants to publish, so it can keep a vul secret indefinitely and leave users exposed. A required end time also gives every participant the same date to plan releases around.	Refines: VP-05-001
VP-04-002	MUST	A CVD case SHALL NOT have more than one active embargo at a time Participants must know which terms bind them. Two active embargoes on one case would give conflicting end times, and nobody could say when publication is allowed.
VP-04-003	MAY	An embargo MAY be proposed An embargo is how participants agree to keep a vul private while fixes are prepared. Proposing one is how that agreement starts; without proposals participants could only disclose with no coordination window.
VP-04-004	MAY	Once proposed, an embargo MAY be accepted or rejected An embargo binds only those who agree to it. Letting a proposal be accepted or rejected makes that agreement explicit and lets a participant refuse terms it cannot meet.
VP-04-005	MAY	Once an embargo is accepted, a Participant MAY propose a revision of it. Circumstances change during a case: fixes slip, vendors join, exploitation appears. Revisions let participants change the terms without first ending the embargo and leaving a gap with no terms in force.
VP-04-006	MAY	A proposed revision of an accepted embargo MAY be accepted or rejected. A revision is a proposal like any other, so the case can take the new terms or keep the terms already in force.

Embargo Principles

ID	Priority	Requirement	Related
VP-05-001	MUST	An embargo SHALL specify an unambiguous date and time as its endpoint Participants in different time zones and organizations must all stop withholding at the same moment. A date without a time, or a vague endpoint, lets them read the deadline differently and publish at different times.
VP-05-002	SHOULD NOT	An embargo's end time SHOULD NOT fall more than one year (P1Y) after the date the embargo is accepted. Long embargoes keep users exposed to a vul that attackers may find independently. A one-year ceiling bounds that exposure.
VP-05-021	SHOULD	An embargo that lasts more than 90 days (P90D) SHOULD carry a documented justification that all Participants agree to. Requiring agreed justification beyond 90 days makes a long embargo a deliberate exception rather than a default, since a long embargo keeps users exposed.
VP-05-003	MUST	An embargo SHALL begin at the moment it is accepted Participants need to know from what moment they are bound. Starting the embargo at acceptance leaves no gap in which a participant has agreed but is not yet bound, and no future start that could be read as permission to disclose now.
VP-05-004	MUST	Adding Participants to an existing embargo SHALL NOT constitute release or publication so long as those Participants accept the terms of the embargo Cases often need new vendors or coordinators after an embargo is in place. If telling them counted as release, no one could be added without ending the embargo; requiring that they accept the terms keeps the information inside it.
VP-05-005	MUST	Embargo termination SHALL NOT be construed as an obligation to publish The end of an embargo only removes the duty to withhold. Reading it as a duty to publish would force participants who are not ready, or have nothing to say, to release information.
VP-05-006	SHOULD NOT	Embargo Participants SHOULD NOT knowingly release information about an embargoed case until all proposed embargoes have been explicitly rejected, no proposed embargo has been explicitly accepted in a timely manner, the expiration date/time of an accepted embargo has passed, or an accepted embargo has been terminated prior to expiration Releasing information while an embargo may still form or is still in force undermines the agreement other participants rely on, and can expose users before fixes exist. The listed conditions are the points at which no embargo binds the participant, so they are the only safe times to release knowingly.
VP-05-007	SHOULD	Embargo participation SHOULD be limited to the smallest possible set of individuals and organizations needed to adequately address the vulnerability report Every additional party is another chance of a leak. Keeping participation to those needed to fix or coordinate limits that risk.
VP-05-008	SHOULD	Embargo duration SHOULD be limited to the shortest duration possible to adequately address the vulnerability report While an embargo runs, users remain unaware of a vul that attackers may also find. Keeping it as short as the work allows limits that exposure.
VP-05-009	SHOULD	Embargoes SHOULD be of short duration, from a few days to a few months Long embargoes raise the chance of independent discovery and exploitation while users have no information. Days to months is long enough for most fix work and short enough to bound that risk.
VP-05-010	SHOULD	Participants stopping work on a case SHOULD notify remaining Participants of their intent to adhere to or disregard any existing embargo associated with the case Remaining participants need to know whether a departing participant will keep the information private. That tells them whether the embargo still holds or must be revisited.
VP-05-011	SHOULD	Participants SHOULD continue to comply with any active embargoes to which they have been a party, even if they stop work on the case Information received under an embargo stays sensitive after a participant stops work. If leaving freed it to disclose, any participant could end the embargo for everyone by stepping away.
VP-05-012	SHOULD	Participants who leave an Active embargo SHOULD be removed by the remaining Participants from further communication about the case A participant that has left an active embargo is not bound to keep new information private. Continuing to send it case updates would leak information outside the embargo.
VP-05-013	SHOULD	Participants SHOULD consider other Participants' history of cooperation when evaluating the terms of a proposed embargo A participant's record of keeping or breaking past embargoes is the best guide to whether it will keep this one. Considering it lets participants set terms, or decline, according to the actual risk.
VP-05-014	SHOULD NOT	Participants SHOULD NOT publish information about the vulnerability when there is an active embargo Publishing while an embargo is active breaks the agreement other participants rely on and can expose users before fixes are ready.
VP-05-015	MAY	Additional Participants MAY be added to an existing embargo upon accepting the terms of that embargo Affected vendors and needed coordinators are often found after an embargo starts. Letting newcomers join by accepting the terms brings them in without renegotiating or ending the embargo.
VP-05-016	MAY	Participants MAY propose a new embargo or revision to an existing embargo at any time within the constraints outlined in the Negotiating Embargoes guidance Needs change as a case develops. Allowing proposals at any time, within the negotiation guidance, lets participants adjust the embargo when they learn something new.
VP-05-017	MAY	Participants MAY reject proposed embargo terms for any reason An embargo binds only participants who agree. A participant must be free to refuse terms it cannot keep, rather than be held to terms it never accepted.
VP-05-018	MAY	Participants in an embargo MAY exit the embargo at any time Embargo participation is voluntary. A participant that cannot or will not keep an embargo does less harm by saying so and leaving than by staying in and breaking it.
VP-05-019	MAY	A Participant's refusal to accept embargo terms MAY result in that Participant being left out of the CVD case entirely Sharing a vul with someone who has not agreed to keep it private puts the embargo at risk for everyone. Leaving out a participant that refuses the terms protects the others.
VP-05-020	MAY	Participants MAY publish information about the vulnerability when there is no active embargo With no active embargo there is no agreement to withhold, and users benefit from learning about the vul. Participants need clear permission to publish then.

Embargo Negotiation

ID	Priority	Requirement	Related
VP-06-001	MUST NOT	CVD Participants MUST NOT propose or accept a new embargo negotiation when information about the vulnerability is already known to the public (\(q^{cs} \in \cdots P \cdots\)), an exploit is publicly available (\(q^{cs} \in \cdots X \cdot\)), or the vulnerability is being actively exploited (\(q^{cs} \in \cdots A\)) Once the vul is public, an exploit is public, or attacks are under way, secrecy protects no one: attackers already have what they need and defenders need the information. An embargo at that point only delays defenders.
VP-06-002	SHOULD NOT	CVD Participants SHOULD NOT propose or accept a new embargo when the fix for a vulnerability has already been deployed (\(q^{cs} \in VFDpxa\)) Once the fix is deployed there is nothing left to prepare in private. A new embargo would only delay telling users about a vul they are already protected against.
VP-06-003	SHOULD	A Receiver that cannot accept a Reporter's proposed embargo as proposed SHOULD propose terms it can accept (VP-06-011) rather than reject the proposal outright. Reporters hold the vul and can disclose it on their own. A counter-proposal keeps them in the coordinated process and keeps the negotiation open; an outright refusal risks the reporter publishing without coordination. The Receiver still need not accept terms it cannot keep (VP-06-010), and VP-07-004 already answers a proposal longer than its default with a counter-proposal of that default.	Refines: VP-06-011
VP-06-004	SHOULD	Participants SHOULD explicitly accept or reject embargo proposals within the period defined in their VDP or within 14 calendar days of receipt, whichever is shorter. An open proposal leaves everyone unsure whether information may be shared. A bounded reply time, never more than 14 days, makes the outcome known soon enough for participants to plan.
VP-06-004b	SHOULD NOT	Embargo agreement or rejection SHOULD NOT be tacit. Silence can be read as either yes or no, so a tacit answer leaves participants disagreeing about whether an embargo binds them. An explicit answer gives them all the same record.	Refines: VP-06-004
VP-06-005	SHOULD	Participants SHOULD make reasonable attempts to retry embargo negotiations when prior proposals have been rejected or otherwise failed to achieve acceptance A case without an embargo leaves users exposed and fixes unprepared at disclosure. Retrying after a failed proposal gives coordination another chance before participants fall back to no embargo.
VP-06-006	SHOULD	Participants SHOULD remain flexible in adjusting embargo terms as the case evolves Fix timelines, affected vendors and threat conditions change during a case. Terms that cannot adjust either expire before fixes are ready or keep holding after the need for them has passed.
VP-06-007	MUST	Submitting a report when an embargo proposal is pending (\(q^{em} \in P\)) SHALL be construed as the Sender's acceptance of the proposed terms Sending the report while a proposal is pending shows the sender is willing to share under those terms. Treating the submission as acceptance avoids a report being shared with no embargo in force.
VP-06-008	MAY	When \(q^{cs} \in VFdpxa\), CVD Participants MAY propose or accept a new embargo that prepares for timely publication or deployment (VP-06-008b). This is the one exception to VP-14-007. With a fix ready but not deployed, a short window can still help users by letting participants line up publication and deployment. Fix Ready otherwise ends embargo negotiation (VP-14-007), so this one purpose is named as the exception, allowed here though not required.	Supersedes: VP-14-007
VP-06-008b	SHOULD	Any embargo accepted when \(q^{cs} \in VFdpxa\) SHOULD be brief and used only to allow Participants to prepare for timely publication or deployment. At this point only release preparation remains. A long embargo would delay the deployment of a fix that already exists.	Refines: VP-06-008
VP-06-009	MAY	CVD Participants MAY propose or accept an embargo in all other case states (\(q^{cs} \in \cdots pxa\)) Before the fix is ready, and while nothing is public or exploited, an embargo is what gives vendors time to prepare fixes in private. This is the case the EM process exists for.
VP-06-010	MAY	Participants MAY accept or reject any proposed embargo as they see fit An embargo binds only those who agree. Each participant knows its own ability to keep the terms and must be free to accept or refuse.
VP-06-011	MAY	Receivers MAY propose embargo terms they find more favorable The receiver may need more or less time than the reporter suggested. A counter-proposal lets it say so while keeping the negotiation going, rather than rejecting outright.
VP-06-012	MAY	Participants MAY withdraw their own unaccepted Proposed embargo A proposer may learn that its proposal does not fit the case after all. Withdrawing it before acceptance stops others from accepting terms the proposer has stopped supporting.
VP-06-013	MAY	Participants MAY interpret another Participant's failure to respond to an embargo proposal in a timely manner as a rejection of that proposal A proposer cannot wait forever for an answer. Reading silence as rejection lets it move on (VP-06-014) instead of being stuck undecided while the vul stays unaddressed.
VP-06-014	MAY	In the absence of an explicit accept or reject response from a Receiver in a timely manner, the Sender MAY proceed consistent with an EM state of None (\(q^{em} \in N\)) Without an answer, no embargo binds the receiver, so the sender may act as if none exists. That stops an unresponsive party from blocking the sender indefinitely.
VP-06-015	MAY	In a case where the EM state is None and for which an embargo has been proposed and either explicitly or tacitly rejected, Participants MAY take any action they choose with the report, including immediate publication When negotiation has failed, there is no agreement to keep the information private. Participants then need to be free to act in users' interest, which may mean publishing.
VP-06-016	MAY	Participants MAY withhold a report from a Recipient until an initial embargo has been accepted A recipient given the report before agreeing to an embargo is free to disclose it. Waiting for acceptance protects the information.
VP-06-017	MAY	Participants MAY use short embargoes to cover their report validation process and subsequently revise the embargo terms pending the outcome of their validation or prioritization processes A recipient often cannot judge how much time it needs until it has validated the report. A short initial embargo protects the report meanwhile and can be revised once the needs are known.

Embargo Default Policies

ID	Priority	Requirement	Related
VP-07-001	MUST	If neither Sender nor Receiver proposes an embargo and no actor default applies, the protocol default embargo of EP-04-005 SHALL apply. A case with no embargo leaves the vul unprotected, and reaching that state only because nobody proposed terms is the least deliberate way to get there. A bounded protocol default gives every eligible case protection.	Refines: EP-04-005
VP-07-014	MUST	A case SHALL have no embargo only where it is not embargo-eligible, that is where any of P/X/A is set (EP-04-008). A case where the vul is already public, exploited or attacked gains nothing from secrecy, so only there does no embargo exist. Every other case has an embargo, if only the protocol default (VP-07-001).	Derives from: VP-07-001 Refines: EP-04-008
VP-07-002	MUST	A Receiver's default embargo specified in its vulnerability disclosure policy SHALL be treated as an initial embargo proposal A published default tells reporters what to expect. Treating it as a proposal makes it a real negotiating position without either side having to send a first message.
VP-07-003	MUST	If the Receiver has declared a default embargo in its vulnerability disclosure policy and the Sender proposes nothing to the contrary, the Receiver's default embargo SHALL be considered as an accepted proposal A sender that knows the receiver's published default and offers nothing else has agreed to it in effect. Treating it as accepted puts an embargo in force at once, rather than leaving the case unprotected while waiting for a formal reply.
VP-07-004	MUST	If the Sender proposes an embargo longer than the Receiver's default, the Receiver's default SHALL be taken as accepted and the Sender's proposal taken as a proposed revision The receiver's shorter default is acceptable to both sides: the receiver published it and the sender asked for at least that much time. Accepting it puts an embargo in force at once, and the longer request stays open as a revision.
VP-07-005	MUST	If the Sender proposes an embargo shorter than the Receiver's default, the Sender's proposal SHALL be taken as accepted and the Receiver's default taken as a proposed revision The sender's shorter proposal is acceptable to both sides: the sender asked for it and the receiver's default allows at least that much time. Accepting it puts an embargo in force at once, and the receiver's longer default stays open as a revision.
VP-07-006	SHOULD	Report Recipients SHOULD post a default embargo as part of their Vulnerability Disclosure Policy to set expectations with potential Reporters Reporters decide how and whether to report based on what they expect. A published default tells them how long they will be asked to wait, and gives VP-07-002 a default to apply.
VP-07-007	SHOULD	If the Sender proposes an embargo and the Receiver has no default embargo specified by policy, the Receiver SHOULD accept the Sender's proposal With no default of its own, the receiver has no stated reason to refuse. Accepting the sender's proposal puts an embargo in force at once and keeps the reporter in the coordinated process.
VP-07-008	SHOULD	When two or more embargo proposals are open and no embargo has yet been accepted (\(q^{em} \in P\)), Participants SHOULD accept the shortest one and propose the remainder as revisions The shortest open proposal is acceptable to every proposer, since each asked for at least that much time. Accepting it puts an embargo in force at once, and treating the rest as revisions keeps the longer requests under discussion.
VP-07-009	SHOULD	When two or more embargo revisions are open and an embargo is active (\(q^{em} \in R\)), Participants SHOULD accept or reject them individually in earliest-to-latest expiration order Open revisions with different end times interact: accepting a later one first can make an earlier one meaningless. Deciding them in expiration order lets each be judged against the terms actually in force.
VP-07-010	MAY	Participants MAY include a default embargo as part of a published Vulnerability Disclosure Policy A published default sets reporters' expectations and lets VP-07-002 apply. Keeping it optional leaves the protocol usable by participants who negotiate case by case.
VP-07-011	MAY	When the Receiver has no default, the Receiver MAY propose a revision after accepting the Sender's proposal Accepting the sender's proposal secures protection at once, but the receiver may need different terms once it knows more. A later revision lets it ask without leaving the case unprotected.
VP-07-012	MAY	When the Sender proposes longer than the Receiver's default, the Receiver MAY accept or reject the proposed extension The sender's longer request is a proposed revision, not an obligation (VP-07-004). The receiver judges whether the extra time is justified.
VP-07-013	MAY	When the Sender proposes shorter than the Receiver's default, the Sender MAY accept or reject the Receiver's proposed revision The receiver's longer default is a proposed revision (VP-07-005), and the sender is not bound by it. The sender judges whether the extra time is acceptable.

Multi-Party Coordination

ID	Priority	Requirement	Related
VP-08-001	MUST	When inviting a new Participant to a case with an existing embargo, the inviting Participant SHALL propose the existing embargo to the invited Participant A newcomer must know which embargo binds the case before it sees case information. Proposing the existing embargo is how it learns the terms and is asked to keep them.
VP-08-002	SHOULD	Participants SHOULD attempt to establish an embargo as early in the process of handling the case as possible Information shared before an embargo is in place is unprotected. Establishing one early limits how much is shared without any agreement.
VP-08-003	SHOULD	Participants SHOULD follow consensus agreement to decide embargo terms In an MPCVD case each participant must be able to keep the terms. Terms set without broad agreement risk being broken by participants who could never meet them.
VP-08-004	SHOULD	All known Vendors of affected software SHOULD be included as Participants A vendor left out of the case cannot prepare a fix, so its users are exposed at publication. Including every known affected vendor lets all fixes be ready together.
VP-08-005	SHOULD	A newly invited Participant to a case with an existing embargo SHOULD accept the existing embargo The existing participants agreed the terms around their own work. A newcomer that accepts them joins without forcing a renegotiation, and can still propose a revision afterwards (VP-08-016).
VP-08-006	SHOULD NOT	The inviting Participant SHOULD NOT share the vulnerability report with a newly invited Participant unless the new Participant has accepted the existing embargo Sharing the report with a participant that has not agreed to keep it private puts the whole case at risk of an uncoordinated release.
VP-08-007	SHOULD	Participants with short default embargo policies SHOULD consider accepting longer embargoes in MPCVD cases In an MPCVD case the slowest vendor sets when all affected users can have a fix. A participant whose own policy is short may need to accept more time so others can finish.
VP-08-008	SHOULD	Potential Participants with a longer default policy than an existing case SHOULD accept the embargo terms offered The existing terms were set around the existing participants' work. A newcomer that insists on its own longer default could hold them up, so it accepts the case's terms and seeks a revision if needed.
VP-08-009	SHOULD	Participants in a case with an existing embargo SHOULD notify Vendors with a longer default embargo policy A vendor with a longer default policy may not be able to meet the existing embargo. Notifying it lets it start work, or ask for a revision, before the deadline instead of being surprised at publication.
VP-08-010	SHOULD	Participants known to leak or provide vulnerability information to adversaries as a matter of policy or historical fact SHOULD be treated similar to Participants with brief disclosure policies A participant known to leak behaves, in effect, like one that will disclose early. Treating it that way keeps others from sharing more with it than they would with a party that publishes quickly.
VP-08-011	MAY	When consensus fails to reach agreement on embargo terms, Participants MAY appoint a case lead to resolve conflicts Consensus can fail, and a case cannot wait indefinitely for terms. A case lead gives the participants a way to reach a decision.
VP-08-012	MAY	Participants MAY engage a third-party Coordinator to act as a neutral case lead to resolve conflicts between Participants When participants disagree, a party with no product at stake can judge the dispute fairly. A third-party Coordinator offers that neutrality.
VP-08-013	MAY	Third-party Coordinators MAY be included as Participants Coordinators bring contacts, experience and neutrality that help complex cases. Allowing them as participants lets them take part directly rather than from outside.
VP-08-014	MAY	Other parties MAY be included as Participants when necessary and appropriate Some cases need parties beyond vendors and reporters, such as service providers, government agencies or large deployers. Allowing them when needed lets the case include everyone who can reduce harm.
VP-08-015	MAY	The inviting Participant MAY interpret a potential Participant's default embargo policy in accordance with default acceptance strategies A potential participant's published default tells the inviter how it is likely to respond. Applying the default acceptance strategies (VP-07) lets the inviter predict the outcome and propose suitable terms.
VP-08-016	MAY	A newly invited Participant MAY propose a revision after accepting the existing embargo Accepting first secures the newcomer's protection and the case's information. A later revision still lets it ask for terms that fit its needs.
VP-08-017	MAY	Participants in an MPCVD case MAY delay notifying potential Participants with short default embargo policies until their policy aligns with the agreed embargo A participant whose policy would end the embargo early could publish before others are ready. Delaying its notification until its policy fits the agreed embargo reduces that risk.
VP-08-018	MAY	After accepting an existing embargo, newly invited Participants with a longer default policy MAY propose a revision to accommodate their preferences The newcomer may need more time than the existing embargo gives. Proposing a revision after accepting lets it ask while the case stays protected.
VP-08-019	MAY	Existing Participants MAY accept or reject a proposed revision from a newly invited Participant The existing terms were set around the existing participants' work. They must be free to decide whether a newcomer's request suits them.
VP-08-020	MAY	Participants in a case with an existing embargo MAY choose to extend the embargo to accommodate a newly added Participant A newly added vendor may need more time to prepare a fix. Extending the embargo lets its users also be protected at publication.
VP-08-021	MAY	Participants MAY decline to participate in future CVD cases involving parties with a history of violating previous embargoes A party that has broken embargoes before is likely to do so again. Declining to work with it protects future cases from that risk.

Embargo Early Termination

ID	Priority	Requirement	Related
VP-09-001	MUST	Embargoes SHALL terminate immediately when information about the vulnerability becomes public (\(q^{cs} \in \{\cdots P \cdots, \cdots X \cdot\}\)) Once the vul or its exploit is public, secrecy protects no one: attackers already have the information and defenders need it. Holding to the embargo would only stop participants from helping users respond.
VP-09-002	SHOULD	Participants SHOULD be prepared with contingency plans in the event of early embargo termination Leaks, exploit publication and attacks can end an embargo at any time. A participant with no plan for that moment cannot publish advice or fixes quickly, which leaves users exposed.
VP-09-003	SHOULD	Embargoes SHOULD terminate immediately when there is evidence that the vulnerability is being actively exploited by adversaries (\(q^{cs} \in \{\cdots A\}\)) Active exploitation means users are being harmed now and defenders need information to respond. Keeping the embargo, or delaying the teardown, would only preserve the attackers' advantage.
VP-09-004	SHOULD	Embargoes SHOULD terminate early when there is evidence that adversaries possess exploit code for the vulnerability Adversaries holding exploit code can attack at any time. Ending the embargo early lets defenders get information and mitigations before attacks spread.
VP-09-005	SHOULD	Participants SHOULD consider the software supply chain when determining an appropriate quorum of Vendors for release Downstream vendors build on upstream components and often cannot ship fixes until those are released. A quorum that ignores the supply chain could trigger release while many affected users still have no fix available.
VP-09-006	MAY	Embargoes MAY terminate early when there is evidence that adversaries are aware of the technical details of the vulnerability If adversaries already know the technical details, secrecy stops buying defenders time. Participants may then end the embargo so defenders can act.
VP-09-007	MAY	Embargoes MAY terminate early when a quorum of Vendor Participants is prepared to release fixes (\(q^{cs} \in VF\cdots\)), even if some Vendors remain unprepared 'Quorum' is intentionally left undefined at the protocol level. Different CVD communities may adopt different decision rules (simple majority by count, weighted by deployed-user impact, unanimity, etc.). This requirement marks an expansion point for future community-specific behavioral norms rather than prescribing a single rule.

Embargo Case Splits and Merges

ID	Priority	Requirement	Related
VP-10-001	MUST	If no new embargo has been proposed or agreement has not been reached following a case merge, the earliest of the previously accepted embargo dates SHALL be adopted for the merged case Each merged case brought an embargo some participants had already agreed to. Adopting the earliest end time breaks no participant's commitment, since none agreed to withhold past its own date, until a new agreement is reached.
VP-10-002	MUST	If a child case following a case split requires an embargo end time earlier than the inherited date, the CASE_MANAGER of that child case SHALL notify the CASE_MANAGERs of all sibling child cases before the earlier end time takes effect, documenting the rationale in the case ledger. Child cases from one split share the same vul information, so an earlier end in one child in effect ends the embargo for its siblings too. Notifying the siblings' CASE_MANAGERs before it takes effect, with the reason on the ledger, gives their participants time to prepare and to see why.
VP-10-003	MUST	Participants in a child case SHALL communicate any subsequently agreed changes from the inherited embargo to the Participants of the other child cases Child cases share information that came from one parent. A change agreed in one child can change what the others may safely disclose and when, so their participants must learn of it.
VP-10-004	SHOULD	A new embargo SHOULD be proposed when any two or more CVD cases are to be merged and multiple parties have agreed to different embargo terms prior to the merger Participants of the merging cases agreed to different terms, and no single set binds all of them. A new proposal lets everyone agree to one set.
VP-10-005	SHOULD	When a case is split into two or more parts, any existing embargo SHOULD transfer to the new cases The information in each new case was shared under the parent's embargo. Carrying the embargo over keeps it protected on terms everyone already agreed to.
VP-10-006	SHOULD	If any of the new cases need to renegotiate the embargo inherited from the parent case, any new embargo SHOULD be later than the inherited embargo The information in a child case is also held in its siblings. An earlier end in one child could expose the others before they are ready, so renegotiated terms should only extend the inherited date.
VP-10-007	MAY	Participants MAY propose revisions to the embargo on a merged case as usual A merged case is still a case, and its work keeps changing. Participants need the usual way to adjust its terms.
VP-10-008	MAY	Participants approaching a case split MAY engage a Coordinator to act as a trusted third party to help resolve and coordinate embargo dependencies for the new cases Splitting a case creates embargo dependencies between the new cases that their participants may not each see. A trusted third party who can see all of them can keep them consistent.

EM Messaging

ID	Priority	Requirement	Related
VP-11-002	MUST	When the vulnerability or an exploit is public, the authority to terminate the case-level embargo SHALL belong to the Case Owner (CM-02-005). Public here means \(q^{cs} \in \{\cdots P \cdots, \cdots X \cdot\}\). Once the vul or an exploit is public, the embargo must end (VP-09-001). Separating who reports the condition (VP-11-003) from who ends the embargo keeps one authoritative decision, made by the Case Owner and recorded by the CASE_MANAGER (VP-11-011), so participants never disagree about whether the embargo still holds.
VP-11-003	MUST	Participants SHALL initiate embargo termination upon becoming aware of publicly available information about the vulnerability or its exploit code Other participants may not have seen the public information. Initiating termination makes sure the case learns of it and the embargo ends promptly.
VP-11-004	SHOULD	Recipients SHOULD acknowledge the \(E*\) messages they receive. The acknowledgment (\(EK\)) is the CASE_MANAGER's ledger entry for the message, fanned out to the participants as Announce(CaseLedgerEntry); no \(EK\) message is sent (EP-09-009). An embargo message changes what participants may disclose. Acknowledging it tells the sender it arrived, so silence is not mistaken for agreement or for a lost message. Every \(E*\) message goes to the CASE_MANAGER (EP-09), and the ledger entry it commits already tells every participant the message was received; a separate \(EK\) message would only add traffic and a second acknowledgment that could disagree with the ledger.
VP-11-005	SHOULD	Participants SHOULD acknowledge (\(EK\)) and inquire (\(GI\)) about the nature of any error reported by an incoming \(EE\) message An \(EE\) means the other side could not process an embargo message, so the two may now hold different embargo states. Acknowledging it and asking what went wrong lets them find and fix the mismatch.
VP-11-006	MUST	When attacks are known to have occurred (\(q^{cs} \in \cdots A\)), the authority to terminate the case-level embargo SHALL belong to the Case Owner (CM-02-005). Known attacks mean the embargo should end (VP-09-003). As with VP-11-002, one party holds the authority to end it, so participants never disagree about whether it still holds. The Case Owner may delegate this decision in advance, for example by configuring CaseOwnerApprovesStatusUpdate to approve reported attacks automatically (RSH-07-003), which then also ends the embargo (ADR-0166). The decision is made ahead of time, and the authority stays with the Case Owner.
VP-11-007	SHOULD	Participants SHOULD initiate embargo termination upon becoming aware of attacks against an otherwise unpublished vulnerability Others in the case may not know about the attacks. Initiating termination makes sure the case learns of them and can end the embargo.
VP-11-008	SHOULD	If early embargo termination is desired but the termination date/time is in the future, this SHOULD be achieved through an Embargo Revision Proposal and additional communication Participants must keep the existing terms until the new end time arrives. A revision proposal changes the end time through the usual agreement process, rather than leaving participants unsure whether the embargo still holds.
VP-11-009	MAY	Participants MAY begin embargo negotiations before sending the report itself in an \(RS\) message; therefore it is not an error for an \(E*\) message to arrive while the Recipient is unaware of the report (\(q^{rm} \in S\)) Negotiating before sending the report lets the sender protect it from the moment it is shared. Treating an early \(E*\) as an error would block that.
VP-11-010	MAY	Participants MAY reject any embargo proposals or revisions for any reason An embargo binds only those who agree. Participants must be free to refuse proposals or revisions they cannot keep.
VP-11-011	MUST	The CASE_MANAGER SHALL effect the teardown of a case-level embargo that the Case Owner terminates (VP-11-002, VP-11-006). It is the single writer of canonical case state (EMB-19-001). One writer of case state means every participant sees the same teardown in the same place in the ledger. The Case Owner decides; the CASE_MANAGER records and announces the decision.
VP-11-012	MUST NOT	A Participant other than the authorising Case Owner SHALL NOT terminate the case-level embargo itself. It can initiate termination (VP-11-003, VP-11-007) and end its own compliance (VP-13-017). If any participant could end the case-level embargo, participants could disagree about whether it still holds. Initiating termination and ending one's own compliance let a participant act on what it knows without overriding the Case Owner (VP-11-002).

CVD Case State (CS) Messaging

ID	Priority	Requirement	Related
VP-12-001	SHOULD	Vendor Awareness (\(CV\)) messages SHOULD be sent only by Participants with direct knowledge of the notification (i.e., either the Participant who sent the report to the Vendor or the Vendor upon receipt of the report) Only those who took part in the notification know for certain that the vendor was told. Restricting \(CV\) to them stops second-hand reports from marking a vendor aware when it was not.
VP-12-002	SHOULD	Once attacks are observed (\(q^{cs} \in \cdots A\)), fix development SHOULD accelerate. Attacks mean users are being harmed while no fix exists. Speeding fix development shortens that harm.
VP-12-002c	SHOULD	Once attacks are observed (\(q^{cs} \in \cdots A\)), publication and deployment SHOULD follow as soon as is practical. While attacks continue, every day without published advice or a deployed fix leaves users harmed. Publishing and deploying as soon as practical shortens that harm.	Refines: VP-12-002

RM-EM Interactions

ID	Priority	Requirement	Related
VP-13-001	SHOULD	The EM process SHOULD begin when a recipient is in RM Received (\(q^{rm} \in R\)) whenever possible Received is the earliest point at which the recipient holds the report. Starting embargo work there protects the report before validation, rather than after information may already have been shared.
VP-13-002	SHOULD NOT	Embargo Management SHOULD NOT begin in an inactive RM state (\(q^{rm} \in \{I, D, C\}\)) Invalid, Deferred and Closed mean the participant is not working on the report. Starting an embargo from those states would bind others to a timeline nobody is working toward.
VP-13-003	SHOULD NOT	Embargo Management SHOULD NOT begin with a proposal from a Participant in RM Invalid (\(q^{rm} \in I\)) A participant that judged the report invalid does not believe there is a real vul to protect. A proposal from it would ask others to withhold information about something it does not think needs fixing.
VP-13-004	SHOULD NOT	Embargo Management SHOULD NOT proceed from EM Proposed to EM Accepted when RM is Invalid or Closed (\(q^{rm} \in \{I, C\}\)) An Invalid or Closed participant is not working on the report. Agreeing to an embargo then would commit it to terms it has no intent to work toward.
VP-13-005	SHOULD NOT	Participants SHOULD NOT close reports (\(q^{rm} \in \{R,I,D,A\} \xrightarrow{c} C\)) while an embargo is active (\(q^{em} \in \{A, R\}\)) A participant that closes may stop watching the case and lose track of its obligations. Keeping the report open while the embargo runs keeps the participant aware of the embargo until it ends.
VP-13-006	SHOULD	Reports with no further tasks SHOULD be held in Deferred or Invalid (\(q^{rm} \in \{D, I\}\)) until the embargo has terminated (\(q^{em} \in X\)) Holding the report in Deferred or Invalid keeps the participant attached to the case, and aware of the embargo, until the embargo ends, without claiming any further work.
VP-13-007	SHOULD	Participants who choose to close a report while an embargo remains in force SHOULD communicate their intent to either continue to adhere to the embargo or terminate their compliance with it Remaining participants need to know whether someone who closed will still keep the information private. That tells them whether the embargo still holds.
VP-13-008	SHOULD	Any changes to a Participant's intention to adhere to an active embargo SHOULD be communicated clearly in addition to any necessary RM or EM state change notifications An RM or EM state change does not say whether the participant will keep the embargo. Saying so clearly stops others from relying on a commitment that has changed.
VP-13-009	MUST	A Participant's closure or deferral (\(q^{rm} \in \{C, D\}\)) of a report while an embargo remains active (\(q^{em} \in \{A, R\}\)) and while other Participants remain engaged SHALL NOT automatically terminate the embargo One participant's exit must not end protection for those still working on fixes. Otherwise any participant could end the embargo for everyone by closing or deferring.
VP-13-010	MAY	The EM process MAY begin prior to the report being sent to a potential Participant (\(q^{rm} \in S\)) Negotiating before sending the report lets the sender protect it from the moment it is shared (VP-11-009).
VP-13-011	MAY	Embargo Management MAY begin in any of the active RM states (\(q^{rm} \in \{R, V, A\}\)) In the active RM states the participant is working on the report. Allowing the embargo to start in any of them keeps protection timely without waiting for a later step.
VP-13-012	MAY	Embargo Management MAY run in parallel to validation (\(q^{rm} \in \{R,I\} \xrightarrow{\{v,i\}} \{V,I\}\)) and prioritization (\(q^{rm} \in V \xrightarrow{\{a,d\}} \{A,D\}\)) activities Validation and prioritization can take time. Running embargo work alongside them protects the report while those decisions are made.
VP-13-013	MAY	EM revision proposals and acceptance or rejection of those proposals MAY occur during any of the valid yet unclosed RM states (\(q^{rm} \in \{V, A, D\}\)) Valid, Accepted and Deferred participants still have a stake in the report. Allowing revisions then lets the embargo follow changes in the work.
VP-13-014	MAY	Outstanding embargo negotiations (\(q^{em} \in P\)) MAY continue in RM Invalid (\(q^{rm} \in I\)) if additional information may be forthcoming to promote the report from Invalid to Valid An Invalid report may become valid with more information (VP-02-033). Keeping the negotiation open protects the report until that is known.
VP-13-015	MAY	Embargo Management MAY proceed from EM Proposed to EM Accepted when RM is neither Invalid nor Closed (\(q^{rm} \in \{R, V, A, D\}\)) In these RM states the participant holds the report and is not done with it, so agreeing to an embargo protects real ongoing work.
VP-13-016	MAY	Embargo Management MAY proceed from EM Proposed to EM None (\(q^{em} \in P \xrightarrow{r} N\)) when RM is Invalid or Closed An Invalid or Closed participant has no ongoing work to protect, so letting the proposal fall back to no embargo matches its position.
VP-13-017	MAY	Participants MAY choose to terminate their compliance with an embargo at any time Embargo participation is voluntary, and a participant may become unable to keep the terms. Ending its own compliance openly does less harm than staying in and breaking them, and does not end the embargo for others (VP-13-009).
VP-13-018	MAY	When a Participant receives another Participant's notice that it intends to end its compliance with an embargo, it MAY end its own compliance (VP-13-017). When one participant will stop keeping the embargo, others may judge that it has stopped protecting them. Letting them end their own compliance lets the case respond without any participant acting beyond its own authority.
VP-13-019	MAY	When a Participant gives notice that it intends to end its embargo compliance, the Case Owner MAY terminate the case-level embargo (CM-02-005). The CASE_MANAGER then carries out the termination (EMB-19-001). One participant leaving the embargo may leave it protecting no one. Terminating the case-level embargo is the Case Owner's authority, so the Case Owner decides, and the CASE_MANAGER, the single writer of case state, carries it out.

RM-EM-CS Interactions

ID	Priority	Requirement	Related
VP-14-004	MUST	Participants MUST treat attacks as an event that could occur at any time and adapt their process as needed in light of available information Attacks can start before, during or after an embargo, without warning. A process that assumes they will not leaves users unprotected when they do.
VP-14-005	SHOULD	Once a case has reached Vendor Aware (\(q^{cs} \in Vfdpxa\)) for at least one Vendor, if the EM process has not started, it SHOULD begin as soon as possible Once a vendor knows, information about the vul is spreading among parties. Starting the EM process then keeps it from spreading further without an agreement.
VP-14-006	SHOULD	Any proposed embargo SHOULD be decided (accept or reject) soon after the first Vendor is notified An undecided proposal leaves the notified vendor unsure whether it may share the information. A quick decision gives it clear terms to work under.
VP-14-007	SHOULD NOT	Once a case reaches Fix Ready (\(q^{cs} \in VF\cdot pxa\)), Participants SHOULD NOT start a new embargo negotiation and SHOULD reject a pending proposal. The one exception is a brief embargo to prepare for publication or deployment (VP-06-008, VP-06-008b). With a fix ready, the remaining work is release. A new or pending embargo would only delay getting the fix to users, unless it is the short window that lines that release up.
VP-14-008	SHOULD	Existing embargoes (\(q^{em} \in \{Active, Revise\}\)) when Fix Ready is reached SHOULD prepare to terminate soon With a fix ready, most of the reason for the embargo is gone. Preparing to end it lets participants release quickly.
VP-14-009	SHOULD	Participants SHOULD accept reasonable extension proposals to allow trailing Vendors to catch up before publication when possible Publishing before all vendors are ready leaves the trailing vendors' users exposed. A reasonable extension can let everyone release together.
VP-14-010	SHOULD NOT	Once a fix has been deployed (\(q^{cs} \in VFD\cdots\)), a Participant SHOULD NOT seek a new embargo. After the fix is deployed there is nothing left to protect by secrecy, so a new embargo only delays user awareness.
VP-14-015	SHOULD	Once a fix has been deployed (\(q^{cs} \in VFD\cdots\)), any existing embargo SHOULD terminate. After the fix is deployed there is nothing left to protect by secrecy, so a continuing embargo only delays user awareness.
VP-14-011	SHOULD	Exploit Publishers who are Participants in pre-public CVD cases (\(q^{cs} \in \cdots p \cdots\)) SHOULD comply with the protocol, especially when they also fulfill other roles (e.g., Reporter, Coordinator, Vendor) An Exploit Publisher in a pre-public case knows about the vul before the public. If it ignores the protocol, especially while also acting as Reporter, Coordinator or Vendor, it can make the vul public before fixes are ready.
VP-14-012	SHOULD NOT	Exploit Publishers SHOULD NOT release exploit code while an embargo is active (\(q^{em} \in \{A, R\}\)) Released exploit code lets attackers use the vul at once. Releasing it during an embargo exposes users before fixes are ready.
VP-14-014	MAY	In MPCVD cases where some Vendors reach Fix Ready before others, Participants MAY propose an embargo extension to allow trailing Vendors to catch up before publication When some vendors are ready earlier, publishing at once would leave the other vendors' users exposed. An extension proposal lets participants choose to give the trailing vendors time.

Implementation Guidance

ID	Priority	Requirement	Related
VP-15-004	MAY	Vultron Protocol implementations MAY use end-to-end encryption to protect sensitive data in transit Transport encryption protects each hop only, and messages may pass through intermediaries. End-to-end encryption also protects them from those intermediaries.

Embargo Representation Privacy

ID	Priority	Requirement	Related
VP-16-001	MUST NOT	Vulnerability details MUST NOT appear in embargo representation data (e.g., embargo scheduling or notification messages) Embargo data, such as calendar entries and schedule notices, spreads further and with less care than case content. Keeping vul details out of it stops embargo scheduling from leaking the vul.
VP-16-002	SHOULD	A case or vulnerability identifier SHOULD appear in embargo representation data along with an indication that it relates to an embargo expiration Recipients need to know which case an embargo date belongs to and that it is an embargo end. An identifier and an explicit embargo indication give them that without sharing any details.
VP-16-003	SHOULD NOT	Case or vulnerability identifiers SHOULD NOT carry any information that reveals potentially sensitive details about the vulnerability Identifiers travel outside the embargo, for example in embargo notices (VP-16-002). An identifier that hints at the product or the flaw would leak information through that route.

CASE_MANAGER Write Authority

ID	Priority	Requirement	Related
VP-17-001	MUST	Every change to the canonical case state MUST go through the CASE_MANAGER, so no participant changes that state directly. This single-writer axiom prevents concurrent-write races and ensures that all shared state changes flow through the actor's consistency checks and persistence layer. The CS participant-specific axes (RM, VFD) are owned by each participant's CaseParticipant record and are intentionally excluded from this restriction.	Refines: VP-02-001
VP-17-002	MUST NOT	A participant MUST NOT update its local case replica by direct mutation from an inbound protocol message. Direct mutation from inbound messages (e.g., Add(Note)[target=VulnerabilityCase]) would bypass the ledger ordering guarantees and create divergence from the canonical case state. This path is distinct from VP-17-001 and is not a bypass of the CASE_MANAGER write constraint.	Refines: VP-17-001 Constrains: SM-10-002
VP-17-003	MUST	A participant MUST update its local case replica only by replaying ledger entries from Announce(CaseLedgerEntry) fan-out. Ledger replay is the intended propagation mechanism for keeping participant replicas consistent with canonical case state, in the ledger's order.	Satisfies: VP-17-002

Routing Topology

ID	Priority	Requirement	Related
VP-18-001	MUST	Outbound messages from a participant MUST follow the routing path: participant → CASE_MANAGER → CaseLedgerEntry → broadcast → participants. The ledger record provides the audit trail and ordering guarantees for all case activity. Direct peer-to-peer delivery bypasses the ledger and the broadcast idempotency controls.	Refines: PCR-08-001 — participant-case-relationships.yaml — PCR-08 covers ledger-based broadcast
VP-18-002	MUST NOT	A participant MUST NOT deliver messages directly to another participant's inbox. Direct peer-to-peer delivery bypasses the case ledger, removing the audit trail and broadcast idempotency guarantees.	Refines: VP-18-001
VP-18-003	MUST	Delivery of outbound participant messages MUST be mediated by the CASE_MANAGER and recorded in the case ledger before being fanned out to participants. Mediation through the CASE_MANAGER ensures all case activity is ledger-ordered and consistently broadcast to all participants.	Refines: VP-18-001