Reference

Report, Embargo and Case State Behavior

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.3 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.3 Report, Embargo and Case State Behavior

The requirements on the state machines and on how a participant behaves in each state: Report Management (RM), Embargo Management (EM), embargo policy, durations, and the Case State (CS) model.

State Machine

Requirements governing how the RM (Report Management), EM (Embargo Management), and CS (CVD Case State: VFD and PXA axes) protocol state machines are defined, represented, and executed at runtime. Each participant maintains its own RM state; the CASE_MANAGER maintains shared EM and Case State. Within CS, the PXA axis is shared across participants while the VFD axis is per-participant.

Wire and DataLayer Compatibility

ID	Priority	Requirement	Related
SM-08-001	MUST	State values MUST be transmitted on the wire as the state's bare label string (for example RECEIVED, ACTIVE, Vf, D, pxa), never as an integer or as a qualified form such as RM.RECEIVED. Other implementations must read the state values in a message. A bare label, such as RECEIVED or pxa, is the value of the state itself, and any implementation can match it. An integer depends on the order of an enum in one implementation, and a qualified form such as RM.RECEIVED depends on its code names. Neither form is part of the protocol.

CS Forced Transitions and Reachable States

ID	Priority	Requirement	Related
SM-09-002	MUST NOT	The CS state machine MUST NOT allow a state in pattern vF* (fix ready, vendor unaware) or *fD* (fix deployed, fix not ready). A vendor cannot have deployed a fix (D) without first having one ready (F); a fix cannot be ready (F) if the vendor is unaware (v) of the vulnerability. Together, SM-09-001 and this rule reduce the theoretical 64-state CS space to the 32 reachable CS states: 4 valid VFD combinations (vfd, Vfd, VFd, VFD) × 8 PXA combinations. See docs/reference/formal_protocol/states.md for the formal derivation. Note: the "40-state" figure in the formal protocol paper refers to the global case state space (8 PXA × 5 EM), not to CS alone.	Refines: SM-09-001
SM-09-004	MUST	A receiver MUST reject a CS state in the vF* or *fD* pattern (SM-09-002) at validation time. These 32 states are structurally impossible. A receiver that rejects them at validation time keeps them out of every store and replica.	Implements: SM-09-002

State Scoping Rules

ID	Priority	Requirement	Related
SM-10-001	MUST	A message that moves a participant-specific machine (RM, VF or D) MUST move it for the participant whose state the message's occasion declares (ADR-0162). For a participant-status message, that participant is the sender (CM-04-001, CM-04-002). For a report's receipt, it is the receiver, whose own RM moves to RM.RECEIVED. RM and VFD state describe the progress of one participant, so each participant's RM and VFD state evolves independently. A status message reports its sender's state; other messages move the receiver's own. No rule on the machine alone tells which, so each occasion declares it. A record on the wrong participant would give it progress it did not make.
SM-10-002	MUST	EM and PXA state transitions MUST update the shared CaseStatus record for the associated VulnerabilityCase. These axes are participant-agnostic: a single shared value covers all participants in the case. EM and PXA state are facts about the case, not about one participant (CM-04-003, CM-04-004). One shared record gives every participant the same embargo state and the same public state. Separate copies for each participant could disagree on whether an embargo is in force or whether the vul is public.	Refines: CM-04-003 Refines: CM-04-004
SM-10-003	MUST NOT	A receiver MUST NOT apply a participant-specific axis transition (RM, VFD) to the shared CaseStatus. It MUST NOT apply a participant-agnostic axis transition (EM, PXA) to a participant's ParticipantStatus. Mixing axes is a protocol correctness violation. A transition that writes across the two kinds of state has two bad results. An RM or VFD move of one participant can change the shared embargo or public state of the case. A shared EM or PXA event can overwrite the progress of one participant (CM-04-006).	Refines: CM-04-006

Report Management Behavioral Requirements

Event-Condition-Action behavioral requirements for Report Management (RM). Each group is triggered by either a received RM message or a local RM state transition, and specifies typed preconditions, ordered steps, and postconditions that implementations must satisfy.

Receive RS (Report Submission)

Behaviors triggered when a participant receives an RS (Report Submission) message, including RM state transition from Start to Received and vendor CS awareness update.

Trigger: Message Received — RS

ID	Priority	Requirement	Related
RMB-01-001	MUST	A Participant in RM Start (q^rm ∈ S) receiving RS MUST transition their RM state to Received (q^rm S → R). RS is the sole RM message that directly changes the receiver's own RM state. All other RM messages announce sender state only. ECA Details Preconditions - Participant is in RM Start - RM state: START Steps 1. [receiver] Transition RM state from START to RECEIVED → Receiver RM state is RECEIVED 2. [receiver] Emit RK to acknowledge receipt of RS → RK queued for sender Postconditions - Receiver RM state is RECEIVED; RK emitted to sender	Satisfies: VP-03-009 — RK acknowledgment of RS Satisfies: MSM-01-001 — RS shorthand wire-type mapping
RMB-01-002	MUST	A Vendor Participant in RM Start receiving RS that introduces a previously unknown vulnerability (q^cs ∈ vfd···) MUST transition their CS to vendor-aware (q^cs vfd··· → Vfd···) and emit CV to announce the transition. RS is the event that makes a Vendor aware of the vulnerability. The CS V-transition records this awareness and CV announces it to other Participants. ECA Details Preconditions - Participant is in RM Start; Participant holds the Vendor role; CS matches pattern vfd... - RM state: START - Role: vendor - CS pattern: vfd... Steps 1. [receiver] Transition RM state from START to RECEIVED → Receiver RM state is RECEIVED 2. [receiver] Transition CS from vfd··· to Vfd··· (V event) → CS vendor-aware bit set to V 3. [receiver] Emit CV to announce the CS vendor-aware transition → CV queued for case participants 4. [receiver] Emit RK to acknowledge receipt of RS → RK queued for sender Postconditions - Receiver RM state is RECEIVED; CS is vendor-aware; CV and RK emitted	Satisfies: VP-03-002 — Vendor MUST transition CS to Vfd on new RS Satisfies: VP-03-009 — RK acknowledgment of RS Satisfies: MSM-01-001 — RS shorthand wire-type mapping
RMB-01-003	SHOULD	A Vendor Participant already in an active RM state (q^rm ∈ {R,I,V,D,A}) receiving RS for a vulnerability they were previously unaware of (q^cs ∈ vfd···) SHOULD transition CS to Vfd··· and emit CV, even though their RM state does not change. The CS V-transition captures vendor awareness regardless of when the Vendor first receives RS. A Vendor who joins a case mid-lifecycle must still record their own awareness event. ECA Details Preconditions - Participant is in an active RM state (Received/Invalid/Valid/Deferred/Accepted); Participant holds the Vendor role; CS matches pattern vfd... - RM state: RECEIVED, INVALID, VALID, DEFERRED, ACCEPTED - Role: vendor - CS pattern: vfd... Steps 1. [receiver] Transition CS from vfd··· to Vfd··· (V event) → CS vendor-aware bit set to V 2. [receiver] Emit CV to announce the CS vendor-aware transition → CV queued for case participants 3. [receiver] Emit RK to acknowledge receipt of RS → RK queued for sender Postconditions - CS is vendor-aware; CV and RK emitted; receiver RM state unchanged	Satisfies: VP-03-002 — Vendor MUST transition CS to Vfd on receiving RS for new vulnerability Satisfies: VP-03-009 — RK acknowledgment of RS Satisfies: MSM-01-001 — RS shorthand wire-type mapping
RMB-01-004	SHOULD	A Participant in an active RM state (q^rm ∈ {R,I,V,D,A}) receiving a duplicate RS (already Vendor-aware, q^cs ∈ V···) SHOULD emit RK to acknowledge receipt without changing RM or CS state. All R messages warrant acknowledgment unless the report is Closed. Duplicate RS does not re-trigger RM or CS transitions. ECA Details Preconditions - Participant is in an active RM state (Received/Invalid/Valid/Deferred/Accepted) - RM state: RECEIVED, INVALID, VALID, DEFERRED, ACCEPTED Steps 1. [receiver] Emit RK to acknowledge receipt of RS → RK queued for sender Postconditions* - RK emitted; RM and CS states unchanged	Satisfies: VP-03-009 — RK acknowledgment of RS Satisfies: MSM-01-001 — RS shorthand wire-type mapping
RMB-01-005	MAY	A Participant in RM Closed (q^rm ∈ C) receiving any R message MAY ignore it without sending a response. The same holds for non-R traffic (EM, CS, GI) on a closed case (VP-03-013); for the CASE_MANAGER once the case is fully closed, ignoring is not optional: it records nothing (CM-23-013). Closed cases are terminal. The protocol permits silent discard to avoid generating unnecessary traffic for completed work. The R scope is this group's trigger, not the limit of the rule: VP-03-013 covers every message class, and ADR-0085 makes owner close a hard kill switch at the CASE_MANAGER. ECA Details Preconditions* - Participant is in RM Closed - RM state: CLOSED	Satisfies: VP-03-013 — Recipients MAY ignore messages received on Closed cases Satisfies: MSM-01-001 — RS shorthand wire-type mapping

Receive RI (Report Invalid)

Behaviors triggered when a participant receives an RI (Report Invalid) message, updating the sender's RM state model.

Trigger: Message Received — RI

ID	Priority	Requirement	Related
RMB-02-001	SHOULD	A Participant in an active RM state (q^rm ∈ {R,I,V,D,A}) receiving RI SHOULD update their record of the sender's RM state to Invalid. RI is a status announcement — it does not change the receiver's own RM state but informs them of the sender's validation result. Maintaining this record supports shared situation awareness. ECA Details Preconditions - Participant is in an active RM state (Received/Invalid/Valid/Deferred/Accepted) - RM state: RECEIVED, INVALID, VALID, DEFERRED, ACCEPTED Steps 1. [receiver] Update local model of sender RM state to INVALID → Sender RM state recorded as INVALID in receiver's model Postconditions - Receiver RM state unchanged; sender's recorded RM state is INVALID	Satisfies: VP-02-019 — Shared awareness of sender RM state change Satisfies: MSM-01-002 — RI shorthand wire-type mapping
RMB-02-002	SHOULD	A Participant in RM Start (q^rm ∈ S) receiving RI SHOULD respond with both RE (to signal the unexpected message) and GI (to inquire what the sender expected). Receiving any R message other than RS while in RM Start means the sender believes the receiver is coordinating a report the receiver has no knowledge of. RE+GI is the protocol-specified error response. ECA Details Preconditions - Participant is in RM Start - RM state: START Steps 1. [receiver] Emit RE to signal the unexpected message error → RE queued for sender 2. [receiver] Emit GI to inquire what the sender expected → GI queued for sender Postconditions* - RE and GI emitted; receiver RM state unchanged (START)	Satisfies: VP-03-010 — RE+GI when R (other than RS) received while in RM Start Satisfies*: MSM-01-002 — RI shorthand wire-type mapping

Receive RV (Report Valid)

Behaviors triggered when a participant receives an RV (Report Valid) message, updating the sender's RM state model.

Trigger: Message Received — RV

ID	Priority	Requirement	Related
RMB-03-001	SHOULD	A Participant in an active RM state (q^rm ∈ {R,I,V,D,A}) receiving RV SHOULD update their record of the sender's RM state to Valid. RV announces the sender's validation result. Maintaining this record supports shared situation awareness across Participants. ECA Details Preconditions - Participant is in an active RM state (Received/Invalid/Valid/Deferred/Accepted) - RM state: RECEIVED, INVALID, VALID, DEFERRED, ACCEPTED Steps 1. [receiver] Update local model of sender RM state to VALID → Sender RM state recorded as VALID in receiver's model Postconditions - Receiver RM state unchanged; sender's recorded RM state is VALID	Satisfies: VP-02-019 — Shared awareness of sender RM state change Satisfies: MSM-01-003 — RV shorthand wire-type mapping
RMB-03-002	SHOULD	A Participant in RM Start (q^rm ∈ S) receiving RV SHOULD respond with RE and GI to signal the error and inquire what the sender expected. Receiving any R message other than RS while in RM Start is an error condition indicating the sender has a mistaken expectation about the receiver's case knowledge. ECA Details Preconditions - Participant is in RM Start - RM state: START Steps 1. [receiver] Emit RE to signal the unexpected message error → RE queued for sender 2. [receiver] Emit GI to inquire what the sender expected → GI queued for sender Postconditions* - RE and GI emitted; receiver RM state unchanged (START)	Satisfies: VP-03-010 — RE+GI when R (other than RS) received while in RM Start Satisfies*: MSM-01-003 — RV shorthand wire-type mapping

Receive RD (Report/Case Deferred)

Behaviors triggered when a participant receives an RD (Report/Case Deferred) message, updating the sender's RM state model.

Trigger: Message Received — RD

ID	Priority	Requirement	Related
RMB-04-001	SHOULD	A Participant in an active RM state (q^rm ∈ {R,I,V,D,A}) receiving RD SHOULD update their record of the sender's RM state to Deferred. RD announces the sender's deferral decision. Maintaining this record supports shared situation awareness and coordination planning. ECA Details Preconditions - Participant is in an active RM state (Received/Invalid/Valid/Deferred/Accepted) - RM state: RECEIVED, INVALID, VALID, DEFERRED, ACCEPTED Steps 1. [receiver] Update local model of sender RM state to DEFERRED → Sender RM state recorded as DEFERRED in receiver's model Postconditions - Receiver RM state unchanged; sender's recorded RM state is DEFERRED	Satisfies: VP-02-019 — Shared awareness of sender RM state change Satisfies: MSM-01-004 — RD shorthand wire-type mapping
RMB-04-002	SHOULD	A Participant in RM Start (q^rm ∈ S) receiving RD SHOULD respond with RE and GI to signal the error and inquire what the sender expected. Receiving any R message other than RS while in RM Start is an error condition. ECA Details Preconditions - Participant is in RM Start - RM state: START Steps 1. [receiver] Emit RE to signal the unexpected message error → RE queued for sender 2. [receiver] Emit GI to inquire what the sender expected → GI queued for sender Postconditions* - RE and GI emitted; receiver RM state unchanged (START)	Satisfies: VP-03-010 — RE+GI when R (other than RS) received while in RM Start Satisfies*: MSM-01-004 — RD shorthand wire-type mapping

Receive RA (Report/Case Accepted)

Behaviors triggered when a participant receives an RA (Report/Case Accepted) message, updating the sender's RM state model to Accepted and acknowledging receipt.

Trigger: Message Received — RA

ID	Priority	Requirement	Related
RMB-05-001	SHOULD	A Participant in an active RM state (q^rm ∈ {R,I,V,D,A}) receiving RA SHOULD update their record of the sender's RM state to Accepted. RA announces the sender's commitment to work the report. Recording this supports shared situation awareness and helps coordinate timing of follow-on actions such as embargo proposals. ECA Details Preconditions - Participant is in an active RM state (Received/Invalid/Valid/Deferred/Accepted) - RM state: RECEIVED, INVALID, VALID, DEFERRED, ACCEPTED Steps 1. [receiver] Update local model of sender RM state to ACCEPTED → Sender RM state recorded as ACCEPTED in receiver's model Postconditions - Receiver RM state unchanged; sender's recorded RM state is ACCEPTED	Satisfies: VP-02-019 — Shared awareness of sender RM state change Satisfies: MSM-01-005 — RA shorthand wire-type mapping
RMB-05-002	SHOULD	A Participant in RM Start (q^rm ∈ S) receiving RA SHOULD respond with RE and GI to signal the error and inquire what the sender expected. Receiving any R message other than RS while in RM Start is an error condition indicating the sender has a mistaken expectation about the receiver's case knowledge. ECA Details Preconditions - Participant is in RM Start - RM state: START Steps 1. [receiver] Emit RE to signal the unexpected message error → RE queued for sender 2. [receiver] Emit GI to inquire what the sender expected → GI queued for sender Postconditions* - RE and GI emitted; receiver RM state unchanged (START)	Satisfies: VP-03-010 — RE+GI when R (other than RS) received while in RM Start Satisfies*: MSM-01-005 — RA shorthand wire-type mapping

Receive RC (Report Closed)

Behaviors triggered when a participant receives an RC (Report Closed) message, updating the sender's RM state model to Closed and acknowledging receipt.

Trigger: Message Received — RC

ID	Priority	Requirement	Related
RMB-06-001	SHOULD	A Participant in an active RM state (q^rm ∈ {R,I,V,D,A}) receiving RC SHOULD update their record of the sender's RM state to Closed. RC announces that the sender has completed their work on the report. Maintaining this record supports shared situation awareness and potential auto-close evaluation. ECA Details Preconditions - Participant is in an active RM state (Received/Invalid/Valid/Deferred/Accepted) - RM state: RECEIVED, INVALID, VALID, DEFERRED, ACCEPTED Steps 1. [receiver] Update local model of sender RM state to CLOSED → Sender RM state recorded as CLOSED in receiver's model Postconditions - Receiver RM state unchanged; sender's recorded RM state is CLOSED	Satisfies: VP-02-019 — Shared awareness of sender RM state change Satisfies: MSM-01-006 — RC shorthand wire-type mapping
RMB-06-002	MAY	After receiving RC from all other active Participants, a Participant MAY evaluate whether local closure criteria are satisfied and, if so, initiate closure of their own RM state. When all other parties have closed, remaining open is often unnecessary. This auto-close judgment is based on local policy and current EM state. ECA Details Preconditions - Participant is in RM Received/Invalid/Deferred/Accepted - RM state: RECEIVED, INVALID, DEFERRED, ACCEPTED	Satisfies: VP-02-035 — Participants MAY close Accepted, Deferred, or Invalid reports Satisfies: MSM-01-006 — RC shorthand wire-type mapping
RMB-06-003	SHOULD	A Participant in RM Start (q^rm ∈ S) receiving RC SHOULD respond with RE and GI to signal the error and inquire what the sender expected. Receiving any R message other than RS while in RM Start is an error condition. ECA Details Preconditions - Participant is in RM Start - RM state: START Steps 1. [receiver] Emit RE to signal the unexpected message error → RE queued for sender 2. [receiver] Emit GI to inquire what the sender expected → GI queued for sender Postconditions* - RE and GI emitted; receiver RM state unchanged (START)	Satisfies: VP-03-010 — RE+GI when R (other than RS) received while in RM Start Satisfies*: MSM-01-006 — RC shorthand wire-type mapping

Receive RE (Report Error)

Behaviors triggered when a participant receives an RE (Report Management Error) signal, which has no dedicated semantic dispatch value and is handled outside the standard AS2 pattern-matching pipeline.

Trigger: Message Received — RE

ID	Priority	Requirement	Related
RMB-07-001	SHOULD	A Participant in an active RM state (q^rm ∈ {R,I,V,D,A}) receiving RE SHOULD emit GI (to inquire about the nature of the error). RE indicates the sender encountered an error related to the report. GI opens a dialogue to resolve the problem. No RK is sent: RK acknowledges only a report submission and never goes to the CASE_MANAGER (RMB-08-003). ECA Details Preconditions - Participant is in an active RM state (Received/Invalid/Valid/Deferred/Accepted) - RM state: RECEIVED, INVALID, VALID, DEFERRED, ACCEPTED Steps 1. [receiver] Emit GI to inquire about the nature of the error → GI queued for sender Postconditions - GI emitted; receiver RM state unchanged	Satisfies: VP-03-011 — Inquire about the error with GI; RK is not sent (RMB-08-003) Satisfies: MSM-01-007 — RE shorthand wire-type mapping
RMB-07-002	SHOULD	A Participant in RM Start (q^rm ∈ S) receiving RE SHOULD respond with RE (to signal the unexpected message) and GI (to inquire what the sender expected). Receiving any R message while in RM Start means the sender has a stale or incorrect case reference. RE+GI is the protocol-specified error response. Even RE itself, when received in START, signals a coordination mismatch that requires the RE+GI error response per VP-03-010. ECA Details Preconditions - Participant is in RM Start - RM state: START Steps 1. [receiver] Emit RE to signal the unexpected message error → RE queued for sender 2. [receiver] Emit GI to inquire what the sender expected → GI queued for sender Postconditions* - RE and GI emitted; receiver RM state unchanged (START)	Satisfies: VP-03-010 — RE+GI when R (other than RS) received while in RM Start Satisfies*: MSM-01-007 — RE shorthand wire-type mapping

Receive RK (Report Acknowledgment)

Behaviors triggered when a participant receives an RK (Report Management Acknowledgment) message confirming receipt of a prior RM message.

Trigger: Message Received — RK

ID	Priority	Requirement	Related
RMB-08-001	MAY	A Participant in an active RM state (q^rm ∈ {R,I,V,D,A}) receiving RK MAY take no further action; RK is an acknowledgment and requires no response. RK closes the acknowledgment loop. Emitting RK in response to RK would create an infinite acknowledgment chain. The protocol specifies no mandatory response to RK from an active-state receiver. ECA Details Preconditions - Participant is in an active RM state (Received/Invalid/Valid/Deferred/Accepted) - RM state: RECEIVED, INVALID, VALID, DEFERRED, ACCEPTED	Satisfies: VP-03-009 — RK itself is never acknowledged with another RK Satisfies: MSM-01-008 — RK shorthand wire-type mapping
RMB-08-002	SHOULD	A Participant in RM Start (q^rm ∈ S) receiving RK SHOULD answer it with Create(ProcessingFault) (ASK-07-001). The fault tells the sender that the receiver holds no report the RK could be about. RE has no wire activity of its own (MSM-05-001). RK arriving in START means the sender believes the receiver has already acknowledged a message the receiver has never seen. A processing fault is the protocol's error response for any R message received while in RM Start per VP-03-010. ECA Details Preconditions - Participant is in RM Start - RM state: START Steps 1. [receiver] Emit Create(ProcessingFault) to signal the unexpected message → ProcessingFault queued for sender; no RE message exists Postconditions* - ProcessingFault emitted; no RK in reply to RK (RMB-08-001); receiver RM state unchanged (START)	Satisfies: VP-03-010 — Processing fault when R received while in RM Start Satisfies*: MSM-01-008 — RK shorthand wire-type mapping
RMB-08-003	MUST	An actor that an Offer(VulnerabilityReport) was addressed to MUST send the RK that acknowledges it to the reporter, the Offer's actor. It may send the RK at any time after it receives the report, whether or not a case exists for it. The reporter checks who may acknowledge its Offer against its own record of that Offer (RMB-08-004). The store of each addressee also holds a record. RK answers the reporter's Offer and is outside the case, so it is the stated exception to PCR-08-001. ECA Details Steps 1. [receiver of the report] Emit RK addressed to the Offer's actor → RK queued for the reporter only Postconditions - The reporter holds the RK	Refines: VP-03-009 — RK acknowledging RS Refines: RMB-01-001 — who sends the RK acknowledging RS, and to whom Refines: PCR-08-001 — the stated RK exception to CASE_MANAGER-only addressing
RMB-08-005	MUST NOT	An actor MUST NOT send an RK that acknowledges a report submission to the CASE_MANAGER. The CASE_MANAGER has no record of the addressees of the Offer, so it cannot check an RK that it receives (RMB-08-004). An RK sent to it can also reach parties that did not receive the report. ECA Details Postconditions - The CASE_MANAGER received no RK	Extends: RMB-08-003
RMB-08-006	MUST NOT	A receiver of an RK that acknowledges a report submission MUST NOT forward it. RK answers the reporter's Offer outside the case. A forwarded RK can reach parties that did not receive the report. ECA Details Steps 1. [any receiver of RK] Record the RK at intake → No RK forwarded	Extends: RMB-08-003
RMB-08-007	MUST NOT	An actor MUST NOT write a case ledger entry for an RK that acknowledges a report submission. RK is outside the case, so it is not a case event. A ledgered RK would also replicate to parties that did not receive the report. ECA Details Steps 1. [any receiver of RK] Record the RK at intake → No ledger entry written	Extends: RMB-08-003
RMB-08-004	MUST	A receiver MUST refuse an RK for a report submission (RMB-08-003, HP-01-006) unless its own record of the Offer names the sender as an addressee. The Offer is the Offer(VulnerabilityReport) that the RK acknowledges. The reporter sent the Offer, so only its record of the to of the Offer tells correctly who received it. The sender of the RK wrote the copy in the RK, and that copy can name any actor. If the reporter accepts an RK on the word of its sender, any actor can claim that it has the report. A receiver with no record of the Offer cannot find the sender in it, so it refuses too. ECA Details Steps 1. [reporter] Check the RK sender against its recorded Offer's addressees → Admitted when the sender is an addressee; REFUSED otherwise	Refines: HP-01-006 — the RK sender clause
RMB-08-008	MUST	A receiver that refuses an RK (RMB-08-004) MUST write nothing past intake and send nothing for it. A refused RK makes no claim the receiver accepts, so any write past intake or any message would act on a claim it refused. ECA Details Postconditions - A refused RK leaves only its intake record	Extends: RMB-08-004

Enter RM Received

Trigger: State Entered — RM.RECEIVED

ID	Priority	Requirement	Related
RMB-09-001	SHOULD	A Participant entering RM Received SHOULD initiate a report validation process to determine whether the report is Valid or Invalid. A Participant that joined a case through an Invite validates the case instead, once it has joined, by replying to the full-case Invite (CM-11-011); an invitee that has not joined has nothing to validate. Received is the intake state that exists specifically to await validation. Failing to validate leaves the report stuck and blocks all subsequent coordination steps that depend on the validation outcome. ECA Details Preconditions - Participant is in RM Received - RM state: RECEIVED Steps 1. [participant] Initiate validation process (credibility check followed by validity check) → Validation process underway Postconditions - Validation process initiated; report will transition to VALID or INVALID on completion	Satisfies: VP-02-006 — Subject each Received report to a validation process Satisfies: VP-02-007 — Have a clearly defined process for validating Received reports Satisfies: VP-02-009 — Proceed only after validating received reports
RMB-09-002	MAY	A Participant entering RM Received MAY temporarily hold the report pending additional information if the initial validation cannot be completed with available data. Reports may arrive with insufficient detail for immediate validation. Holding in Received preserves the option to revalidate when the Reporter provides more information. ECA Details Preconditions - Participant is in RM Received - RM state: RECEIVED	Satisfies: VP-02-012 — MAY temporarily hold reports pending additional information Satisfies: VP-02-013 — SHOULD give Reporters an opportunity to update with additional info

Enter RM Valid

Trigger: State Entered — RM.VALID

ID	Priority	Requirement	Related
RMB-10-001	MUST	A Participant entering RM Valid MUST initiate a prioritization evaluation to determine whether to Accept or Defer the report. VP-02-002 requires that Participants prioritize Valid cases. Entering Valid without initiating prioritization blocks progression and violates the requirement. ECA Details Preconditions - Participant is in RM Valid - RM state: VALID Steps 1. [participant] Initiate prioritization evaluation (e.g., SSVC scoring) → Prioritization process started; outcome is ACCEPTED or DEFERRED Postconditions - Prioritization underway; report will transition to ACCEPTED or DEFERRED	Satisfies: VP-02-002 — Participants MUST prioritize Valid cases Satisfies: VP-02-014 — SHOULD perform a prioritization evaluation for Valid reports
RMB-10-002	MUST NOT	A Participant in RM Valid MUST NOT close the report directly from the Valid state (q^rm V → C) without first transitioning through Accepted or Deferred (constraint C-03). Closing directly from Valid skips the mandatory prioritization step. Reports with no further action should be Deferred first and then Closed, preserving the prioritization record. ECA Details Preconditions - Participant is in RM Valid - RM state: VALID	Satisfies: VP-02-004 — Participants MUST NOT close cases from the Valid state
RMB-10-003	SHOULD	A Participant entering RM Valid SHOULD emit RV to announce the validation result to other Participants. State-change notifications support shared situation awareness. Other Participants tracking this report depend on RV to update their model of the sender's RM state. ECA Details Preconditions - Participant is in RM Valid - RM state: VALID Steps 1. [participant] Emit RV to announce RM Valid transition → RV queued for case participants Postconditions - RV emitted; other Participants informed of Valid transition	Satisfies: VP-03-004 — SHOULD send RV when validation ends in valid determination Satisfies: VP-03-012 — SHOULD send a message for each RM state transition
RMB-10-004	SHOULD	A Participant entering RM Valid SHOULD create or update a case object to track the report's progress through the CVD process. Valid reports represent confirmed vulnerability coordination work. A case object enables participant management, embargo coordination, and state tracking across all involved parties. ECA Details Preconditions - Participant is in RM Valid - RM state: VALID	Satisfies: VP-02-015 — SHOULD create a case for reports entering the Valid state Satisfies: VP-02-020 — SHOULD create a case for all Valid reports

Enter RM Invalid

Trigger: State Entered — RM.INVALID

ID	Priority	Requirement	Related
RMB-11-001	SHOULD	A Participant entering RM Invalid SHOULD emit RI to announce the invalid determination to other Participants. State-change notifications support shared situation awareness. Other Participants tracking this report depend on RI to update their model of the sender's validation outcome. ECA Details Preconditions - Participant is in RM Invalid - RM state: INVALID Steps 1. [participant] Emit RI to announce RM Invalid transition → RI queued for case participants Postconditions - RI emitted; other Participants informed of Invalid transition	Satisfies: VP-03-003 — SHOULD send RI when validation ends in invalid determination Satisfies: VP-03-012 — SHOULD send a message for each RM state transition
RMB-11-002	SHOULD NOT	Participants SHOULD NOT mark duplicate reports as Invalid. A duplicate report is not invalid — it describes a real vulnerability already tracked in an existing case. Marking it Invalid misrepresents the validation outcome and may confuse other Participants. ECA Details Preconditions - Participant is in RM Invalid - RM state: INVALID	Satisfies: VP-02-022 — Participants SHOULD NOT mark duplicate reports as Invalid Satisfies: VP-02-023 — Duplicate reports SHOULD pass through Valid state
RMB-11-003	MAY	A Participant in RM Invalid MAY revalidate the report when new information becomes available, transitioning back through the validation process toward RM Valid. Invalid reports may become valid if additional information is provided by the Reporter or discovered independently. Revalidation preserves coordination options without requiring a new RS. ECA Details Preconditions - Participant is in RM Invalid - RM state: INVALID	Satisfies: VP-02-033 — MAY periodically revalidate Invalid reports Satisfies: VP-02-013 — SHOULD give Reporters an opportunity to update with additional info
RMB-11-004	MAY	A Participant in RM Invalid MAY close the report if no further action is expected and no active embargo is in force (q^em ∉ {A,R}). Invalid reports with no prospect of revalidation should eventually be closed. Active embargo constraints on closure still apply. ECA Details Preconditions - Participant is in RM Invalid - RM state: INVALID	Satisfies: VP-02-035 — Participants MAY close Invalid reports Satisfies: VP-13-005 — SHOULD NOT close while an active embargo is in force

Enter RM Deferred

Trigger: State Entered — RM.DEFERRED

ID	Priority	Requirement	Related
RMB-12-001	SHOULD	A Participant entering RM Deferred SHOULD emit RD to announce the deferral decision to other Participants. State-change notifications support shared situation awareness. Other Participants depend on RD to update their model of the sender's prioritization decision and to calibrate their own coordination plans. ECA Details Preconditions - Participant is in RM Deferred - RM state: DEFERRED Steps 1. [participant] Emit RD to announce RM Deferred transition → RD queued for case participants Postconditions - RD emitted; other Participants informed of Deferred transition	Satisfies: VP-03-005 — SHOULD send RD when prioritization ends in deferred decision Satisfies: VP-03-012 — SHOULD send a message for each RM state transition Satisfies: VP-02-024 — Vendors SHOULD communicate prioritization choices including deferral
RMB-12-002	SHOULD	A Participant in RM Deferred SHOULD monitor for new information (updated threat intelligence, exploitation activity, or vendor progress) that could justify reprioritization toward Accepted. Deferred does not mean permanently shelved. Changed conditions may restore the urgency needed to resume active work on the report. ECA Details Preconditions - Participant is in RM Deferred - RM state: DEFERRED	Satisfies: VP-02-017 — Reports SHOULD exit Deferred when work resumes or no further action planned
RMB-12-003	MAY	A Participant in RM Deferred MAY set a policy timer to automatically move the report to Closed after a defined period of inactivity. Indefinitely deferred reports accumulate as open coordination debt. A timer enforces eventual cleanup consistent with local policy without requiring manual review of every dormant case. ECA Details Preconditions - Participant is in RM Deferred - RM state: DEFERRED	Satisfies: VP-02-031 — MAY set a policy timer on Deferred reports

Enter RM Accepted

Trigger: State Entered — RM.ACCEPTED

ID	Priority	Requirement	Related
RMB-13-001	MUST	A Participant MUST be in RM Accepted (q^rm ∈ A) before sending RS to another Participant to initiate CVD coordination (constraint C-04). Sending RS from any other RM state is prohibited. Sending RS from a non-Accepted state would initiate coordination before the sender has committed to working the report. Accepted represents the sender's confirmed engagement and readiness to coordinate. ECA Details Preconditions - Participant is in RM Accepted - RM state: ACCEPTED	Satisfies: VP-03-001 — MUST be in RM Accepted to send RS Satisfies: VP-02-003 — Participants initiating CVD with others MUST do so from Accepted state
RMB-13-002	SHOULD	A Participant entering RM Accepted SHOULD emit RA to announce the accept decision to other Participants. State-change notifications support shared situation awareness. Other Participants depend on RA to know that the sender has committed to active work and may soon send RS to initiate coordination. ECA Details Preconditions - Participant is in RM Accepted - RM state: ACCEPTED Steps 1. [participant] Emit RA to announce RM Accepted transition → RA queued for case participants Postconditions - RA emitted; other Participants informed of Accepted transition	Satisfies: VP-03-006 — SHOULD send RA when prioritization ends in accept decision Satisfies: VP-03-012 — SHOULD send a message for each RM state transition Satisfies: VP-02-024 — Vendors SHOULD communicate prioritization choices including acceptance
RMB-13-003	SHOULD	A Participant in RM Accepted SHOULD perform active work on the report (e.g., fix development, remediation guidance, coordination with other Participants via RS). Accepted is the active engagement state. Entering Accepted without performing work reduces coordination effectiveness and may violate implicitly agreed timelines within an active embargo. ECA Details Preconditions - Participant is in RM Accepted - RM state: ACCEPTED	Satisfies: VP-02-002 — Participants MUST prioritize Valid cases; Accepted is the result of prioritization

Enter RM Closed

Trigger: State Entered — RM.CLOSED

ID	Priority	Requirement	Related
RMB-14-001	SHOULD	A Participant entering RM Closed SHOULD emit RC to announce the closure to other Participants. State-change notifications support shared situation awareness. Other Participants depend on RC to know the sender has completed their work and to evaluate whether to initiate their own closure. ECA Details Preconditions - Participant is in RM Closed - RM state: CLOSED Steps 1. [participant] Emit RC to announce RM Closed transition → RC queued for case participants Postconditions - RC emitted; other Participants informed of Closed transition	Satisfies: VP-03-007 — SHOULD send RC when report is closed Satisfies: VP-03-012 — SHOULD send a message for each RM state transition
RMB-14-002	MAY	A Participant in RM Closed (q^rm ∈ C) MAY ignore further R messages received on the closed report without sending a response. Non-R traffic (EM, CS, GI) on a closed case is covered by VP-03-013, and the CASE_MANAGER's kill switch once the case is fully closed by CM-23-013. Closed is a terminal state. A response to more R messages creates work for a report that is complete. The limit for the CASE_MANAGER is wider: after the Case Owner closes the case, it records no message of any class (CM-23-013, ADR-0085). Thus this rule controls only what a closed participant does with the R messages that it continues to receive. ECA Details Preconditions - Participant is in RM Closed - RM state: CLOSED	Satisfies: VP-03-013 — Recipients MAY ignore messages received on Closed cases
RMB-14-003	SHOULD NOT	A Participant SHOULD NOT close a report (q^rm ∈ {R,I,D,A} → C) while an active embargo is in force (q^em ∈ {A,R}) unless they first communicate their closure intent, and whether their Embargo Consent continues, to other Participants. Closing while an embargo is active may signal withdrawal from the coordinated timeline without proper notification, potentially undermining the agreed disclosure date for all parties. ECA Details Preconditions - Participant is in RM Received/Invalid/Deferred/Accepted; EM state is Active or Revise - RM state: RECEIVED, INVALID, DEFERRED, ACCEPTED - EM state: ACTIVE, REVISE	Satisfies: VP-13-005 — SHOULD NOT close while an active embargo is in force Satisfies: VP-13-007 — SHOULD communicate intent to adhere or terminate compliance when closing during an active embargo
RMB-14-004	MUST	The RM transition function MUST permit closing from Received (q^rm R → C), as well as I → C, A → C and D → C. A Reject sent from RM Received, of a report Offer, a stub Invite (CM-11-007) or a full-case Invite (CM-11-011), is the R → C transition. Reject means close and TentativeReject means invalid, so a hard no from Received needs its own edge rather than a bypass of the transition table.
RMB-14-008	MUST NOT	The RM transition function MUST NOT permit closing from Valid (VP-02-004). Valid keeps no close edge: a participant that found a report valid decides to engage or defer before it leaves (ADR-0114).	Refines: VP-02-004
RMB-14-005	MUST	Every RM closure MUST be written as transitions the RM transition function permits, with no closure path that overrides the transition table. An override that skips the RM transition table lets a closure write a state that no permitted sequence reaches. The write-boundary check (RMB-15-001) and every replica then disagree with that state. R to C is in the table (RMB-14-004), and Valid goes through Deferred (RMB-14-009). Thus every closure is an ordinary transition, and no closure path needs the override (ADR-0114).
RMB-14-009	MUST	An actor MUST record a participant at RM Valid that leaves the case (Leave(VulnerabilityCase), CM-23-012) as V → D → C. V → C is not in the RM transition table (RMB-14-008), so a closure from Valid that keeps to the table (RMB-14-005) goes through Deferred.	Refines: RMB-14-005
RMB-14-006	MUST NOT	The RM state machine MUST NOT define any transition out of RM.CLOSED to a different RM state. RM.CLOSED is terminal: once a participant's RM state reaches CLOSED, no further RM progression is possible for that participant on that case. RM.CLOSED being terminal is what gives the closure act finality. A participant that anticipates returning to the case SHOULD instead move to RM.DEFERRED (resumable via DEFERRED → ACCEPTED) rather than close; once closed, the participant has no path back in, because a re-invite to a participant at RM.CLOSED is refused (CM-11-043, ADR-0085). Rejoin mechanics are deferred to a future design; the interim workaround is defer-not-close (RMB-14-007).
RMB-14-007	SHOULD	A participant that anticipates returning to active coordination on a case SHOULD move to RM.DEFERRED (the resumable parking state) rather than RM.CLOSED. RM.DEFERRED supports both DEFERRED → ACCEPTED (resume) and DEFERRED → CLOSED (abandon) transitions; RM.CLOSED supports neither. Because RM.CLOSED is terminal (RMB-14-006), a participant that closes and later wants back in has no protocol path. RM.DEFERRED preserves optionality: the participant can accept the case later or close it once it confirms there is nothing more to do (ADR-0085). Full rejoin mechanics (reactivation via re-invitation, multiple lifecycle arcs per actor) are deferred to a future design Idea.

Embargo Management Behavioral Requirements

Event-Condition-Action behavioral requirements for Embargo Management (EM). Each group is triggered by either a received EM message or a local EM state transition, and specifies typed preconditions, ordered steps, and postconditions that implementations must satisfy.

Receive EP (Embargo Proposed)

Behaviors triggered when a participant receives an EP (Embargo Proposed) message, transitioning EM state to Proposed and acknowledging receipt. Written in the voice of the formal protocol, in which every Participant is a peer. In the CASE_MANAGER topology (PCR-08-001) a participant addresses its proposal to the CASE_MANAGER alone, so the Participant receiving EP is the CASE_MANAGER on receipt; every other participant reaches the same EM state through ledger replay, and is asked for its answer by the Invite the CASE_MANAGER relays to it. "Emit EK" is discharged by the CASE_MANAGER's commit and announcement of the received activity; no EK message exists (EP-09-009). See EP-09 and ADR-0113 as amended.

Trigger: Message Received — EP

ID	Priority	Requirement	Related
EMB-01-001	MUST	A Participant in EM None (q^em ∈ N) with CS not yet public/exploit/attack (q^cs ∈ ···pxa) receiving EP MUST transition their EM state to Proposed (q^em N → P). "Emit EK" is discharged by the CASE_MANAGER's commit of the received activity, fanned out as Announce(CaseLedgerEntry); no EK message is emitted (EP-09-009). EP is the EM message that initiates embargo negotiation. When no embargo exists and the case is still pre-public, the receiver transitions to Proposed to signal they are evaluating the proposal. ECA Details Preconditions - EM state is None; CS matches pattern ...pxa - EM state: NONE - CS pattern: ...pxa Steps 1. [receiver] Transition EM state from NONE to PROPOSED → Receiver EM state is PROPOSED 2. [receiver] CASE_MANAGER commits the received EP and announces the ledger entry (discharges EK) → Ledger entry committed and fanned out; no EK message exists Postconditions - Receiver EM state is PROPOSED; EK discharged by the ledger commit	Satisfies: VP-11-004 — VP-11-004's EK is the CASE_MANAGER's ledger commit (EP-09-009) Satisfies: MSM-02-001 — EP shorthand wire-type mapping
EMB-01-002	MUST	The case is at P/X/A when the vulnerability is public (q^cs ∈ ···P··), an exploit is public (q^cs ∈ ····X·), or attacks are observed (q^cs ∈ ·····A). A Participant that receives a new embargo proposal (EP) at P/X/A MUST answer the Invite with its own Reject(Invite(EmbargoEvent)) instead of accepting it. The refusal binds only the proposal's addressee. A receiver the proposal is not addressed to (HP-01-012) holds an unaddressed copy, refuses it (HP-01-005) and answers nothing (ADR-0118); cc addresses nobody (ADR-0109). The Reject names the Invite by id and carries no terms. An Invite that names its terms by URI only is classified as an embargo Invite only once the receiver holds the terms (SE-01-006). Its Reject follows the fetch of those terms (AKM-05-007), and none is sent when the fetch fails (AKM-05-015). A re-delivery of an Invite already answered with a Reject is a duplicate, and gets no second Reject (HP-01-003). Embargo negotiation is not viable once public disclosure has occurred. VP-06-001 prohibits new embargo negotiations in these states. The Reject of the Invite tells the proposer that the receiver refuses the terms. It is the receiver's own consent answer (MSM-07-004), not ER: ER is the Case Owner's decision for the case, or the CASE_MANAGER's abandonment of the proposal (MSM-02-006, MSM-02-010). A bare object URI matches no pattern's object type, so a receiver that lacks the terms cannot tell an embargo Invite from an actor Invite until it fetches them (#5266). ECA Details Preconditions - CS matches pattern ...P.. - CS pattern: ...P.. - CS matches pattern ....X. - CS pattern: ....X. - CS matches pattern .....A - CS pattern: .....A Steps 1. [receiver] Emit a Reject of the Invite to refuse the embargo proposal → Reject(Invite(EmbargoEvent)) queued for the sender; the receiver's EM state does not move to PROPOSED Postconditions - Reject(Invite(EmbargoEvent)) emitted; no EM state transition to PROPOSED	Satisfies: VP-06-001 — MUST NOT propose or accept embargo when public/exploit/attacks Satisfies: MSM-02-001 — EP shorthand wire-type mapping
EMB-01-003	MUST	A Participant already in EM Proposed (q^em ∈ P) with CS not yet public/exploit/attack (q^cs ∈ ···pxa) receiving a second or counter EP MUST stay in Proposed with no additional state transition. "Emit EK" is discharged by the CASE_MANAGER's commit of the received activity, fanned out as Announce(CaseLedgerEntry); no EK message is emitted (EP-09-009, MSM-02-009). Multiple EP messages can arrive during negotiation. When already in Proposed, no additional state transition is needed. The receiver evaluates the counter-proposal: it may answer the Invite with an Accept or a Reject of it, or counter, and the Case Owner decides the proposal for the case with EA or ER. ECA Details Preconditions - EM state is Proposed; CS matches pattern ...pxa - EM state: PROPOSED - CS pattern: ...pxa Steps 1. [receiver] CASE_MANAGER commits the counter EP and announces the ledger entry (discharges EK) → Ledger entry committed and fanned out; no EK message exists; EM state remains PROPOSED Postconditions - EM state remains PROPOSED; counter-proposal terms available for evaluation; EK discharged by the ledger commit	Satisfies: VP-11-004 — SHOULD send EK in acknowledgment of any E message except EK itself Satisfies*: MSM-02-001 — EP shorthand wire-type mapping
EMB-01-004	SHOULD NOT	A Participant in RM Invalid (q^rm ∈ I) SHOULD NOT propose or accept an embargo when receiving EP. VP-13-003 discourages starting embargo management from an Invalid RM state. The report has been assessed as invalid; committing to embargo terms under those conditions is premature and likely to be wasted effort. ECA Details Preconditions - Participant is in RM Invalid - RM state: INVALID	Satisfies: VP-13-003 — SHOULD NOT begin EM with a proposal from a Participant in RM Invalid Satisfies: MSM-02-001 — EP shorthand wire-type mapping
EMB-01-005	SHOULD NOT	A Participant in an inactive RM state (q^rm ∈ {D, C}) SHOULD NOT begin embargo management by accepting an incoming EP. VP-13-002 discourages starting embargo management in inactive RM states. Deferred or Closed cases indicate the participant has deprioritized or completed their engagement; starting embargo negotiation in these states is unlikely to lead to productive coordinated disclosure. ECA Details Preconditions - Participant is in RM Deferred/Closed - RM state: DEFERRED, CLOSED	Satisfies: VP-13-002 — SHOULD NOT begin EM in an inactive RM state Satisfies: MSM-02-001 — EP shorthand wire-type mapping

Receive EA (Embargo Accepted)

Behaviors triggered when a participant receives an EA (Embargo Accepted) message, transitioning EM state to Active and acknowledging receipt.

Trigger: Message Received — EA

ID	Priority	Requirement	Related
EMB-02-001	MUST	A Participant in EM Proposed (q^em ∈ P) with CS not yet public/exploit/attack (q^cs ∈ ···pxa) receiving EA MUST move their EM state along the accept transition of EMB-18-005: to Active (q^em P → A) when the accepted proposal was the last one open, and to Revise (q^em P → R) while another proposal stays open. "Emit EK" is discharged by the CASE_MANAGER's commit of the received activity, fanned out as Announce(CaseLedgerEntry); no EK message is emitted (EP-09-009, MSM-02-009). Every participant must agree on whether an embargo is in force. If the receiver kept EM at Proposed after the EA, it would act as if no embargo binds the case, and it could disclose while the other participants keep the vulnerability private. Another open proposal stays open as a revision of the embargo now in force, because the consent already given to its terms stays valid (ADR-0130). Revise records both facts. The ledger commit of the EA acknowledges it. ECA Details Preconditions - EM state is Proposed; CS matches pattern ...pxa - EM state: PROPOSED - CS pattern: ...pxa Steps 1. [receiver] Transition EM state from PROPOSED to ACTIVE → Receiver EM state is ACTIVE 2. [receiver] CASE_MANAGER commits the received EA and announces the ledger entry (discharges EK) → Ledger entry committed and fanned out; no EK message exists Postconditions - Receiver EM state is ACTIVE, or REVISE while another proposal is open; EK discharged by the ledger commit	Satisfies: VP-05-003 — An embargo SHALL begin at the moment it is accepted Satisfies: VP-11-004 — SHOULD send EK in acknowledgment of any E message except EK itself Satisfies*: MSM-02-002 — EA shorthand wire-type mapping
EMB-02-002	MUST NOT	A Participant MUST NOT apply EA's transition to Active when the case is at P/X/A (q^cs ∉ ···pxa). EA is the Case Owner's Accept(EmbargoEvent)[target=VulnerabilityCase] (MSM-07-008). The CASE_MANAGER refuses that activation before committing it to the case ledger, and sends no Reject of the Invite for it. VP-06-001 prohibits accepting embargoes once public disclosure has occurred. EA is the Case Owner's decision (MSM-02-002), so the refusal falls on it. A Reject of the Invite that the CASE_MANAGER commits reads as its abandonment of the proposal (MSM-07-016, ADR-0152), so the activation is refused instead. The Reject of EMB-02-004 differs: it is a direct answer, never committed. VP-13-004 only discourages Active when RM is Invalid or Closed; this bar is absolute. ECA Details Preconditions - CS matches pattern ...P.. - CS pattern: ...P.. - CS matches pattern ....X. - CS pattern: ....X. - CS matches pattern .....A - CS pattern: .....A Steps 1. [CASE_MANAGER] Refuse the Case Owner's activation before committing it (embargo not viable) → Nothing is committed; EM state is not transitioned to ACTIVE Postconditions - Activation refused; EM state not transitioned to ACTIVE	Satisfies: VP-06-001 — MUST NOT accept a new embargo when public/exploit/attacks Satisfies: MSM-02-002 — EA shorthand wire-type mapping
EMB-02-003	SHOULD NOT	A Participant in RM Invalid or Closed (q^rm ∈ {I, C}) SHOULD NOT allow EM to proceed from Proposed to Active upon receiving EA. VP-13-004 discourages proceeding to Active when the report has been assessed as invalid or closed. The embargo would apply to a case the participant is not actively working. ECA Details Preconditions - Participant is in RM Invalid/Closed - RM state: INVALID, CLOSED	Satisfies: VP-13-004 — SHOULD NOT proceed from EM Proposed to EM Accepted when RM is Invalid or Closed Satisfies: MSM-02-002 — EA shorthand wire-type mapping
EMB-02-004	MUST	The case may be at P/X/A (q^cs ∉ ···pxa) when a Participant's Accept(Invite(EmbargoEvent)) reaches the CASE_MANAGER. The CASE_MANAGER MUST then refuse the Accept by answering that Participant with a Reject of the Invite. An Accept of the Invite is the Participant's own consent, not EA (MSM-02-010), so EMB-02-002 does not cover it. VP-06-001 prohibits accepting embargoes once public disclosure has occurred, so consent to the proposed terms cannot be recorded. The Reject of the Invite tells the Participant that its answer was refused, as EMB-01-002 does for a proposal. It is a direct answer addressed to that Participant and is never committed to the ledger, so no replica reads it as the abandonment of MSM-07-016. It sits beside EMB-02-002 because both refuse an acceptance on a public case. ECA Details Preconditions - CS matches pattern ...P.. - CS pattern: ...P.. - CS matches pattern ....X. - CS pattern: ....X. - CS matches pattern .....A - CS pattern: .....A Steps 1. [CASE_MANAGER] Emit a Reject of the Invite to refuse the acceptance (embargo not viable) → Reject(Invite(EmbargoEvent)) queued for the accepting Participant; its consent is not recorded Postconditions - Reject(Invite(EmbargoEvent)) emitted; the Participant's acceptance is not recorded	Satisfies: VP-06-001 — MUST NOT accept a new embargo when public/exploit/attacks

Receive EV (Embargo Revision Proposed)

Behaviors triggered when a participant receives an EV (Embargo Revision Proposed) message while an embargo is active, transitioning EM state to Revise and acknowledging receipt. Written in the voice of the formal protocol, in which every Participant is a peer. In the CASE_MANAGER topology (PCR-08-001) a participant addresses its proposal to the CASE_MANAGER alone, so the Participant receiving EV is the CASE_MANAGER on receipt; every other participant reaches the same EM state through ledger replay, and is asked for its answer by the Invite the CASE_MANAGER relays to it. "Emit EK" is discharged by the CASE_MANAGER's commit and announcement of the received activity; no EK message exists (EP-09-009). See EP-09 and ADR-0113.

Trigger: Message Received — EV

ID	Priority	Requirement	Related
EMB-03-001	MUST	A Participant in EM Active (q^em ∈ A) with CS not yet public/exploit/attack (q^cs ∈ ···pxa) receiving EV MUST transition their EM state to Revise (q^em A → R). "Emit EK" is discharged by the CASE_MANAGER's commit of the received activity, fanned out as Announce(CaseLedgerEntry); no EK message is emitted (EP-09-009, MSM-02-009). A participant must know that a change to the embargo is open while the current terms still bind it. Revise records both facts: an embargo is in force, and a revision of it waits for an answer. If the receiver stayed in Active, it could not tell that a later EC or EJ decides a revision. The revision does not change any participant's consent to the embargo in force until the Case Owner activates it (EP-05-002). ECA Details Preconditions - EM state is Active; CS matches pattern ...pxa - EM state: ACTIVE - CS pattern: ...pxa Steps 1. [receiver] Transition EM state from ACTIVE to REVISE → Receiver EM state is REVISE 2. [receiver] CASE_MANAGER commits the received EV and announces the ledger entry (discharges EK) → Ledger entry committed and fanned out; no EK message exists Postconditions - Receiver EM state is REVISE; original embargo remains in force; EK discharged by the ledger commit	Satisfies: VP-04-005 — Once accepted, revisions MAY be proposed Satisfies: VP-11-004 — VP-11-004's EK is the CASE_MANAGER's ledger commit (EP-09-009) Satisfies: MSM-02-003 — EV shorthand wire-type mapping
EMB-03-002	MUST	A Participant already in EM Revise (q^em ∈ R) with CS not yet public/exploit/attack (q^cs ∈ ···pxa) receiving a counter EV (counter-revision) MUST stay in Revise with no additional state transition. "Emit EK" is discharged by the CASE_MANAGER's commit of the received activity, fanned out as Announce(CaseLedgerEntry); no EK message is emitted (EP-09-009, MSM-02-009). Multiple revision proposals can arrive. When already in Revise, no further state transition is needed; the receiver evaluates the counter-revision and answers its Invite with an Accept or a Reject of it, and the Case Owner decides the revision for the case with EC or EJ. ECA Details Preconditions - EM state is Revise; CS matches pattern ...pxa - EM state: REVISE - CS pattern: ...pxa Steps 1. [receiver] CASE_MANAGER commits the counter EV and announces the ledger entry (discharges EK) → Ledger entry committed and fanned out; no EK message exists; EM state remains REVISE Postconditions - EM state remains REVISE; EK discharged by the ledger commit	Satisfies: VP-11-004 — SHOULD send EK in acknowledgment of any E message except EK itself Satisfies*: MSM-02-003 — EV shorthand wire-type mapping
EMB-03-003	MUST NOT	This rule binds a Participant that is neither Case Owner nor CASE_MANAGER. Its EM is Active or Revise (q^em ∈ {A, R}) and the case is at P/X/A (q^cs ∉ ···pxa). That Participant, receiving EV, MUST NOT adopt the proposal, emit ET or change its own EM state. Only the Case Owner, or the CASE_MANAGER when delegated, initiates termination (EP-09-003, EP-09-008, CM-24, ADR-0113, ADR-0118). The public, exploit or attack fact causes it, never a revision proposal. A proposal is at most the occasion on which a participant notices the case is public; making it the cause would tie termination to someone proposing terms. Ending the embargo is the Case Owner's decision, and only the CASE_MANAGER writes shared EM state (EP-09-008, ADR-0113). VP-06-001 and VP-09-001 are met by the owner's or CASE_MANAGER's termination (VP-11-002, VP-11-011), which in the CASE_MANAGER topology is the CS public-event cascade, not by each participant emitting ET (ADR-0118). ECA Details Preconditions - EM state is Active or Revise; CS matches pattern ...P.. - EM state: ACTIVE, REVISE - CS pattern: ...P.. - EM state is Active or Revise; CS matches pattern ....X. - EM state: ACTIVE, REVISE - CS pattern: ....X. - EM state is Active or Revise; CS matches pattern .....A - EM state: ACTIVE, REVISE - CS pattern: .....A Steps 1. [receiver] Leave the revision unadopted and emit no ET → No ET is emitted; the receiver's EM state is unchanged Postconditions - No revision proposal adopted; the receiver emits no ET and its EM state is unchanged	Satisfies: VP-09-001 — Embargoes SHALL terminate immediately when public/exploit Satisfies: MSM-02-003 — EV shorthand wire-type mapping
EMB-03-004	MUST	This rule binds the Participant of EMB-03-003: neither the Case Owner nor the CASE_MANAGER, in EM Active or Revise, with the case at P/X/A. That Participant, receiving EV, MUST answer the revision Invite with its own Reject of it to the CASE_MANAGER. EMB-01-002 requires the same answer to a proposal. Revision negotiation is not viable once public disclosure has occurred, so the participant refuses the revision. A participant answers only the Invite addressed to it (EP-09-003). The Reject of the Invite is the participant's own consent answer (MSM-07-004), not ER, which is the Case Owner's decision or the CASE_MANAGER's abandonment (MSM-02-006). ECA Details Preconditions - EM state is Active or Revise; CS matches pattern ...P.. - EM state: ACTIVE, REVISE - CS pattern: ...P.. - EM state is Active or Revise; CS matches pattern ....X. - EM state: ACTIVE, REVISE - CS pattern: ....X. - EM state is Active or Revise; CS matches pattern .....A - EM state: ACTIVE, REVISE - CS pattern: .....A Steps 1. [receiver] Emit a Reject of the revision Invite to the CASE_MANAGER → Reject(Invite(EmbargoEvent)) queued for the CASE_MANAGER Postconditions - Reject(Invite(EmbargoEvent)) queued for the CASE_MANAGER	Refines: EMB-01-002 — Applies the proposal refusal to a revision Invite Satisfies: MSM-02-003 — EV shorthand wire-type mapping

Receive EJ (Embargo Revision Rejected)

Behaviors triggered when a participant receives an EJ (Embargo Revision Rejected) message, reverting EM state from Revise to Active and acknowledging receipt.

Trigger: Message Received — EJ

ID	Priority	Requirement	Related
EMB-04-001	MUST	This rule covers a Participant in EM Revise (q^em ∈ R) whose CS is not yet public/exploit/attack (q^cs ∈ ···pxa). When it receives EJ for the last open proposal, it MUST move its EM state back to Active (q^em R → A). The CASE_MANAGER's commit of the received activity, fanned out as Announce(CaseLedgerEntry), discharges "Emit EK". No EK message is emitted (EP-09-009, MSM-02-009). EJ says that a revision proposal is rejected. A rejected revision leaves the embargo in force and the consent to it unchanged (EP-05-002), so when no other proposal is open, EM returns to Active under the terms it had. The CASE_MANAGER's commit and fan-out of the received activity tell every participant of the change, so no separate EK message is necessary (ADR-0113). ECA Details Preconditions - EM state is Revise; CS matches pattern ...pxa - EM state: REVISE - CS pattern: ...pxa Steps 1. [receiver] Transition EM state from REVISE back to ACTIVE → Receiver EM state is ACTIVE 2. [receiver] CASE_MANAGER commits the received EJ and announces the ledger entry (discharges EK) → Ledger entry committed and fanned out; no EK message exists Postconditions - Receiver EM state is ACTIVE (revision rejected); EK discharged by the ledger commit	Satisfies: VP-11-004 — SHOULD send EK in acknowledgment of any E message except EK itself Satisfies*: MSM-02-004 — EJ shorthand wire-type mapping
EMB-04-003	MUST	This rule covers a Participant in EM Revise (q^em ∈ R) whose CS is not yet public/exploit/attack (q^cs ∈ ···pxa). When it receives EJ while another proposal is open, it MUST remain in Revise (q^em R → R) (EMB-18-005). While another proposal stays open, EM stays in Revise, because the register still holds an open proposal (ADR-0130). ECA Details Preconditions - EM state is Revise; CS matches pattern ...pxa; another proposal is open - EM state: REVISE - CS pattern: ...pxa Postconditions - Receiver EM state is REVISE	Refines: EMB-18-005
EMB-04-002	MUST	The CASE_MANAGER in EM Revise (q^em ∈ R) with CS in a public/exploit/attack state (q^cs ∉ ···pxa) that commits the Case Owner's EJ of the last open revision MUST emit ET in the same act to terminate the embargo, rather than reverting to Active. Reverting to Active is not viable once public disclosure has occurred. VP-09-001 requires termination in these states. "Rather than reverting" describes where the act ends: EM ends EXITED, never back in Active. Inside the act, the CASE_MANAGER records the rejection as decided (the revision REJECTED) and then terminates the embargo, as two entries a replica copies in order (MSM-07-032, CM-23-016). ECA Details Preconditions - EM state is Revise; CS matches pattern ...P.. - EM state: REVISE - CS pattern: ...P.. - EM state is Revise; CS matches pattern ....X. - EM state: REVISE - CS pattern: ....X. - EM state is Revise; CS matches pattern .....A - EM state: REVISE - CS pattern: .....A Steps 1. [CASE_MANAGER] Commit the Case Owner's EJ, then emit ET to terminate the embargo in the same act → ET queued for participants; EM transitions to EXITED Postconditions - ET emitted; EM state is EXITED	Satisfies: VP-09-001 — Embargoes SHALL terminate immediately when public/exploit Satisfies: MSM-02-004 — EJ shorthand wire-type mapping

Receive EC (Embargo Revision Accepted)

Behaviors triggered when a participant receives an EC (Embargo Revision Accepted) message, advancing EM state from Revise back to Active with updated terms and acknowledging receipt.

Trigger: Message Received — EC

ID	Priority	Requirement	Related
EMB-05-001	MUST	This rule covers a Participant in EM Revise (q^em ∈ R) whose CS is not yet public/exploit/attack (q^cs ∈ ···pxa). When it receives EC for the last open proposal, it MUST move its EM state back to Active (q^em R → A) with the revised terms. The CASE_MANAGER's commit of the Case Owner's Accept(EmbargoEvent)[target=VulnerabilityCase], fanned out as Announce(CaseLedgerEntry), discharges "Emit EK". No EK message is emitted (EP-09-009, MSM-02-009). EC says that the Case Owner accepts a revision. The revised terms replace the terms in force, so when no other proposal is open, EM returns to Active under the revised terms. The CASE_MANAGER's commit and fan-out of the owner's Accept tell every participant of the change, so no separate EK message is necessary (ADR-0113). ECA Details Preconditions - EM state is Revise; CS matches pattern ...pxa - EM state: REVISE - CS pattern: ...pxa Steps 1. [receiver] Transition EM state from REVISE to ACTIVE with revised embargo terms → Receiver EM state is ACTIVE; revised terms recorded 2. [receiver] CASE_MANAGER commits the Case Owner's Accept(EmbargoEvent)[target=VulnerabilityCase] and announces the ledger entry (discharges EK) → Ledger entry committed and fanned out; no EK message exists Postconditions - Receiver EM state is ACTIVE with new terms; EK discharged by the ledger commit	Satisfies: VP-04-006 — Once accepted, revisions MAY be accepted Satisfies: VP-11-004 — SHOULD send EK in acknowledgment of any E message except EK itself Satisfies*: MSM-02-005 — EC shorthand wire-type mapping
EMB-05-003	MUST	This rule covers a Participant in EM Revise (q^em ∈ R) whose CS is not yet public/exploit/attack (q^cs ∈ ···pxa). When it receives EC while another proposal is open, it MUST remain in Revise (q^em R → R) under the revised terms (EMB-18-005). The revised terms replace the terms in force at once. While another proposal stays open, EM stays in Revise, because the register still holds an open proposal (ADR-0130). ECA Details Preconditions - EM state is Revise; CS matches pattern ...pxa; another proposal is open - EM state: REVISE - CS pattern: ...pxa Postconditions - Receiver EM state is REVISE with the revised terms	Refines: EMB-18-005
EMB-05-002	MUST	This rule covers the CASE_MANAGER in EM Revise (q^em ∈ R) with CS in a public/exploit/attack state (q^cs ∉ ···pxa). It MUST refuse the Case Owner's EC before committing it, and emits no ET for the EC. Accepting a revision is not viable once public disclosure has occurred (VP-06-001). EC activates a revision, so it is refused as EA is (EMB-02-002), before the commit (CLP-10-009). A refusal is not an act, so it carries no ET. The P/X/A fact causes the termination, not the EC (EMB-03-003): the act that adopts P, X or A ends the embargo (RSH-03-001, ADR-0166). EJ differs (EMB-04-002): it is committed, so its act can end the embargo. ECA Details Preconditions - EM state is Revise; CS matches pattern ...P.. - EM state: REVISE - CS pattern: ...P.. - EM state is Revise; CS matches pattern ....X. - EM state: REVISE - CS pattern: ....X. - EM state is Revise; CS matches pattern .....A - EM state: REVISE - CS pattern: .....A Steps 1. [CASE_MANAGER] Refuse the Case Owner's EC before committing it → No ledger entry and no ET; EM stays Revise under the prior terms Postconditions - EC refused uncommitted; no ET emitted for it; the embargo in force is unchanged	Refines: EMB-02-002 — EC is the activation of a revision Satisfies: MSM-02-005 — EC shorthand wire-type mapping

Receive ER (Embargo Rejected)

Behaviors triggered when a participant receives an ER (Embargo Rejected) message, transitioning EM state from Proposed to None and acknowledging receipt.

Trigger: Message Received — ER

ID	Priority	Requirement	Related
EMB-06-001	MUST	A Participant in EM Proposed (q^em ∈ P) receiving ER MUST move their EM state along the reject transition of EMB-18-005: back to None (q^em P → N) when the rejected proposal was the last one open, and staying in Proposed (q^em P → P) while another proposal is open. "Emit EK" is discharged by the CASE_MANAGER's commit of the received activity, fanned out as Announce(CaseLedgerEntry); no EK message is emitted (EP-09-009, MSM-02-009). If the receiver stayed in Proposed after the last open proposal is rejected, it would wait for an answer that does not come, and it would show an embargo negotiation that has ended. None tells every participant that no embargo binds the case. While another proposal is open, EM stays in Proposed, because that proposal still waits for an answer (ADR-0130). The ledger commit of the ER acknowledges it. ECA Details Preconditions - EM state is Proposed - EM state: PROPOSED Steps 1. [receiver] Transition EM state from PROPOSED to NONE → Receiver EM state is NONE 2. [receiver] CASE_MANAGER commits the received ER and announces the ledger entry (discharges EK) → Ledger entry committed and fanned out; no EK message exists Postconditions - Receiver EM state is NONE (proposal rejected), or PROPOSED while another proposal is open; EK discharged by the ledger commit	Satisfies: VP-11-004 — SHOULD send EK in acknowledgment of any E message except EK itself Satisfies: VP-05-017 — Participants MAY reject proposed embargo terms for any reason Satisfies*: MSM-02-006 — ER shorthand wire-type mapping

Receive ET (Embargo Terminated)

Behaviors triggered when a participant receives an ET (Embargo Terminated) message, transitioning EM state to Terminated and acknowledging receipt.

Trigger: Message Received — ET

ID	Priority	Requirement	Related
EMB-07-001	MUST	A Participant in EM Active (q^em ∈ A) receiving ET MUST transition their EM state to Exited (q^em A → X). "Emit EK" is discharged by the CASE_MANAGER's commit of the received activity, fanned out as Announce(CaseLedgerEntry); no EK message is emitted (EP-09-009, MSM-02-009). ET is the message that terminates an active embargo. The receiver records that the embargo has ended. ET has immediate effect regardless of other pending messages. ECA Details Preconditions - EM state is Active - EM state: ACTIVE Steps 1. [receiver] Transition EM state from ACTIVE to EXITED → Receiver EM state is EXITED 2. [receiver] Emit EK to acknowledge receipt of ET → EK queued for sender Postconditions - Receiver EM state is EXITED; EK emitted	Satisfies: VP-11-004 — SHOULD send EK in acknowledgment of any E message except EK itself Satisfies*: MSM-02-007 — ET shorthand wire-type mapping
EMB-07-002	MUST	A Participant in EM Revise (q^em ∈ R) receiving ET MUST transition their EM state to Exited (q^em R → X). "Emit EK" is discharged by the CASE_MANAGER's commit of the received activity, fanned out as Announce(CaseLedgerEntry); no EK message is emitted (EP-09-009, MSM-02-009). ET terminates the embargo regardless of whether a revision is pending. The revision proposal is abandoned upon termination. ECA Details Preconditions - EM state is Revise - EM state: REVISE Steps 1. [receiver] Transition EM state from REVISE to EXITED → Receiver EM state is EXITED 2. [receiver] Emit EK to acknowledge receipt of ET → EK queued for sender Postconditions - Receiver EM state is EXITED; pending revision abandoned; EK emitted	Satisfies: VP-11-004 — SHOULD send EK in acknowledgment of any E message except EK itself Satisfies*: MSM-02-007 — ET shorthand wire-type mapping
EMB-07-003	MUST	A Participant already in EM Exited (q^em ∈ X) receiving ET MUST remain in Exited with no state transition. "Emit EK" is discharged by the CASE_MANAGER's commit of the received activity, fanned out as Announce(CaseLedgerEntry); no EK message is emitted (EP-09-009, MSM-02-009). Exited is already the terminal state, so a duplicate termination message needs no additional transition and no acknowledgment of its own. ECA Details Preconditions - EM state is Exited - EM state: EXITED Steps 1. [receiver] Make no state change for the duplicate ET → EM state remains EXITED; no EK message exists Postconditions - EM state remains EXITED; no EK message emitted	Satisfies: VP-11-004 — SHOULD send EK in acknowledgment of any E message except EK itself Satisfies*: MSM-02-007 — ET shorthand wire-type mapping

Receive EE (Embargo Error)

Behaviors triggered when a participant receives an EE (Embargo Management Error) signal, which has no dedicated semantic dispatch value and is handled outside the standard AS2 pattern-matching pipeline.

Trigger: Message Received — EE

ID	Priority	Requirement	Related
EMB-08-001	SHOULD	A Participant that receives Create(ProcessingFault) about an embargo activity it sent SHOULD inquire about the nature of the error (GI) when the fault does not say what went wrong. EE has no wire activity of its own (MSM-02-008, MSM-05-001). The receiver emits no EK for the fault (EP-09-009). A fault report says that an embargo activity failed, but it does not always say why. An inquiry lets the sender explain the error and enables recovery. A fault report does not trigger an EM state transition, and the error is grouped by failure mode, not by state machine, so no EE or EK message exists. ECA Details Steps 1. [receiver] Emit GI to inquire about the nature of the error → GI queued for sender; no EK message exists Postconditions - GI emitted; EM state unchanged	Satisfies: VP-11-005 — SHOULD acknowledge (EK) and inquire (GI) about the nature of any error reported by EE Satisfies: MSM-02-008 — EE shorthand wire-type mapping

Receive EK (Embargo Acknowledgment)

Behaviors triggered when a participant receives an EK (Embargo Management Acknowledgment) passthrough signal, which has no dedicated semantic dispatch value and requires no state transition.

Trigger: Message Received — EK

ID	Priority	Requirement	Related
EMB-09-001	MAY	A Participant receiving EK MAY process it as a passthrough acknowledgment with no state transition and no required response. EK only confirms that its sender received an earlier E message. It carries no decision about the embargo, so it gives the receiver nothing to change and nothing to answer.*	Satisfies: VP-11-004 — EK is the acknowledgment; no acknowledgment of acknowledgment required Satisfies: MSM-02-009 — EK shorthand wire-type mapping

Enter EM Proposed

Trigger: State Entered — EM.PROPOSED

ID	Priority	Requirement	Related
EMB-10-001	MAY	A Participant entering EM Proposed MAY evaluate the proposed terms and answer the Invite with Accept(Invite(EmbargoEvent)) or Reject(Invite(EmbargoEvent)), or counter-propose with EV. EM Proposed marks that embargo negotiation is underway. The participant must evaluate the proposal and eventually accept, counter, or reject to move the EM process forward. Its answer is its own consent (MSM-07-003, MSM-07-004); the Case Owner's EA or ER decides the proposal for the case (MSM-02-002, MSM-02-006). ECA Details Preconditions - EM state is Proposed - EM state: PROPOSED	Satisfies: VP-04-004 — Once proposed, an embargo MAY be accepted or rejected Satisfies: VP-06-003 — A Receiver that cannot accept a Reporter's proposal as proposed SHOULD counter-propose rather than reject it Satisfies: VP-06-010 — Participants MAY accept or reject any proposed embargo as they see fit
EMB-10-002	SHOULD NOT	A Participant in RM Invalid or Deferred or Closed (q^rm ∈ {I, D, C}) SHOULD NOT begin or continue embargo negotiations while in those inactive RM states. VP-13-002 and VP-13-003 discourage starting EM in inactive RM states. An embargo proposed while a report is invalid or deferred is unlikely to result in productive coordination. ECA Details Preconditions - Participant is in RM Invalid/Deferred/Closed - RM state: INVALID, DEFERRED, CLOSED	Satisfies: VP-13-002 — SHOULD NOT begin EM in an inactive RM state Satisfies: VP-13-003 — SHOULD NOT begin EM with a proposal from a Participant in RM Invalid

Enter EM Active

Trigger: State Entered — EM.ACTIVE

ID	Priority	Requirement	Related
EMB-11-001	SHOULD NOT	A Participant in EM Active SHOULD NOT share the vulnerability report with a newly invited Participant until that Participant has accepted the existing embargo terms. VP-08-006 prohibits sharing the vulnerability report with new Participants who have not yet accepted an existing embargo. Sharing before acceptance undermines the embargo's confidentiality guarantees. ECA Details Preconditions - EM state is Active - EM state: ACTIVE	Satisfies: VP-08-006 — SHOULD NOT share vulnerability report with newly invited Participant unless they accepted the embargo
EMB-11-002	SHOULD	A Participant entering EM Active SHOULD maintain the embargo by not publishing information about the vulnerability until the embargo is terminated, whether on reaching its end time or early. An embargo whose end time has passed is ended by the CASE_MANAGER with the reason END_TIME_REACHED (EMB-13-003); until that termination reaches a Participant, its end time still bounds what it withholds. VP-05-014 specifies that Participants SHOULD NOT publish information about the vulnerability when there is an active embargo. Entering Active marks the formal commitment to these terms. Reaching the end time does not end the embargo by itself: the termination is a register change the CASE_MANAGER commits, so every Participant learns of it the same way (ADR-0122). ECA Details Preconditions - EM state is Active - EM state: ACTIVE	Satisfies: VP-05-014 — SHOULD NOT publish information when there is an active embargo
EMB-11-003	MUST NOT	A Participant in RM Closed or Deferred (q^rm ∈ {C, D}) in EM Active while other Participants remain engaged MUST NOT automatically terminate the embargo due to their own RM closure or deferral. VP-13-009 explicitly requires that a single Participant's closure or deferral SHALL NOT automatically terminate the embargo. The embargo persists as long as other Participants remain engaged and the EM process is Active. ECA Details Preconditions - Participant is in RM Closed/Deferred; EM state is Active - RM state: CLOSED, DEFERRED - EM state: ACTIVE	Satisfies: VP-13-009 — A Participant's closure or deferral SHALL NOT automatically terminate the embargo
EMB-11-004	SHOULD	Reports with no further tasks (q^rm ∈ {D, I}) SHOULD be held in Deferred or Invalid while the embargo remains Active or Revise (q^em ∈ {A, R}) rather than being closed. VP-13-006 advises keeping the report in a non-terminal RM state until the embargo has exited. Closing early may prematurely signal disengagement from the coordinated timeline. ECA Details Preconditions - Participant is in RM Deferred/Invalid; EM state is Active or Revise - RM state: DEFERRED, INVALID - EM state: ACTIVE, REVISE	Satisfies: VP-13-006 — SHOULD be held in Deferred or Invalid until embargo exits
EMB-11-005	SHOULD	A Participant who intends to change their adherence stance to an active embargo SHOULD communicate that intent clearly to other Participants. VP-13-008 requires communicating changes to embargo adherence. Surprises about who is or is not honoring the embargo undermine coordinated disclosure. ECA Details Preconditions - EM state is Active - EM state: ACTIVE	Satisfies: VP-13-008 — Changes to adherence intention SHOULD be communicated clearly

Enter EM Revise

Trigger: State Entered — EM.REVISE

ID	Priority	Requirement	Related
EMB-12-001	MAY	A Participant entering EM Revise MAY evaluate the revision proposal and answer its Invite with Accept(Invite(EmbargoEvent)) or Reject(Invite(EmbargoEvent)), or counter-propose a further revision with EV. EM Revise means an active embargo has a pending revision proposal. The participant must evaluate the proposed new terms and either accept, reject, or counter-propose to move the EM process forward. Its answer is its own consent (MSM-07-003, MSM-07-004); the Case Owner's EC or EJ decides the revision for the case (MSM-02-005, MSM-02-004). ECA Details Preconditions - EM state is Revise - EM state: REVISE	Satisfies: VP-04-005 — Once accepted, revisions MAY be proposed, which MAY be accepted or rejected
EMB-12-002	MUST NOT	A Participant in RM Closed or Deferred (q^rm ∈ {C, D}) in EM Revise while other Participants remain engaged MUST NOT automatically terminate the embargo due to their own RM state. VP-13-009 applies equally in Revise state. A single Participant's closure or deferral SHALL NOT automatically terminate the embargo. The embargo remains in force even when one Participant's engagement has declined. ECA Details Preconditions - Participant is in RM Closed/Deferred; EM state is Revise - RM state: CLOSED, DEFERRED - EM state: REVISE	Satisfies: VP-13-009 — A Participant's closure or deferral SHALL NOT automatically terminate the embargo
EMB-12-003	SHOULD	A Participant who intends to change their adherence stance while an embargo is in Revise state SHOULD communicate that intent clearly to other Participants. VP-13-008 requires communicating changes to embargo adherence. This applies during revision negotiations as well as during the stable Active state. ECA Details Preconditions - EM state is Revise - EM state: REVISE	Satisfies: VP-13-008 — Changes to adherence intention SHOULD be communicated clearly

Enter EM Exited

Trigger: State Entered — EM.EXITED

ID	Priority	Requirement	Related
EMB-13-001	SHOULD	A Participant entering EM Exited SHOULD treat no participant as bound by an embargo. The embargo register's ACTIVE entry is TERMINATED, and no consent row is written (MSM-07-025, ADR-0118, ADR-0122). Once the embargo exits, no consent row binds anyone: with no ACTIVE register entry nobody is a signatory, and a register with a TERMINATED entry accepts no further change (ADR-0122), so no later invitation to the terminated embargo can rebind anyone. The position is derived from the case, so it is not copied onto each participant record. ECA Details Preconditions - EM state is Exited - EM state: EXITED Steps 1. [participant] Terminate the register's ACTIVE entry; write no Participant consent row → No Participant is bound by an embargo; consent rows are as they were Postconditions - No active embargo and no signatory; EM state is terminal EXITED	Satisfies: VP-04-001 — Accepted embargoes MUST eventually terminate
EMB-13-003	MUST	When the end time of the embargo in force has passed, the CASE_MANAGER MUST end it with the reason END_TIME_REACHED, through one idempotent termination path. Two ways reach that path. One is the CASE_MANAGER's own lazy check when it next handles the case, for an inbound activity or one of its own triggers. The other is an outside request to end the embargo at its end time, such as from a Sentinel that monitors embargo timers. A request to end the embargo early, made after its end time, takes the same path. Each way commits the CASE_MANAGER's Remove(EmbargoEvent) with content END_TIME_REACHED and runs the full termination cascade. The outside request is made to the CASE_MANAGER itself. A Remove from the Case Owner is the owner's own message, ledgered on receipt like any other. VP-04-001 requires every accepted embargo to have an end time, so every embargo reaches one; recording the end as a termination keeps EM derived from the register, and lets the content gate stop withholding content under an embargo that has expired. The lazy check needs no scheduler; the outside request lets a deployment end an embargo on time without waiting for the next activity on the case. One path keeps the two from both committing: a register with a TERMINATED entry accepts no further change (ADR-0122). ECA Details Preconditions - An embargo is in force and its end time has passed - EM state: ACTIVE, REVISE Postconditions - The register's ACTIVE entry is TERMINATED with reason END_TIME_REACHED, every open proposal CANCELLED, EM EXITED, and the teardown announced	Refines: VP-04-001 — Every accepted embargo has an end time; reaching it ends the embargo Depends on: EP-08-004 — The termination cancels every open proposal in the same step
EMB-13-006	MUST	Whichever of the lazy check and the outside request (EMB-13-003) arrives after the embargo has ended MUST commit nothing. One path keeps the two from both committing: a register with a TERMINATED entry accepts no further change (ADR-0122).	Extends: EMB-13-003
EMB-13-007	MUST	The CASE_MANAGER MUST answer an end-time request (EMB-13-003) that arrives after the embargo has ended as already done. The requester asked for an outcome the case already holds, so the answer tells it the embargo is ended rather than refusing it.	Extends: EMB-13-003
EMB-13-008	MUST	An END_TIME_REACHED termination claimed before the embargo's end time MUST be refused, by the CASE_MANAGER before it commits and by a replica that replays it. An END_TIME_REACHED reason claims the end time has passed. A claim made before then is false, and the content gate would stop withholding content under an embargo that is still in force.	Extends: EMB-13-003
EMB-13-004	MUST	A termination Remove(EmbargoEvent) MUST carry what ended the embargo in content, exactly END_TIME_REACHED or EARLY. Its summary carries a human-readable account the protocol does not read. The what is all a receiver needs to apply a termination and to check it against the end time; the why records the decision. A cause is a kind with its own details, so a new cause (adversary awareness, exploit code held by adversaries, a participant's leak) is a new kind rather than a change to a closed list (ADR-0122).	Refines: EMB-13-001 — Carries what ended the ACTIVE entry
EMB-13-009	MUST	A receiver MUST refuse, at the parse edge, a termination Remove(EmbargoEvent) whose content is anything other than END_TIME_REACHED or EARLY (EMB-13-004). The what is all a receiver needs to apply a termination and to check it against the end time, so a termination without a valid what cannot be applied.	Extends: EMB-13-004
EMB-13-010	MUST	The TERMINATED register entry MUST record the termination's reason (the what) and, when known, a structured cause (the why). The cause is an object discriminated on kind, whose details depend on the kind. One kind is THREAT_SIGNAL, with the signals (P, X, A) that ended the embargo, distinct and in that order. Another, FIX_READY, has the vendor participants whose readiness made the quorum (VP-09-007). The other kinds are FIX_DEPLOYED, and OTHER, whose account is the summary. The why records the decision. A cause is a kind with its own details, so a new cause (adversary awareness, exploit code held by adversaries, a participant's leak) is a new kind rather than a change to a closed list (ADR-0122).	Extends: EMB-13-004 Refines: EMB-13-001
EMB-13-011	MUST NOT	An END_TIME_REACHED termination MUST NOT record a cause (EMB-13-010). Every cause kind is EARLY, and an EARLY termination with no cause is valid and records the what alone. A cause explains why an embargo ended before its end time. An embargo that ran to its end time has no such cause.	Extends: EMB-13-010
EMB-13-005	MUST	A termination Remove(EmbargoEvent) whose termination has a cause (EMB-13-010) MUST carry it as terminationCause. One ledger entry is one activity, and the termination's entry is the whole TERMINATE register step (ADR-0124), so the why reaches a replica replaying the ledger only if the Remove carries it. A threat signal is a fact about the case that every participant learns from a status entry; naming it on a Remove while the case status does not show it would leave the register and the status disagreeing, and reading the Remove as a status change would commit one no participant sent (ADR-0122).	Refines: EMB-13-010 — Carries the recorded cause on the wire so replicas can copy it
EMB-13-012	MUST	At the parse edge, a receiver MUST refuse a bad terminationCause (EMB-13-005). A cause is bad when its kind is unknown, when a detail is missing or malformed, or when the termination is END_TIME_REACHED. A cause the receiver cannot read, or one on a termination that can have none (EMB-13-011), would put a TERMINATED entry in the register that no other node can reproduce.	Extends: EMB-13-005
EMB-13-013	MUST	A FIX_READY, FIX_DEPLOYED or OTHER cause on the Case Owner's Remove to the CASE_MANAGER is the owner's claim. The CASE_MANAGER MUST record it as given. These causes are the owner's account of its own decision, which the CASE_MANAGER has no grounds to check against its own view of the case.	Extends: EMB-13-005
EMB-13-014	MUST	The CASE_MANAGER MUST refuse a THREAT_SIGNAL cause on the Case Owner's Remove before it is committed. The refusal's reason directs the sender to a case status update that sets P, X or A, the way a threat signal ends an embargo. A threat signal is a fact about the case that every participant learns from a status entry. Naming it on a Remove while the case status does not show it would leave the register and the status disagreeing, and reading the Remove as a status change would commit one no participant sent (ADR-0122).	Extends: EMB-13-005
EMB-13-015	MAY	A Remove that the CASE_MANAGER sends MAY name THREAT_SIGNAL as its cause. No other Remove names it (EMB-13-014). The CASE_MANAGER ends an embargo on a threat signal it has adopted into the case status, so its Remove and the status agree.
EMB-13-016	MUST	A replica MUST record, on its TERMINATED entry, the cause that the termination's ledger entry carries. One ledger entry is one activity, and the termination's entry is the whole TERMINATE register step (ADR-0124), so the why reaches a replica replaying the ledger only if the Remove carries it.	Extends: EMB-13-005
EMB-13-017	MUST NOT	A replica MUST NOT work a termination cause out from its own case state. A replica's own view can differ from the CASE_MANAGER's, such as threat signals its PXA does not carry. A cause it worked out would then disagree with the CASE_MANAGER's TERMINATED entry (CM-23-016).	Extends: EMB-13-016
EMB-13-002	MUST NOT	A Participant in EM Exited MUST NOT seek new embargoes or accept new embargo proposals (EP) for this case when the CS state is public (q^cs ∈ ···P··), exploit-public (q^cs ∈ ····X·), or attacks-observed (q^cs ∈ ·····A). VP-06-001 prohibits seeking new embargoes once public disclosure, exploit publication, or attacks have occurred. The EXITED state after any of these events is terminal for embargo negotiations on this case. ECA Details Preconditions - EM state is Exited; CS matches pattern ...P.. - EM state: EXITED - CS pattern: ...P.. - EM state is Exited; CS matches pattern ....X. - EM state: EXITED - CS pattern: ....X. - EM state is Exited; CS matches pattern .....A - EM state: EXITED - CS pattern: .....A	Satisfies: VP-06-001 — No new embargo once public awareness, exploit publication or attacks have occurred

Actor-Voluntary Embargo Termination (Trigger Side)

Trigger-side factory for voluntarily ending an active embargo (e.g., fix deployed or ready). "The actor" here is the actor enacting the CASE_MANAGER role: the factory's canonical case-state write (EM → EXITED, ledger commit, teardown announce) is gated on CVDRole.CASE_MANAGER (terminate_embargo_bt runs ResolveCaseManagerNode before the state mutation) and is authorised by the Case Owner by default (CM-02-005). A teardown that a received P, X or A report calls for is authorised by the Case Owner's adoption of that value, with no second gate (RSH-07-001, ADR-0166). A non-manager Participant that wishes to end an embargo does not run this trigger to write canonical state; it initiates termination by reporting the condition or notifying intent (VP-11-003, VP-13-017/018), and terminates only its own compliance. See CONCERN-3280 for the reconciliation of the participant-facing protocol prose with this authority model.

Trigger: State Entered — EM.ACTIVE

ID	Priority	Requirement	Related
EMB-14-001	MUST	An actor that ends an active embargo early of its own accord MUST name its reason: a deployed fix, a ready fix, or another reason. Voluntary termination requires an auditable reason. ECA Details Preconditions - EM state is Active or Revise - EM state: ACTIVE, REVISE Steps 1. [actor] Choose the termination reason (fix deployed, fix ready, or other) → Reason chosen Postconditions - A termination reason is chosen	Refines: EMB-07-001 — Voluntary actor termination is a sub-case of active-embargo termination
EMB-14-005	MUST NOT	An actor that names no reason MUST NOT end an active embargo early of its own accord. A termination with no reason gives the other participants nothing to audit (EMB-14-001). ECA Details Postconditions - EM state is unchanged	Extends: EMB-14-001
EMB-14-006	MUST	An actor that ends an active embargo early of its own accord MUST record its reason as the termination's cause (EMB-13-004). The cause is FIX_DEPLOYED, FIX_READY or OTHER respectively, never an EARLY termination with no cause. Recording the chosen reason as the cause carries it to every participant through the termination's ledger entry, where a cause-less EARLY termination would tell them only that the embargo ended. ECA Details Steps 1. [actor] Terminate the embargo, recording the chosen reason as its cause → ET emitted carrying the cause; EM transitions to EXITED Postconditions - EM state is EXITED; ET queued; termination cause recorded	Extends: EMB-14-001 Uses definition from: EMB-13-004

Inbound Embargo-Response Decision (Received Side)

Behaviors triggered when an actor receives an inbound embargo overture and must decide how to respond. Two overture flows are distinguished: (Flow A) an EM-level embargo proposal (EP) proposing terms, whose acceptance moves the shared EM state; and (Flow B) a PEC-level invitation (Invite(EmbargoEvent)[context=VulnerabilityCase]) asking the actor to become a signatory to an embargo, whose acceptance advances that participant's Participant Embargo Consent (PEC) state. The pre-PEC simulator conflated these into a single _ChooseEmProposedResponse fallback; the production protocol separates the shared EM lifecycle (EMB-01..EMB-09) from per-participant consent (CM-18, ADR-0048). This group specifies a single decision seam layered over both flows: it selects the response (accept / defer-to-owner / reject / counter) while delegating the mechanical transition to the existing received and trigger BTs. The mechanics already exist (invite/accept/reject trees, propose/accept/reject trigger use cases); what is missing is the decision layer that chooses among them, with a default-accept policy and a plug-in seam for owner adjudication.

Trigger: Message Received — EP | InviteToEmbargoOnCase

ID	Priority	Requirement	Related
EMB-15-004	MUST	An actor that rejects an embargo overture MUST answer with the activity that matches what it rejects. The Case Owner deciding a proposal for the case sends ER, its Reject(EmbargoEvent)[target=VulnerabilityCase], which returns the shared EM to NONE (EMB-06, MSM-07-009). A participant answering an embargo Invite sends a Reject of the Invite, which records only its own consent (MSM-07-004). That Reject marks the rejected embargo's row DECLINED. A signatory refusing proposed terms keeps its row for the embargo in force (MSM-07-015). A proposal and an Invite carry different EM and consent semantics, so the rejection has to match the overture for every participant to read it the same way. The pre-public constraint (EMB-01-002) is a hard protocol rule that overrides any local acceptance policy. ECA Details Preconditions - Inbound overture received; decision resolves to reject, OR CS is public/exploit/attacks forcing rejection (EMB-01-002) Steps 1. [participant] Answer with the rejection that matches the overture → The Case Owner's decision on a proposal is ER (EM → NONE); an embargo Invite gets a Reject of the Invite, recording DECLINED Postconditions - Overture rejected with the activity that matches it	Refines: EMB-06-001 — Flow A rejection reuses the ER emission path Refines: CM-18-003 — Flow B rejection advances PEC to DECLINED
EMB-15-009	MAY	The Case Owner MAY send a Reject(Invite(EmbargoEvent)) besides its decision for the case. That Reject records only the owner's own consent, like any sender's (MSM-07-004). The owner is also a participant with a consent row of its own. Its decision for the case is a separate activity (MSM-07-009, ADR-0122), so its Invite answer decides nothing for the case.	Extends: EMB-15-004
EMB-15-010	MUST	A participant MUST send the refusal EMB-01-002 requires whatever its own decision on the overture would have been. The pre-public constraint (EMB-01-002) is a hard protocol rule that overrides any local acceptance policy, so no decision seam may answer in its place.	Satisfies: EMB-01-002 — Mandatory rejection when public/exploit/attacks overrides default-accept

CS Public/Exploit/Attacks Detected While EM Proposed

Behaviors required when a Participant detects that the vulnerability has become public (q^cs ∈ ···P··), an exploit is available (q^cs ∈ ····X·), or attacks have been observed (q^cs ∈ ·····A) while the case EM state is still Proposed (q^em ∈ P). Embargo negotiation is not viable in any of these states; the proposed embargo MUST be abandoned.

Trigger: State Entered — CS.public_exploit_attacks

ID	Priority	Requirement	Related
EMB-16-001	MUST	A Participant in EM Proposed (q^em ∈ P) MUST abandon the proposed embargo when it detects a CS transition into P, X or A. The P state is public (q^cs ∈ ···P··), X is exploit-available (q^cs ∈ ····X·), and A is attacks-observed (q^cs ∈ ·····A). It cancels each open proposal in the case's embargo register, so EM derives None (q^em P → N). The CASE_MANAGER cancels a proposal it received with its ER, Reject(Invite(EmbargoEvent)), committed as reject_invite_to_embargo_on_case. It cancels a proposal it made itself with its Undo(Invite(EmbargoEvent)), committed as undo_invite_to_embargo_on_case. After either, it sends its Undo(Invite(EmbargoEvent)) of each Invite it relayed for that proposal. A proposal never relayed is cancelled all the same. EMB-01-002 establishes that embargo negotiation is not viable once public disclosure, exploit availability, or attacks have occurred. EMB-01-002 is framed as a guard on receiving EP, but the same viability constraint applies when a P/X/A state change arrives while a proposal is already in flight. Continuing to negotiate a proposed embargo in these conditions would be misleading to other Participants and counter to the purpose of coordinated disclosure. CANCEL records that nobody decided the proposal (ADR-0122). An actor undoes only an activity it performed, so withdrawing an Invite one sent is an Undo and declining one received is a Reject; a CASE_MANAGER act with a participant's verb and object carries the participant's semantic type (ADR-0152). ECA Details Preconditions - EM state is Proposed - EM state: PROPOSED - CS transitions to public (q^cs ∈ ···P··) - CS pattern: ...P.. - CS transitions to exploit-available (q^cs ∈ ····X·) - CS pattern: ....X. - CS transitions to attacks-observed (q^cs ∈ ·····A) - CS pattern: .....A Steps 1. [system] Detect that CS has transitioned to a P/X/A state while EM is Proposed → An open proposal is recognised 2. [system] As the CASE_MANAGER, cancel each open proposal: commit its Reject of the proposal, or its Undo of an own proposal, then an Undo of each Invite relayed for it → Each proposal's register entry is CANCELLED and EM derives NONE; the entries are committed and replayed by every replica Postconditions - EM state is NONE; the abandonment is committed; proposed embargo abandoned	Extends: EMB-01-002 — EMB-01-002 guards against entering PROPOSED with P/X/A set; this entry covers the symmetric case where P/X/A fires while already in PROPOSED Refines: EMB-06-001 — ER emission semantics apply; EM returns to NONE
EMB-16-003	MUST	A Participant that abandons a proposed embargo on a P/X/A transition (EMB-16-001) MUST notify the other Participants. Continuing to negotiate a proposed embargo that is no longer viable would mislead the other Participants. The CASE_MANAGER's committed entries are the notice to every other Participant (EP-09-007, EP-09-009).	Extends: EMB-16-001
EMB-16-004	MUST	The CASE_MANAGER MUST commit the entries that abandon every open proposal (EMB-16-001) in one transaction (CLP-07-015). A partly committed abandonment would leave some proposals open after the case reached P/X/A, so the case's register and its replicas would disagree about which proposals are still open.	Extends: EMB-16-001 Refines: CLP-07-015
EMB-16-005	MUST	A replica MUST apply each abandoned proposal's CANCEL once, from the entry that carries it (ADR-0152). The CASE_MANAGER's Reject cancels the proposal, and each Undo after it finds the proposal cancelled and changes nothing. Applying the CANCEL from its own entry keeps the replica's register equal to the CASE_MANAGER's.	Extends: EMB-16-001
EMB-16-002	MUST NOT	This rule covers a Participant without the CASE_MANAGER role that detects a P/X/A CS transition while EM is Proposed. It MUST NOT emit ER as the abandonment of the case's open proposals. Abandoning the case's open proposals is a decision for the case, and only the actor that holds the CASE_MANAGER role writes shared EM state (EMB-16-001, EP-09-008). The P/X/A signal already reaches the CASE_MANAGER as a status declaration, and the CASE_MANAGER abandons the proposals when it detects that signal. A Reject of the Invite that another Participant sends arrives at the CASE_MANAGER as that Participant declining the proposal (MSM-07-004). The CASE_MANAGER records only that decline, so the Reject cannot abandon the proposals, and it misstates what the Participant meant.	Refines: EMB-16-001 Depends on: EP-09-008
EMB-16-006	MUST NOT	This rule covers a Participant without the CASE_MANAGER role that detects a P/X/A CS transition while EM is Proposed. It MUST NOT write the abandonment to its own EM state. Only the actor that holds the CASE_MANAGER role writes shared EM state (EMB-16-001, EP-09-008). Another Participant's EM moves when its replica replays the CASE_MANAGER's entries.	Extends: EMB-16-002 Depends on: EP-09-008

Late Accept of an Expired Embargo Invitation

Behaviors required when an Accept(Invite(EmbargoEvent)) arrives after the invitation's RSVP deadline (CM-28-001) has passed. The protocol is liberal in what it accepts: a late accepter has signalled willingness to coordinate and MUST NOT be sent away. Codified by ADR-0065. Source: IDEA-2066. The trigger is a Participant's consent answer, which carries no protocol shorthand (MSM-02-010).

Trigger: Message Received — AcceptInviteToEmbargoOnCase

ID	Priority	Requirement	Related
EMB-17-001	MUST	A CASE_MANAGER receiving an Accept(Invite(EmbargoEvent)) after the invitation's effective RSVP deadline MUST NOT reject it solely because the deadline has passed. Being liberal in what is accepted serves CVD outcomes. A late accepter is volunteering to coordinate; refusing them converts a missed deadline into a lost participant, which is worse for the case than a late consent. See ADR-0065. ECA Details Preconditions - The referenced invitation's effective RSVP deadline has passed Postconditions - The Accept is not refused on deadline grounds; one of EMB-17-002, EMB-17-003, or EMB-17-004 has been applied	Depends on: CM-28-003
EMB-17-012	MUST	For an Accept(Invite(EmbargoEvent)) received after the invitation's effective RSVP deadline, the CASE_MANAGER MUST check whether the accepted embargo is still compatible with the case's Active Embargo. It then applies EMB-17-002, EMB-17-003 or EMB-17-004. A late Accept can name the embargo in force, a superseded one, or none at all. Each needs its own answer, so the CASE_MANAGER checks which case holds first. See ADR-0065. ECA Details Preconditions - The referenced invitation's effective RSVP deadline has passed Postconditions - One of EMB-17-002, EMB-17-003, or EMB-17-004 has been applied	Extends: EMB-17-001
EMB-17-002	MUST	When the accepted embargo is the case's Active Embargo, the CASE_MANAGER MUST honour the late Accept and mark the participant's consent row for it AGREED, exactly as it would for an on-time Accept. A row at TIMED_OUT moves directly to AGREED (TIMED_OUT → AGREED, ADR-0118), and so does one at DECLINED (DECLINED → AGREED, CM-18-003): the participant has changed its answer, so it is not re-invited first. The CASE_MANAGER honours it by committing the received Accept verbatim as accept_invite_to_embargo_on_case, carrying the row it states, as an on-time Accept is committed (EMB-17-009, ADR-0152). If the terms the participant agreed to are the terms in force, the participant is a valid signatory. The deadline governs whether the invitation is open, not whether the agreement is sound. See ADR-0065. The Accept states the change, so its entry is the change's entry (CLP-07-013), and a replica reaches the state an on-time Accept leaves. ECA Details Preconditions - EM state is Active - EM state: ACTIVE - The accepted embargo ID matches the case's Active Embargo Steps 1. [system] Record the PEC AGREE transition for the accepting participant → The participant's consent row for the Active Embargo is AGREED Postconditions - The participant is a signatory to the Active Embargo	Refines: EMB-17-001
EMB-17-003	MUST	When the accepted embargo is not the case's Active Embargo, the CASE_MANAGER MUST send the accepting actor a fresh Invite(EmbargoEvent) with the Active Embargo. An accepting participant at TIMED_OUT moves TIMED_OUT → INVITED for the Active Embargo (ADR-0118). The fresh Invite is a relay (EP-09-002). Its actor is the CASE_MANAGER. Its attributedTo names the Active Embargo's proposer, or the CASE_MANAGER itself when it made the embargo as the protocol default, without a proposal. Recording the stale Accept as consent would make the participant a signatory to terms they never saw. Rejecting them would discard a willing participant. Re-inviting resolves both: the actor stays in the case and is asked to consent to the terms actually in force. See ADR-0065. The re-invite asks about terms somebody proposed, exactly as a relay does, so it carries the relay's shape and semantic type (ADR-0152). ECA Details Preconditions - The accepted embargo ID does not match the case's Active Embargo, and the case has an Active Embargo Steps 1. [system] Emit a fresh Invite(EmbargoEvent) to the accepting actor carrying the case's Active Embargo → Accepting participant's consent row for the Active Embargo is INVITED; stale Accept is not recorded as consent Postconditions - A fresh invitation for the Active Embargo has been sent; the actor remains a case participant	Refines: EMB-17-001 Depends on: CM-28-013
EMB-17-013	MUST	Once it has queued the fresh Invite of EMB-17-003 (SYNC-09-002), the CASE_MANAGER MUST commit it as invite_to_embargo_on_case. The invitee's INVITED row with the Invite's deadline follows it (CM-28-013). The re-invite asks about terms somebody proposed, exactly as a relay does, so it carries the relay's semantic type (ADR-0152). Committing it after it is queued lets a rebuilt send keep the same id (SYNC-09-002).	Extends: EMB-17-003 Depends on: CM-28-013
EMB-17-014	MUST	A replica MUST apply the CASE_MANAGER's re-invite (EMB-17-003) through the relay slot, so that the Invite proposes nothing and EM does not move. The replica's register already holds the embargo the Invite names, so the Invite asks for consent to it and changes no embargo state (ADR-0152).	Extends: EMB-17-003
EMB-17-005	MUST NOT	When the accepted embargo is not the case's Active Embargo, the CASE_MANAGER MUST NOT record the stale Accept as consent to the current terms. Recording the stale Accept as consent would make the participant a signatory to terms they never saw. See ADR-0065.	Refines: EMB-17-003
EMB-17-006	MUST NOT	When the accepted embargo is not the case's Active Embargo, the CASE_MANAGER MUST NOT reject the accepting actor. Rejecting a willing participant discards coordination capacity; re-inviting to the current terms is the correct response. See ADR-0065.	Refines: EMB-17-003
EMB-17-004	MUST	When the case has no Active Embargo and no Proposed Embargo (EM EXITED or NONE), the CASE_MANAGER MUST treat a late Accept as a no-op. The no-op is not a refusal (HP-01-003). A redelivery of the same Accept gets the same result. Follows the EMB-07-003 precedent for post-terminal messages: no transition. There is nothing to invite the actor to, so a fresh invitation would manufacture a negotiation nobody requested — but the actor's case participation is independent of embargo consent and MUST survive. An entry or reply acknowledging the Accept would change nothing at any receiver, and anything that holds the case and its ledger can see the Accept named an embargo the case no longer holds, so the no-op is not ledgered (ADR-0152, CLP-02-013). See ADR-0065. ECA Details Preconditions - EM state is EXITED (embargo terminated) or NONE (no embargo started) - EM state: EXITED, NONE Steps 1. [system] Treat the Accept as a no-op, committing and sending nothing → Participant consent rows are unchanged; participant remains in the case; no ledger entry is committed and nothing is sent Postconditions - No embargo state change; accepting actor remains a case participant	Refines: EMB-17-001 Extends: EMB-13-002 — EMB-13-002 covers the P/X/A case; this entry covers an Accept arriving after EM EXITED when CS is not yet P/X/A
EMB-17-015	MUST NOT	The CASE_MANAGER MUST NOT commit any ledger entry for a late Accept that arrives when the case has no Active Embargo and no Proposed Embargo (EMB-17-004). An entry acknowledging the Accept would change nothing at any receiver. Anything that holds the case and its ledger can see the Accept named an embargo the case no longer holds, so the no-op is not ledgered (ADR-0152, CLP-02-013).	Part of: EMB-17-004
EMB-17-016	MUST NOT	The CASE_MANAGER MUST NOT send any activity in reply to a late Accept that arrives when the case has no Active Embargo and no Proposed Embargo (EMB-17-004). There is nothing to invite the actor to, so a reply or fresh invitation would manufacture a negotiation nobody requested.	Part of: EMB-17-004
EMB-17-017	MUST	The CASE_MANAGER MUST leave the participant's consent rows unchanged for a late Accept that arrives when the case has no Active Embargo and no Proposed Embargo (EMB-17-004). Nothing is recorded after a termination (EM EXITED), and a TIMED_OUT row stays TIMED_OUT when no embargo has started (EM NONE) (ADR-0118). The Accept names an embargo that is no longer, or not yet, in force, so no row can bind to it. The actor's case participation is independent of embargo consent and survives.	Part of: EMB-17-004
EMB-17-007	MUST NOT	When the case has no Active Embargo and no Proposed Embargo (EM state is EXITED or NONE), the CASE_MANAGER MUST NOT issue a fresh embargo invitation to the accepting actor. There is no active embargo to invite the actor to; a fresh invitation would manufacture a negotiation nobody requested. See ADR-0065.	Refines: EMB-17-004
EMB-17-008	MUST NOT	When the case has no Active Embargo and no Proposed Embargo (EM state is EXITED or NONE), the CASE_MANAGER MUST NOT remove the accepting actor from the case. Case participation is independent of embargo consent; the actor's willingness to coordinate must not result in their removal. See ADR-0065.	Refines: EMB-17-004
EMB-17-009	MUST	When the CASE_MANAGER honours a late Accept (EMB-17-002), it MUST commit the received Accept(Invite(EmbargoEvent)) verbatim as accept_invite_to_embargo_on_case. Its entry carries the AGREED row the Accept states, exactly as for an on-time Accept. A replica then copies the row without re-evaluating the deadline (RSH-08-004, ADR-0124, CLP-07-011). Without a committed entry the replica has no signal that the row moved to AGREED; the replica's participant record would silently stay TIMED_OUT while the CASE_MANAGER's record shows AGREED, breaking ledger-driven convergence (ADR-0108, ADR-0118). The Accept states the change, so its entry is the change's entry (CLP-07-013); a follow-up Update of the same row would record one state change twice. The deadline having passed is an observation anything holding the case can make, so it is not ledgered either (ADR-0152). ECA Details Postconditions - The late Accept is committed as accept_invite_to_embargo_on_case in the CASE_MANAGER's store, and the accepter's AGREED row is copied from it in every replica's store	Refines: EMB-17-001 Depends on: RSH-08-004
EMB-17-018	MUST NOT	When the CASE_MANAGER honours a late Accept (EMB-17-002), it MUST NOT commit any further entry for the same row. An example is its own Update(EmbargoConsent) of the AGREED row (CLP-07-002, ADR-0152). The Accept states the change, so its entry is the change's entry (CLP-07-013); a follow-up Update of the same row would record one state change twice.	Extends: EMB-17-009

EM Write-Boundary Consolidation

Requirements ensuring that all EM state transitions are executed through the EmbargoLifecycle service layer rather than written directly to case.current_status.em in BT nodes or helpers. Identified by audit in CONCERN-2412: three BT nodes (EmActivateEmbargo, ClearEmbargo, SetDefaultActiveEmbargoNode) bypass EmbargoLifecycle with direct EmDimension assignment. Complements SM-04-001 (general write-boundary guard requirement) with an EM-specific routing rule.

ID	Priority	Requirement	Related
EMB-18-007	MUST	A participant replica MUST fetch from the case's CASE_MANAGER the embargo an announced revision replaces, when it cannot read it (AKM-05-007). It defers the revision until the fetch settles (AKM-05-010), and refuses it only when the fetch fails (AKM-05-015). A replica can lack a record the CASE_MANAGER holds through a gap or a lag, and the CASE_MANAGER can supply it (AKM-05-003). The fetch runs before the activation writer, so EMB-18-003's fail-closed read still guards the register.	Refines: EMB-18-003 Depends on: AKM-05-007
EMB-18-004	MUST	A receiver MUST refuse an inline EmbargoEvent whose context is neither the case that carries it nor a report that case holds (EP-04-009). The same refusal applies to the record the receiver already holds under the embargo's id. It applies whether the case or ledger entry carries the embargo inline or names it by bare id. For a ledger entry, the case's reports are those of the replica's stored case. An embargo belongs to the case that its context names. A handler stores a carried embargo when its store does not hold that id yet, and the first write wins. An unchecked event would therefore let a sender plant the embargo of another case under an id that case will name later. That case would then name the planted record. The check therefore covers the record already held under the id, not only the carried copy. A Reporter's proposal names its report until the case exists, and it keeps its id after that (EP-04-004). A refusal of an embargo about one of the case's reports would refuse the Reporter its own case.	Refines: EMB-18-003
EMB-18-012	MUST	A receiver MUST make an EMB-18-004 refusal before it writes anything. The event is then not stored, and no embargo state of either case changes. A handler stores a carried embargo when its store does not hold that id yet, and the first write wins. A refusal after a write would leave the planted record in the store for the other case to name later.	Extends: EMB-18-004
EMB-18-005	MUST	Every change to a case's embargo register MUST move the case's EM state only along an EM transition for the change's EM trigger: a proposal is propose, an activation is accept, a rejection, or the cancellation of open proposals with no embargo in force, is reject, and a termination is terminate. The EM transitions are propose: N→P, P→P, A→R, R→R; reject: P→N, P→P, R→A, R→R; accept: P→A, P→R, R→A, R→R; and terminate: A→X, R→X. A rejection leaves Proposed, and a rejection or an acceptance leaves Revise, only when no proposal remains open; an acceptance from Proposed moves to Active, or to Revise while another proposal stays open. EM is computed from the embargo register (ADR-0122), not replaced by it: the EM state machine remains the protocol's model, and the register is a layer beneath it. With several proposals open, rejecting or activating one leaves the others open: a rejection keeps EM in Proposed or Revise until the last one is off the table, and an activation from Proposed puts the embargo in force with the others pending as revisions, in Revise (ADR-0130).	Refines: EMB-18-001

Embargo Teardown Announcement

Who authors the Announce(EmbargoEvent) that follows an embargo teardown, and who receives it. Added by ISSUE-2238 after the recipients were found to be unspecified, which is how they came to disagree with the tree's role gate.

ID	Priority	Requirement	Related
EMB-19-001	MUST	The actor that holds the CASE_MANAGER role for the case MUST author the Announce(EmbargoEvent) emitted after an embargo teardown. The teardown changes canonical case state, so the actor that holds the CASE_MANAGER role announces it, and the participants are its audience. The tree that commits the teardown runs as the CASE_MANAGER, because the ledger commit is gated on that role. An announcement addressed to the CASE_MANAGER would therefore go to the announcing actor itself, and the teardown would reach nobody.	Refines: BT-05-006 Refines: CLP-10-001
EMB-19-003	MUST	The CASE_MANAGER MUST address the teardown Announce(EmbargoEvent) (EMB-19-001) to every active participant (CM-10-004) except itself. The teardown changes canonical case state, and the participants are the audience of that change.	Extends: EMB-19-001 Uses definition from: CM-10-004
EMB-19-004	MUST NOT	The CASE_MANAGER MUST NOT address the teardown Announce(EmbargoEvent) (EMB-19-001) to the CASE_MANAGER. The tree that commits the teardown runs as the CASE_MANAGER, because the ledger commit is gated on that role. An announcement addressed to the CASE_MANAGER would go to the announcing actor itself and loop back for no additional record.	Extends: EMB-19-001
EMB-19-002	MUST	When a case has no participants besides the CASE_MANAGER, the teardown announcement MUST be skipped rather than emitted with an empty recipient list. An activity addressed to nobody is undeliverable, and delivery discards it anyway; constructing one only adds a queue entry that can never be resolved. Skipping keeps the teardown itself unaffected, consistent with the announcement being best-effort — a notification gap MUST NOT block a teardown.	Refines: EMB-19-001

Embargo Policy

Requirements for a standardized embargo policy record associated with an Actor profile. Allows actors to declare their default embargo preferences so that coordinators can evaluate compatibility before proposing an embargo or inviting an actor to a case.

Policy Record Format

ID	Priority	Requirement	Related
EP-01-001	MAY	An Actor profile MAY include an embargo_policy field containing the Actor's structured embargo policy record inline. The policy is part of the profile: an Actor has at most one, and it is published, read and replaced as a field of the profile, not as a separate object. Whoever holds an Actor's profile then holds its embargo terms, so carrying the profile (CP-01-010) carries the policy, and no lookup has to choose among several records.
EP-01-002	MUST	The embargo policy record MUST include the following fields: actor_id (full URI string identifying the Actor to which this policy applies), inbox (URL string of the Actor's ActivityPub inbox), preferred_duration (ISO 8601 duration string representing the Actor's preferred embargo length) A coordinator that reads a policy needs to know whose terms it states, where to send a proposal or Invite, and what length the actor prefers. Without actor_id a policy copied out of its profile cannot be attributed, without inbox the coordinator cannot reach the actor, and preferred_duration is the actor default that shortest-wins reads at case creation (EP-04-003).	Implements: VP-05-001 Implements: VP-07-001 Implements: VP-07-002 Depends on: DUR-01-001 — ISO 8601 duration format
EP-01-003	SHOULD	The embargo policy record SHOULD include the optional fields minimum_duration (ISO 8601 duration), maximum_duration (ISO 8601 duration), and notes (free-text string describing the Actor's embargo preferences). A declared range tells a coordinator, before it proposes, which terms the actor will accept (EP-03-002), which saves a propose-and-reject round trip. Free-text notes carry preferences that a duration cannot express. The fields are optional because many actors hold only a preferred length.	Implements: VP-05-001 Implements: VP-07-006 Depends on: DUR-01-001 — ISO 8601 duration format
EP-01-005	MUST	The embargo policy record MUST use full-URI IDs for actor_id Other actors on other servers read and compare policies. A local or short identifier cannot be resolved or compared across servers, so a coordinator could attach a policy to the wrong actor; a full URI names one actor everywhere (OID-01-001).	Depends on: OID-01-001
EP-01-006	SHOULD	When minimum_duration is declared, an Actor SHOULD reject embargo proposals shorter than that value. The minimum_duration field signals a floor below which the Actor will not accept an embargo; evaluating it prevents compatibility mismatches.	Refines: EP-01-003
EP-01-007	SHOULD	When maximum_duration is declared, an Actor SHOULD reject embargo proposals longer than that value. The maximum_duration field signals a ceiling above which the Actor will not accept an embargo; evaluating it prevents compatibility mismatches.	Refines: EP-01-003

Policy Compatibility Evaluation

ID	Priority	Requirement	Related
EP-03-001	SHOULD	Before proposing an embargo or inviting an actor to join an existing embargo, the CASE_MANAGER SHOULD retrieve and evaluate the target actor's embargo policy for compatibility with the proposed embargo terms A proposal the invitee will reject costs a negotiation round and can leave the invitee outside the embargo while the round runs. Reading the published policy first lets the CASE_MANAGER choose terms the invitee has said it accepts, or know in advance that it will decline.	Implements: VP-07-001 Implements: VP-07-006 Implements: VP-07-007
EP-03-002	MUST	Compatibility evaluation MUST check that the proposed duration falls within the target actor's minimum_duration–maximum_duration range, if declared The declared minimum and maximum are the actor's statement of what it will accept (EP-01-006, EP-01-007). An evaluation that ignored them would report terms as compatible that the actor has already said it will reject.	Implements: VP-07-003 Implements: VP-07-004 Implements: VP-07-005 Depends on: DUR-01-001 Depends on: DUR-04-001

Default Embargo Semantics

ID	Priority	Requirement	Related
EP-04-001	MUST	When the CASE_OWNER's actor default embargo applies at case creation and the sender submitted no explicit embargo proposal, the case's initial EM state MUST be EM.ACTIVE, not EM.PROPOSED. The sender's report submission without a counter-proposal constitutes tacit acceptance of the CASE_OWNER's actor default embargo. A sender that submits a report without terms of its own has nothing to object to in the receiver's default, so nobody is left to accept it. A case left at EM.PROPOSED would wait for an answer nobody owes, with no embargo in force at the moment the report is most sensitive.	Refines: DUR-07-003
EP-04-002	MUST NOT	When a default embargo is created, the intermediate EM Proposed state MUST NOT be observable to other participants: no message, ledger entry or replica shows the embargo as Proposed. The default embargo is in force from creation. A participant that saw it as Proposed would treat it as not yet agreed and could answer it or counter-propose, and its replica would record a negotiation that never happened.
EP-04-003	MUST	This rule covers case creation where the sender proposes a duration and the CASE_OWNER's profile carries an embargo policy, its actor default (EP-01-001, CP-01-010). The CASE_MANAGER MUST make the shorter of the two the active embargo at once (EM ACTIVE). Two parties that propose 30 and 60 days respectively agree on days 1–30 and disagree only on days 31–60. Activating the shorter embargo immediately captures all mutual agreement. See docs/topics/process_models/em/formal_model.md § "Why the shortest proposal wins" for the full vector-agreement derivation.	Refines: EP-08-001 — EP-04-003 is the two-party case-creation instance of this ordering rule. Both MUST resolve earliest-end-date first, and both MUST share one comparator (#3392).
EP-04-016	SHOULD	This rule covers case creation where both the sender and the CASE_OWNER have an applicable embargo proposal (EP-04-003). The CASE_MANAGER SHOULD register the longer of the two as a pending revision (EM REVISE). The longer duration becomes a pending revision so the proposer can negotiate the contested portion. This is strictly better than rejecting it outright: both parties secure the overlap they both wanted.	Extends: EP-04-003
EP-04-004	MUST	A sender MUST be able to propose embargo terms when it submits a report. It carries a proposed EmbargoEvent, inline or by reference, as the proposedEmbargo of the Offer(VulnerabilityReport) activity. That EmbargoEvent carries the report URI as its context (EP-04-009). Without a way to state terms on the report, a sender with its own deadline can only take the receiver's default or negotiate after the case exists, and the shortest-wins comparison (EP-04-003) has no sender side to compare. The report Offer is the one message the sender sends before a case exists, so it carries the proposal, and the receiver's CaseProposal carries the Offer whole (CP-01-008), so the terms reach the CASE_MANAGER as the sender stated them.	Refines: EP-04-003
EP-04-017	MUST	At case creation, the CASE_MANAGER MUST rewrite the context of the sender's proposed EmbargoEvent (EP-04-004) from the report URI to the case URI. The context rewrite moves the terms onto the case once there is one, so the case's embargo is about the case like every other (EP-04-009).	Extends: EP-04-004
EP-04-005	MUST	A protocol default embargo duration MUST exist. The goal of the EM process is to lock in an embargo as early as possible (docs/topics/process_models/em/principles.md). Without a protocol default, a case with no embargo proposal and no actor default would have no embargo at all.
EP-04-018	MUST	The protocol default embargo duration MUST be no less than 72 hours and no more than 5 days. The 72-hour floor equals the default EP-07-002 minimum RSVP window, so the shortest embargo the protocol produces is as long as the shortest answer window it grants. The 5-day ceiling keeps a deployment from restoring a default generous enough to make publishing nothing better than publishing a policy.	Constrains: EP-04-005
EP-04-019	MUST	This rule covers an embargo-eligible case created with no embargo proposal and no actor default. The CASE_MANAGER MUST activate an embargo of the protocol default duration, so the case begins at EM.ACTIVE. A case with no embargo is the outcome the process exists to avoid, and reaching it through mutual silence is the least deliberate way to arrive there.	Extends: EP-04-005
EP-04-006	MUST NOT	The protocol default MUST NOT participate in the shortest-wins comparison of EP-04-003. It is the value applied when no proposal and no actor default applies, never a candidate within that comparison. A 72-hour protocol default that competed under shortest-wins would win against every longer proposal and cap every embargo in the system at 72 hours, so no longer embargo could ever be agreed. The protocol default answers "what if nobody said anything", not "whose terms are shortest". See ADR-0096.	Refines: EP-04-003
EP-04-007	MUST NOT	The CASE_MANAGER MUST NOT clamp a proposal or actor default that is shorter than the protocol default up to it. It honors that term at its stated duration. em/principles.md requires embargo duration be "limited to the shortest duration possible", and a Participant is free to set their own terms. EP-04-005's range bounds what the fallback may be configured to; it does not constrain what parties may agree. A reporter who proposes 12 hours gets 12 hours. See ADR-0096.
EP-04-008	MUST NOT	The CASE_MANAGER MUST NOT apply the protocol default to a case that is not embargo-eligible. Such a case has P, X or A set at creation. VP-06-001 already forbids proposing or accepting an embargo negotiation once the vulnerability is public, exploit code is public, or attacks are observed (EMB-01-002 is the accept half of the same prohibition). An embargo on an already-public vulnerability protects nothing, so the protocol default inherits that guard rather than bypassing it. See ADR-0096.	Refines: VP-06-001 Refines: EP-04-005
EP-04-020	MUST	When any of P, X or A is set at case creation, the CASE_MANAGER MUST leave the case at EM.NONE. VP-06-001 forbids proposing or accepting an embargo once the vulnerability is public, exploit code is public, or attacks are observed. An embargo on an already-public vulnerability protects nothing, so the case starts with none.	Refines: VP-06-001
EP-04-009	MUST	EmbargoEvent.context MUST identify the subject the embargo concerns: the report URI before a case exists, and the case URI afterwards. A proposal embedded on Offer(VulnerabilityReport) (EP-04-004) precedes the case, so the report is the only subject it can name. This gives pre-case embargo terms a representation without a pre-case embargo phase, which ADR-0096 declines.
EP-04-021	MUST NOT	A reader of EmbargoEvent.context MUST NOT assume it names a case without checking. The field is EmbargoEvent.context in vultron/core/models/embargo_event.py, typed NonEmptyString, and nothing validates it as a case reference. Before a case exists it holds a report URI (EP-04-009), so a reader that assumes a case would take a report URI for one.	Derives from: EP-04-009
EP-04-011	MUST	The pending revision that EP-04-016 registers at case creation MUST follow the same relay as any other revision proposal (EP-09). A revision registered in the CASE_MANAGER's store alone is invisible to the party whose terms won and unreachable by the owner: unindexed, the default selection cannot name it, and with no Invite nobody is asked to answer it. The creation-time revision is a revision like any other; the only thing special about it is who proposes it, and CM-24 already covers the CASE_MANAGER proposing on a participant's behalf.	Refines: EP-04-016 Depends on: EP-09-002 — The creation-time revision is relayed by the same rule as any other revision.
EP-04-024	MUST	The CASE_MANAGER MUST propose the creation-time revision (EP-04-011) on behalf of the party whose terms lost the shortest-wins comparison, with that party in attributedTo. The creation-time revision is a revision like any other; the only thing special about it is who proposes it, and CM-24 already covers the CASE_MANAGER proposing on a participant's behalf. The party whose terms lost is the proposer and is not invited (EP-09-002).	Part of: EP-04-011
EP-04-025	MUST	The CASE_MANAGER MUST commit the creation-time revision (EP-04-011) as a proposal entry. The committed relayed Invite is that entry, and the CASE_MANAGER commits no separate proposal entry. No proposal activity exists at creation, so the committed relayed Invite is itself the proposal entry. A second entry would record one proposal twice.	Part of: EP-04-011
EP-04-026	MUST	The CASE_MANAGER MUST record the creation-time revision (EP-04-011) in the open-proposal record, so that the owner's default selection (EP-08-002) can reach it. A revision registered in the CASE_MANAGER's store alone is unreachable by the owner: unindexed, the default selection cannot name it.	Part of: EP-04-011 Depends on: EP-08-002 — Indexing the revision is what lets the default selection reach it.
EP-04-027	MUST	The CASE_MANAGER MUST relay the creation-time revision (EP-04-011) as an Invite(EmbargoEvent) to the party whose terms won. A revision registered in the CASE_MANAGER's store alone is invisible to the party whose terms won, and with no Invite nobody is asked to answer it.	Part of: EP-04-011

Revision Activation Consent Rule

ID	Priority	Requirement	Related
EP-05-001	MUST NOT	This rule covers the Case Owner's activation of a revised embargo that ends later than the embargo it replaces (REVISE → ACTIVE). The CASE_MANAGER MUST NOT carry any participant's consent over to it. A participant who signed for terms T1 has not consented to longer terms T2; treating them as a signatory once T2 is in force would imply consent they never gave. A participant is bound by the revised embargo only through an AGREED consent row for it, so each signatory to the replaced embargo that has not agreed to the revised one has lapsed (CM-18-001), and no write is needed to lapse them. The rule applies at activation rather than at proposal because the participant remains bound by T1 for as long as T1 is the active embargo (ADR-0093, ADR-0122).	Implements: CM-18-001
EP-05-003	MUST	This rule covers the Case Owner's activation of a revised embargo that ends no later than the one it replaces. The CASE_MANAGER MUST apply CARRY_OVER to the revised embargo's row of each participant with an AGREED row for the replaced embargo. That includes a participant whose row for the revision is DECLINED (CM-10-001, CM-18-003, MSM-07-019). Shorter terms ask nothing new: agreeing to N days is agreeing to every shorter period, the same containment that makes shortest-wins (EP-04-003) safe without asking anyone, so their agreement is carried over by writing the row. That holds for a participant that declined the shorter revision too: its decline objected to losing time, not to keeping the embargo, and the decline stays in the ledger (ADR-0122).	Implements: CM-18-001
EP-05-002	MUST NOT	A revision proposal (ACTIVE → REVISE) and any further counter-revision (REVISE → REVISE) MUST NOT change any participant's consent to the embargo in force. The proposer's row for the proposed embargo becomes AGREED (MSM-07-022). Every other participant gets an UNINVITED row for it (CM-18-001). Every other row stays as it is until the Case Owner activates a revision (EP-05-001, EP-05-003). Until then the prior embargo stays in force, and every signatory to it remains one. A participant cannot lapse until the embargo on the case differs from the one they agreed to. Lapsing on proposal would strand signatories when the revision is rejected, report participants who are still bound and still receive embargoed content as not bound, and lapse the proposer of the revision (ADR-0093). With per-embargo rows a proposal only ever adds rows for the proposed embargo.	Refines: EP-05-001

PEC Idempotency

ID	Priority	Requirement	Related
EP-06-001	MUST NOT	An idempotent retry or re-processing of a participant add-or-update MUST NOT remove or downgrade any consent row. That covers each row that has left UNINVITED for INVITED, AGREED, DECLINED or TIMED_OUT. Dropping an AGREED or DECLINED row on retry silently revokes or erases consent that was already given. The positive-path idempotency rule (don't double-add) is covered by CM-13-005; this rule covers the negative path (don't downgrade).	Refines: CM-13-005 Implements: CM-18-001

Embargo Invite RSVP Window Policy

Policy requirements for the embargo invite RSVP window: the fallback default when no deadline is on the wire, the minimum permitted window, and the clamp-on-receipt rule that neutralises coercively short deadlines. Codified by ADR-0065. Source: IDEA-2066.

ID	Priority	Requirement	Related
EP-07-001	MUST	When an Invite(EmbargoEvent) carries no Invite.end_time, an implementation MUST apply a default RSVP window, measured from the invitation's published timestamp. An invitation with no deadline would leave the invitee's consent row INVITED for ever. A default window gives every invitation an end, so silence resolves. See ADR-0065.	Implements: CM-28-002
EP-07-009	SHOULD	The default RSVP window of EP-07-001 SHOULD be 7 days, matching CM-18-002. Aligning the fallback with the CM-18-023 policy window means an invitation that omits end_time gets the same answer window as the policy grants. See ADR-0065.	Extends: EP-07-001
EP-07-002	MUST	An inviting actor MUST set each Invite(EmbargoEvent)'s Invite.end_time at least the minimum RSVP window after the invitation's published timestamp. The minimum is the lesser of a fixed window and the time remaining in the embargo. An unbounded-downward deadline weaponises the mechanism: a one-minute RSVP window formally invites a participant while guaranteeing they cannot answer, excluding them with the appearance of due process. See ADR-0065.	Refines: EP-07-006
EP-07-010	SHOULD	The fixed window of the minimum RSVP window (EP-07-002) SHOULD be 72 hours. Seventy-two hours gives an invitee a realistic chance to answer across time zones and weekends, and it equals the floor of the protocol default embargo (EP-04-018). See ADR-0065.	Extends: EP-07-002
EP-07-003	MUST	When a receiving actor receives an Invite(EmbargoEvent) whose Invite.end_time is earlier than the applicable minimum window, it MUST clamp the effective deadline up to that minimum. The applicable minimum is the one computed by EP-07-002, so the clamp never raises the deadline past the embargo's own end. Clamping makes a coercive deadline ineffective rather than fatal. Rejecting the invitation outright would hand the sender exactly what a hostile sender wants — an invite that never takes effect — and would punish the invitee for the inviter's misbehaviour. See ADR-0065.	Refines: EP-07-002
EP-07-006	MUST NOT	An RSVP deadline MUST NOT fall after the end of the embargo it concerns. An invitee must be able to answer while the embargo still exists. A deadline past the embargo's end asks the invitee to consent to an embargo that is already over, and records its silence as an expiry after the answer stopped mattering. See ADR-0096.	Constrains: CM-18-023
EP-07-011	MUST	When a computed RSVP deadline would fall after the embargo's end_time, the actor that computes it MUST clamp it down to that end_time. This holds for a deadline from an explicit Invite.end_time and from the CM-18-002 policy window alike. Clamping is how a deadline is kept within the embargo (EP-07-006) without refusing the invitation: the invitee can still answer while the embargo exists.	Implements: EP-07-006
EP-07-004	MUST NOT	A receiving actor MUST NOT reject an Invite(EmbargoEvent) as malformed solely on the basis of a sub-minimum deadline. Rejecting the invitation would hand a hostile sender exactly what they want — an invite that never takes effect — and punishes the invitee for the inviter's misbehaviour.	Refines: EP-07-003

Open Proposal Resolution Order

How a Participant resolves two or more simultaneously open embargo proposals: earliest expiration first, with the remainder handled as revisions. Codified by ADR-0100, which also records why there is no multi-candidate poll activity. The heuristic itself predates this group as normative prose in docs/topics/process_models/em/defaults.md; stating it here is what makes it testable. Source: CONCERN-3433.

ID	Priority	Requirement	Related
EP-08-001	SHOULD	This rule covers a case with two or more open embargo proposals and none accepted. A Participant SHOULD accept the proposal whose embargo end_time is earliest, and propose the remainder as revisions. Two parties proposing 30 and 60 days agree on days 1–30 and disagree only beyond that, so accepting the shorter proposal captures all mutual agreement immediately and leaves the contested remainder to negotiate as a revision. This is the Shortest Embargo Proposed Wins heuristic stated in docs/topics/process_models/em/defaults.md, derived in docs/topics/process_models/em/formal_model.md, and applied to case growth in docs/topics/process_models/em/working_with_others.md.
EP-08-005	SHOULD	This rule covers two or more revisions open against an active embargo. A Participant SHOULD accept or reject them one at a time, in earliest-to-latest end_time order. Taking revisions shortest first applies the Shortest Embargo Proposed Wins heuristic (EP-08-001) to revisions: each accepted revision captures the agreement the longer ones also contain.	Extends: EP-08-001
EP-08-002	MUST	This rule covers a selection among two or more open embargo proposals where the caller supplied no proposal identifier. The implementation MUST select the earliest-expiring open proposal, never the first by insertion or arrival order. A counter-proposal is emitted while the EM state remains PROPOSED (EMB-15-003), so arrival order places the superseded terms first. Selecting by arrival therefore accepts the terms the counter-proposal was sent to replace, which inverts EP-08-001 in exactly the situation that makes a default selection necessary.	Refines: EP-08-001
EP-08-004	MUST	When an embargo terminates (EM ACTIVE or REVISE → EXITED), the implementation MUST close every open proposal, cancelling it in the same embargo register step that terminates the embargo (ADR-0122), not only the entry for the terminated embargo itself. Every proposal open while EM is ACTIVE or REVISE is a revision of the active embargo, and a revision of an embargo that no longer exists cannot be accepted. A case has at most one active embargo (VP-04-002), so while EM is ACTIVE or REVISE every open proposal is by construction a revision of that embargo; no field linking a revision to the embargo it revises is needed to know which proposals a termination decides. EP-08-003's text reaches the terminated embargo; this entry reaches the proposals about it.	Refines: EP-08-003 Depends on: VP-04-002 — One active embargo at a time is what makes every open proposal a revision of it.

Embargo Negotiation Relays Through the CASE_MANAGER

How an embargo proposal — the first one for a case or a revision of the active embargo — reaches every participant and every replica in the CASE_MANAGER topology. The behavioural specs (EMB-01 through EMB-06) are written in the voice of the formal protocol, in which every Participant is a peer and every Participant "receives EP" or "receives EV". Here a participant addresses its proposal to the CASE_MANAGER alone (PCR-08-001), so the Participant receiving EP or EV is the CASE_MANAGER on receipt, and every other participant learns the resulting case state from the ledger. The protocol interactions the behavioural specs define still happen: the CASE_MANAGER relays the proposal to the participants as an Invite, they answer the CASE_MANAGER, and the owner's answer decides. Each step is recorded in the ledger. Ledger entries carry case state to replicas and set no parse-and-respond expectation; they augment the negotiation as the record of the case, they do not replace it. Decided by ADR-0113 from Concerns #3892, #3836 and #3863 for revisions; generalised to every proposal, with the acknowledgement, RSVP-deadline, trigger-side write and invitee rules below, by its 2026-09-30 amendment from Concern #3918.

ID	Priority	Requirement	Related
EP-09-001	MUST	This rule covers the CASE_MANAGER's receipt of an Invite(EmbargoEvent) for a case whose CS state is not yet public, exploit or attack. The CASE_MANAGER MUST move the canonical case's EM state and commit the proposal as a ledger entry. The move is EM NONE → PROPOSED for the first proposal and ACTIVE → REVISE for a revision. If the CASE_MANAGER does not move the canonical case on receipt, its record never shows that a revision is under negotiation when a non-owner proposes one, and everything keyed on EM.REVISE runs only in the proposer's store. The CASE_MANAGER is the sole writer of canonical case state (ADR-0108); if it does not move the case, no replica can.	Implements: EMB-01-001 Implements: EMB-03-001 Depends on: EMB-18-001 — The EM write goes through EmbargoLifecycle, never a direct assignment. Depends on: RSH-08-003
EP-09-020	MUST	This rule covers the CASE_MANAGER's receipt of a counter-proposal Invite(EmbargoEvent) for a case already at EM PROPOSED or REVISE. The CASE_MANAGER MUST commit the proposal with no further EM transition. A counter-proposal adds terms to a negotiation already open, so the EM state that says a negotiation is open already holds. Committing it still puts the proposal on the ledger, where every replica learns of it.	Implements: EMB-01-003 Implements: EMB-03-002 Depends on: RSH-08-003
EP-09-021	MUST	When the CASE_MANAGER receives an Invite(EmbargoEvent) for a case whose CS state is public, exploit or attack, it MUST refuse the proposal (EMB-01-002, EMB-03-003). An embargo on a vulnerability that is already public, exploited or attacked protects nothing (VP-06-001), so the CASE_MANAGER does not open a negotiation for one.	Implements: EMB-01-002 Implements: EMB-03-003 Implements: EMB-03-004
EP-09-002	MUST	After committing a revision proposal, the CASE_MANAGER MUST emit an Invite(EmbargoEvent) for the revision to each case participant whose RM state is not RM.CLOSED. The proposer and the executing CASE_MANAGER itself get none. Each Invite has actor set to the CASE_MANAGER's ID and attributedTo set to the proposer's ID (CM-24-001, CM-24-002). Participants answer only an Invite addressed to them (EP-09-003), so without the relay nobody but the proposer would be asked. Proposing terms is consenting to them (ADR-0093), so the proposer is not invited. The CASE_MANAGER is the Case Owner's delegate that routes communications and manages ledger entries, with no view of its own on the embargo, and a container never mails an actor it hosts (ADR-0109).	Refines: CM-24-001 Refines: CM-24-002 Depends on: PCR-08-007 — The same relay shape as the case Invite.
EP-09-022	MUST	The CASE_MANAGER MUST commit each Invite emission of EP-09-002 as a ledger entry once the Invite is in the outbox (SYNC-09-002). The committed emission is how every replica learns who was asked, and committing only after the outbox write keeps the ledger from recording an Invite that was never sent.	Extends: EP-09-002
EP-09-023	MUST	At the commit of a revision proposal, the CASE_MANAGER MUST write the proposer's consent row for the proposed embargo as AGREED. Proposing terms is consenting to them (ADR-0093), so the proposer is not invited, and its row records that consent instead.	Extends: EP-09-002
EP-09-024	MUST	This rule covers an actor that holds the CASE_MANAGER role but not CASE_OWNER. It also has an embargo stake of its own, through a role beyond CASE_MANAGER and COORDINATOR. At the commit of a revision proposal, the CASE_MANAGER MUST write that actor's own row for the proposed embargo. The row is AGREED when the actor is the proposer. Otherwise the actor's own embargo-proposal policy decides AGREED or DECLINED (EMB-15-001). The CASE_MANAGER relays the Invite and never mails an actor it hosts (ADR-0109), so a stakeholder that holds the role would never be asked.	Extends: EP-09-002
EP-09-003	MUST NOT	A participant that receives an Invite(EmbargoEvent) MUST NOT write case EM state or any participant's consent state on receipt. It stores the Invite and answers it with Accept or Reject addressed to the CASE_MANAGER through its response decision (EMB-15). Only the CASE_MANAGER turns an announcement into case state and every other participant takes case state from the ledger (ADR-0108, RSH-08-003). Consent is recorded when the CASE_MANAGER commits the answer, and the replica learns it from the ledger.	Refines: RSH-08-003 Depends on: PCR-08-003 — The fan-out is the only mechanism by which participants learn accepted state.
EP-09-025	MUST NOT	A participant MUST NOT treat an Announce(CaseLedgerEntry) that carries a proposal or an Invite as an invitation to answer. A participant answers only an Invite addressed to it. The ledger is a channel for case state, not a protocol interaction. Giving an entry parse-and-respond semantics would let every future entry type become an implicit request, and would fork the negotiation into two paths, one over Invites and one over entries. The interactions the behavioural specs define are the ones that happen; the ledger records them.	Depends on: PCR-08-003 — The fan-out is the only mechanism by which participants learn accepted state.
EP-09-004	MUST NOT	A revision Invite(EmbargoEvent) MUST NOT change the consent of a participant that is already a signatory to the active embargo. The PEC INVITE trigger is applied to the participant's row for the revision (CM-18-003), so a signatory's row for the revision moves from UNINVITED to INVITED and it keeps its AGREED row for the active embargo; its answer to the revision is recorded on the revision's row and binds it to nothing new until the owner activates the revision (EP-05-001, EP-05-002). A signatory is bound by the active embargo for as long as it is active; a proposal to revise it asks nothing of them yet (ADR-0093). Because consent is per embargo (ADR-0122) the Invite lands on its own row and cannot touch the row that binds the signatory, so a receive tree that applies INVITE for every recipient does not fault on exactly the participants a revision most concerns.	Refines: EP-05-002 Depends on: CM-18-003
EP-09-005	MAY	The Case Owner MAY accept or reject an open revision at any time, without waiting for any other participant to answer the revision Invite. The owner's Accept(EmbargoEvent)[target=VulnerabilityCase] activates the revision and the owner's Reject(EmbargoEvent)[target=VulnerabilityCase] keeps the prior terms (MSM-07-008, MSM-07-009); either is committed as a ledger entry and decides the embargo. The owner's Accept or Reject of the revision Invite is only its own consent (MSM-07-003, MSM-07-004). Only the Case Owner's answer changes the embargo on the case; the other participants' answers inform that decision, they do not make it (ADR-0093). The Invites are not a vote: they gather the consent records the activation cascade reads (EP-05-001). The owner's decision settles the embargo; the answers settle who is bound by it.
EP-09-006	SHOULD	The Case Owner SHOULD wait for at least some participants to answer a revision Invite before accepting or rejecting the revision, so as to gauge consensus (VP-08-003). The protocol defines no quorum, no vote and no waiting period; which answers, how many and how long are actor policy. Consensus on embargo terms is the protocol's stated norm (VP-08-003), and "quorum" is deliberately undefined so that different CVD communities can adopt different decision rules (VP-09-007). A fixed threshold here would take that room away. Leaving it to actor policy makes the waiting decision a natural call-out point rather than a rule.	Refines: VP-08-003 Depends on: VP-09-007 — VP-09-007's rationale is where the protocol leaves "quorum" undefined; it stays undefined here too.
EP-09-008	MUST	Shared EM state covers proposing, accepting, rejecting or terminating an embargo. An actor acting on its own initiative MUST write it only when it holds the CASE_MANAGER role for the case. EP-09-017 says what an actor without the role does instead. An actor that writes its own EM state before the CASE_MANAGER has answered, then declares that state to the manager, is left wrong when the manager refuses: nothing corrects the write, so a proposer's replica can sit at PROPOSED while the canonical case never moves. The manager is the one writer of shared case state (ADR-0108); a participant's replica of it comes from the ledger like everyone else's.	Depends on: EP-09-007 Depends on: SYNC-11-002 Depends on: BT-17-001 Refines: RSH-08-003 — The receive-side rule, applied to the trigger side for shared EM state.
EP-09-017	MUST	This rule binds an actor acting on its own initiative without the CASE_MANAGER role. It MUST send its embargo activity to the CASE_MANAGER, write no EM state, and declare no EM state. Its replica moves when the CASE_MANAGER's commit is announced (EP-09-007). The CASE_MANAGER's Reject of a refused proposal answers the activity. So does its Reject of the Invite to an Accept it refuses once P/X/A is set (EMB-02-004). A participant takes a Reject(Invite(EmbargoEvent)) from the CASE_MANAGER and from nobody else (PCR-08-001, HP-01-006). The CASE_MANAGER is the one writer of shared case state (ADR-0108), so an actor without the role asks it instead of writing. A write made before the CASE_MANAGER answers is left wrong when the CASE_MANAGER refuses, and a declaration of that state spreads the error. The CASE_MANAGER's answer is the only one a participant takes, so a refusal always reaches the actor that asked.	Refines: EP-09-008 Depends on: EP-09-007
EP-09-009	MUST NOT	The CASE_MANAGER's commit of a received embargo activity, fanned out as Announce(CaseLedgerEntry), is the acknowledgement the EMB behavioural requirements express as "emit EK". Implementations MUST NOT define or emit an EK message to acknowledge an embargo activity. No EK exists in the production stack and MSM-02-009 records that its purpose is served by ledger hash-chain continuity. Under the relay every accepted embargo activity is committed and announced, so the record the specs want the receiver to produce already exists; a second acknowledgement would be a message with no reader (#3918).	Refines: MSM-02-009 Implements: EMB-09-001
EP-09-010	MUST	The invitee of an Invite(EmbargoEvent) is its sole to recipient. A receiving actor MUST resolve the invitee from that single recipient, not from the receiving actor. Every emitter sends a single-recipient Invite, a participant to the CASE_MANAGER and the CASE_MANAGER to one participant per relayed Invite (EP-09-002). Inferring the invitee from the receiving actor puts the RSVP deadline on the enforcer's own record instead of the invitee's.	Depends on: EP-09-002
EP-09-026	MUST	A receiving actor MUST refuse an Invite(EmbargoEvent) that names no to recipient or more than one, as a misrouting (OX-08-001). Every emitter sends a single-recipient Invite (EP-09-010), so an Invite with no recipient or several is a defect, not a shape to interpret. Refusing names the defect; guessing hides it.	Extends: EP-09-010
EP-09-011	MUST	When the CASE_MANAGER admits a participant (Accept(Invite(Actor)[target=VulnerabilityCaseStub])) while an embargo proposal is open, it MUST relay an Invite(EmbargoEvent) for every open proposal to the joiner and commit each as a ledger entry, after the joiner holds the case and the prior ledger. Each Invite has actor set to the CASE_MANAGER's ID and attributedTo set to the proposal's original proposer (EP-09-002). A proposal whose consent row for the joiner has already left UNINVITED is not relayed again. Every participant holds a row for every register entry (CM-18-001). The row's state, not its presence, says whether the joiner was asked. The joiner's row for the active embargo is unchanged (EP-09-004), so a joiner that accepts the revision is a signatory of it at activation and one that does not lapses (ADR-0093, EP-05-001). A joiner is seated after the relay of a proposal (EP-09-002), so it was never on the roster when the Invite went out, and nothing else would ask it. A new participant becomes a signatory to the embargo in effect when it joins, and is asked about a revision on the table exactly like the participants who were present when it was proposed.	Refines: EP-09-002 Depends on: CM-11-001
EP-09-012	MUST	This rule covers a participant whose consent row for the embargo of an Invite(EmbargoEvent) it received is INVITED or TIMED_OUT (CM-18-001). The participant MUST be able to answer that Invite with Accept or Reject after its embargo has become the embargo in force, as before. The answer names the Invite it answers. Activation takes a proposal out of the record of open proposals (EP-08-003), so a participant relayed the proposal (EP-09-011) that had not answered when it was activated, or whose reply deadline has since passed (EMB-17), can no longer answer it as an open proposal. The receive side already honours the answer (MSM-07-003, EMB-17-002).	Constrains: EP-08-002 Depends on: MSM-07-003 Depends on: EMB-17-002
EP-09-027	MUST NOT	A participant MUST NOT answer an Invite(EmbargoEvent) whose consent row is in any state other than INVITED or TIMED_OUT. A row that is AGREED or DECLINED already holds an answer, and an UNINVITED row was never asked. Withdrawing from the embargo in force from an AGREED row is not an answer and has its own message (EP-09-013).	Extends: EP-09-012
EP-09-013	MUST	A participant whose consent row for the embargo in force is AGREED MUST be able to withdraw from that embargo. It sends Leave(EmbargoEvent), naming the embargo in force, to the CASE_MANAGER (MSM-07-010, PCR-08). A withdrawal needs no Invite. An Accept or a Reject is never a withdrawal from the embargo in force. VP-13-017 lets a participant end its own compliance at any time, and VP-13-008 asks that it say so. A signatory made by seeding (CM-14-005) or by joining (CM-11-001) holds no Invite(EmbargoEvent) for the embargo in force, but every participant holds the embargo itself, so a withdrawal names the embargo, not an Invite.	Depends on: MSM-07-010 Refines: VP-13-017
EP-09-028	MUST NOT	This rule covers a participant with no embargo in force, one whose row for that embargo is not AGREED, and the Case Owner. Each MUST NOT send Leave(EmbargoEvent) to withdraw. With no embargo in force there is nothing to withdraw from, and a participant whose row is not AGREED is not bound by the embargo. The Case Owner ends an embargo by terminating it (MSM-07-036), not by withdrawing from it.	Extends: EP-09-013

Duration

Requirements for a canonical representation of time durations independent of start/end timestamps. Applicable wherever a duration must be exchanged in JSON, such as embargo policy records and embargo initialization at case creation.

Representation Format

ID	Priority	Requirement	Related
DUR-01-001	MUST	Durations MUST be represented as ISO 8601 duration strings using the P[n]DT[n]H[n]M[n]S format Participants exchange durations across independent implementations, so they need a format every stack already parses the same way. ISO 8601 durations have libraries in every common language and carry their units in the string; a private format would need every implementer to agree on its grammar separately.
DUR-01-002	MUST	Duration strings MUST be serialized as JSON strings, not as numbers A JSON number carries no unit, so 30 could mean seconds, hours or days, and two receivers could read different embargo lengths from the same record. A string in the DUR-01-001 format states its units, so the value means one thing to every reader.
DUR-01-003	MUST	Durations represent absolute elapsed time, not calendar-relative intervals; P1D means exactly 86400 seconds, with no DST or calendar adjustment implied An embargo ends at one instant for every participant. If P1D meant a calendar day, a duration that spans a daylight-saving change would end an hour earlier or later depending on the time zone it was computed in, and participants in different zones would disagree on when disclosure is allowed.

Allowed Grammar (Restricted ISO 8601 Subset)

ID	Priority	Requirement	Related
DUR-02-001	MUST	Only the following units are permitted in duration strings: days (D), hours (H), minutes (M, time-part only), and seconds (S). Each of these units has a fixed length in seconds, so every implementation computes the same end time from the same string. The list is closed so that a receiver can reject anything else (DUR-04-001) rather than guess at its length.
DUR-02-002	MUST NOT	The following units MUST NOT appear in Vultron duration strings because they introduce calendar ambiguity: years (Y), months (M, date-part), and weeks (W). A year is 365 or 366 days depending on leap year; a month is 28, 29, 30, or 31 days; a week is 5 business days or 7 calendar days depending on context. These variable lengths make duration arithmetic non-deterministic across implementations. ISO 8601 day-based durations (e.g., P90D) represent an exact number of 86400-second intervals and are unambiguous.

Canonical Form

ID	Priority	Requirement	Related
DUR-03-001	SHOULD	Duration strings SHOULD be normalized to a canonical form: prefer the largest unit without remainder One duration can be written several ways (P1D, PT24H, PT1440M), so two records that hold the same value can fail a plain string comparison or show a spurious change in a diff. One preferred spelling lets readers compare strings and lets a person read the value at a glance.
DUR-03-002	SHOULD	An embargo policy duration SHOULD use whole-day units only, where it can. Embargo terms are negotiated and compared in days, and policy ranges are read by people as well as code. A whole number of days compares against a policy range at a glance.
DUR-03-004	SHOULD NOT	An embargo policy duration SHOULD NOT mix day and time units, as in P29DT23H. A mixed value such as P29DT23H is hard to compare against a policy range at a glance, and it usually signals an arithmetic leftover rather than an intended term.	Extends: DUR-03-002
DUR-03-003	SHOULD NOT	P0D SHOULD NOT be used to express a zero-length duration; prefer PT0S for explicitness A zero duration needs one spelling so that equal values compare equal as strings. PT0S is the form a zero timedelta serializes to (DUR-05), so a zero value written and read back keeps the same spelling.

Validation Requirements

ID	Priority	Requirement	Related
DUR-04-001	MUST	Implementations MUST reject duration strings containing disallowed units: Y, date-part M, W A duration with a year, month or week unit has no fixed length (DUR-02-002), so two receivers that accept it can compute different embargo end dates from the same message. Rejecting it at the edge exposes the disagreement before any participant acts on its own reading.
DUR-04-002	MUST	Implementations MUST reject malformed ISO 8601 duration strings A malformed duration that a receiver accepts with a guessed meaning sets an embargo length that nobody proposed. Rejecting it at parse time keeps the bad value out of the core and tells the sender its message was not understood.
DUR-04-003	MUST	Implementations MUST reject empty duration strings ("P" or "PT") P and PT match the start of the grammar but state no length. A parser that read them as zero would turn a missing value into an embargo that ends the moment it starts.
DUR-04-004	MUST	A valid duration MUST contain at least one component Each ISO 8601 component is optional on its own, so without this rule the grammar admits a duration that states no length at all. A reader would then have to guess one, and the obvious guess, zero, ends an embargo at its start.

Interval Composition

ID	Priority	Requirement	Related
DUR-06-001	MUST	A duration-only embargo policy field MUST be interpreted as a relative offset from a context-specific anchor (typically case creation time) A duration alone has no position in time. Without a named anchor, two participants could apply the same policy to different start points, such as report receipt, case creation or the moment they read it, and hold different embargo end dates.
DUR-06-002	MUST	When combined with a start timestamp, the end time is end = start + duration Plain addition with no calendar adjustment (DUR-01-003) is the one rule every implementation computes identically, so a start time and a duration give every participant the same end instant.
DUR-06-003	MUST	A timestamp used in interval composition MUST conform to RFC 3339. A timestamp without an offset is read in each participant's local zone, so the same start time names different instants on different servers. An RFC 3339 timestamp carries its offset, so every participant reads the same instant.
DUR-06-004	SHOULD	An implementation SHOULD compose intervals in UTC, not in a local time zone. Local time zones shift for daylight saving, so the same start and duration can give different end instants on different servers. UTC has no such shift, so every participant computes the same end instant.	Extends: DUR-06-003

Embargo Duration Semantics

ID	Priority	Requirement	Related
DUR-07-001	MUST	Specific embargo end times on cases MUST be declared as event intervals with unambiguous start and end timestamps, not as durations alone An embargo on a case is a commitment to a disclosure date that every participant must agree on. A duration alone depends on an anchor each participant might read differently and on when it is read, while explicit start and end timestamps name the same instants for everyone.
DUR-07-002	SHOULD	At case creation (RM.RECEIVED), if no embargo end time is established, the case creation process SHOULD apply the actor's default embargo duration (from the actor profile) to the case creation timestamp to establish the initial embargo end time A case with no embargo end has no agreed disclosure date, and the EM process exists to lock in an embargo as early as possible. The receiving actor's published default is the terms it has already declared it will accept, so applying it at creation gives the case an embargo without a negotiation round.
DUR-07-003	MUST	When a default embargo duration is applied at case creation, the case's resulting EM state MUST be EM.ACTIVE, not EM.PROPOSED (EP-04-001). The default applies only when the sender submitted no terms of its own, which is tacit acceptance of the default (EP-04-001), so nobody is left to accept it. A case left at EM.PROPOSED would wait for an answer that nobody owes, with no embargo in force while it waits.
DUR-07-004	MUST	An embargo end time MUST be established before an embargo-eligible case (none of P, X or A set) transitions to RM.VALID. Once a report is valid, coordination begins and other parties are brought into the case. An embargo end set before that point means every participant joins under a known disclosure date instead of sharing vul details with no agreed date in force. A case with P, X or A set is exempt and is validated with no embargo, at EM.NONE when P, X or A was set at creation. It can never receive a new embargo (EP-04-008, VP-06-001), so requiring one would block RM.VALID.	Depends on: DUR-07-002

CVD Case State Behavioral Requirements

Event-Condition-Action behavioral requirements for CVD Case State (CS) transitions. Each group is triggered by either a received CS message or a local CS state transition, and specifies typed preconditions, ordered steps, and postconditions that implementations must satisfy. CS cascade chains that trigger embargo teardown reference EM behavior directly and are developed in concert with the EM behavioral requirements.

Receive CV (Vendor Aware)

Behaviors triggered when a participant receives a CV (Vendor Aware) message, updating the sender's CS state model to reflect vendor awareness of the vulnerability.

Trigger: Message Received — CV

ID	Priority	Requirement	Related
CSB-01-001	MUST	A Participant in a non-Closed RM state (q^rm ∉ C) receiving CV MUST update their model of the sending Participant's CS state to Vendor Aware (q^cs ∈ Vfd···). No CK message is emitted (MSM-03-008). The CASE_MANAGER's commit of the received activity, fanned out as Announce(CaseLedgerEntry), records it. Each replica acknowledges that entry by its unbroken hash chain (MSM-05-002). CV announces a Vendor-specific CS transition. The receiver does not change their own CS state; they update their awareness model for the sender. ECA Details Preconditions - Participant is in an active RM state (Received/Invalid/Valid/Deferred/Accepted) - RM state: RECEIVED, INVALID, VALID, DEFERRED, ACCEPTED Steps 1. [receiver] Update model of sender's CS state to Vendor Aware (Vfd···) — receiver's own CS state is unchanged → Receiver's awareness model for sender reflects CS=Vfd 2. [receiver] CASE_MANAGER commits the received CV and announces the ledger entry (discharges CK) → Ledger entry committed and fanned out; no CK message exists Postconditions - Sender's CS state recorded as Vfd; CK discharged by the ledger commit; receiver CS unchanged	Satisfies: MSM-03-001 — CV shorthand wire-type mapping

Receive CF (Fix Ready)

Behaviors triggered when a participant receives a CF (Fix Ready) message, updating the sender's CS state model to reflect that a fix is ready.

Trigger: Message Received — CF

ID	Priority	Requirement	Related
CSB-02-001	MUST	A Participant in a non-Closed RM state (q^rm ∉ C) receiving CF MUST update their model of the sending Participant's CS state to Fix Ready (q^cs ∈ VFd···). No CK message is emitted (MSM-03-008). The CASE_MANAGER's commit of the received activity, fanned out as Announce(CaseLedgerEntry), records it. Each replica acknowledges that entry by its unbroken hash chain (MSM-05-002). CF announces a Vendor-specific CS transition. The receiver does not change their own CS state; they update their awareness model for the sender. ECA Details Preconditions - Participant is in an active RM state (Received/Invalid/Valid/Deferred/Accepted) - RM state: RECEIVED, INVALID, VALID, DEFERRED, ACCEPTED Steps 1. [receiver] Update model of sender's CS state to Fix Ready (VFd···) — receiver's own CS state is unchanged → Receiver's awareness model for sender reflects CS=VFd 2. [receiver] CASE_MANAGER commits the received CF and announces the ledger entry (discharges CK) → Ledger entry committed and fanned out; no CK message exists Postconditions - Sender's CS state recorded as VFd; CK discharged by the ledger commit; receiver CS unchanged	Satisfies: MSM-03-002 — CF shorthand wire-type mapping

Receive CD (Fix Deployed)

Behaviors triggered when a participant receives a CD (Fix Deployed) message, updating the sender's CS state model to reflect that a fix has been deployed.

Trigger: Message Received — CD

ID	Priority	Requirement	Related
CSB-03-001	MUST	A Participant in a non-Closed RM state (q^rm ∉ C) receiving CD MUST update their model of the sending Participant's CS state to Fix Deployed (q^cs ∈ VFD···). No CK message is emitted (MSM-03-008). The CASE_MANAGER's commit of the received activity, fanned out as Announce(CaseLedgerEntry), records it. Each replica acknowledges that entry by its unbroken hash chain (MSM-05-002). CD announces a Vendor-specific CS transition. The receiver does not change their own CS state; they update their awareness model for the sender. ECA Details Preconditions - Participant is in an active RM state (Received/Invalid/Valid/Deferred/Accepted) - RM state: RECEIVED, INVALID, VALID, DEFERRED, ACCEPTED Steps 1. [receiver] Update model of sender's CS state to Fix Deployed (VFD···) — receiver's own CS state is unchanged → Receiver's awareness model for sender reflects CS=VFD 2. [receiver] CASE_MANAGER commits the received CD and announces the ledger entry (discharges CK) → Ledger entry committed and fanned out; no CK message exists Postconditions - Sender's CS state recorded as VFD; CK discharged by the ledger commit; receiver CS unchanged	Satisfies: MSM-03-003 — CD shorthand wire-type mapping

Receive CP (Public Aware)

Behaviors triggered when a participant receives a CP (Public Aware) message, recording public disclosure of the vulnerability and initiating embargo teardown if an active embargo exists.

Trigger: Message Received — CP

ID	Priority	Requirement	Related
CSB-04-001	MUST	A Participant in a non-Closed RM state (q^rm ∉ C) with CS not yet public (q^cs ∈ ···p··) and EM None or Exited (q^em ∈ {N, X}) receiving CP MUST transition their local CS to Public Aware (q^cs ···p·· → ···P··) and emit CK to acknowledge receipt. CP is a global (participant-agnostic) CS transition. All receivers must update their own CS state. When EM is None or Exited, no embargo teardown is needed. ECA Details Preconditions - EM state is None or Exited; CS matches pattern ...p.. - EM state: NONE, EXITED - CS pattern: ...p.. Steps 1. [receiver] Transition local CS to Public Aware (···P··) → Receiver CS public bit set to P 2. [receiver] Emit CK to acknowledge receipt of CP → CK queued for sender Postconditions - Receiver CS is public-aware; CK emitted	Satisfies: MSM-03-004 — CP shorthand wire-type mapping
CSB-04-002	MUST	A Participant in a non-Closed RM state (q^rm ∉ C) with CS not yet public (q^cs ∈ ···p··) and EM Proposed (q^em ∈ P) receiving CP MUST transition their local CS to Public Aware. Public awareness terminates a pending embargo proposal per VP-09-001. The embargo cannot be negotiated once the information is public (VP-06-001). ECA Details Preconditions - EM state is Proposed; CS matches pattern ...p.. - EM state: PROPOSED - CS pattern: ...p.. Steps 1. [receiver] Transition local CS to Public Aware (···P··) → Receiver CS public bit set to P 2. [receiver] Transition EM from PROPOSED to NONE (embargo proposal abandoned) → Receiver EM state is NONE 3. [receiver] Emit CK to acknowledge receipt of CP → CK queued for sender Postconditions - Receiver CS is public-aware; EM is NONE; CK emitted	Satisfies: VP-09-001 — Embargoes SHALL terminate immediately when information becomes public Satisfies: MSM-03-004 — CP shorthand wire-type mapping
CSB-04-003	MUST	A Participant in a non-Closed RM state (q^rm ∉ C) with CS not yet public (q^cs ∈ ···p··) and EM Active or Revise (q^em ∈ {A, R}) receiving CP MUST transition their local CS to Public Aware. VP-09-001 requires immediate embargo termination when public awareness occurs. The CS transition is recorded before embargo teardown begins (CSB-12-004). ECA Details Preconditions - EM state is Active or Revise; CS matches pattern ...p.. - EM state: ACTIVE, REVISE - CS pattern: ...p.. Steps 1. [receiver] Transition local CS to Public Aware (···P··) → Receiver CS public bit set to P 2. [CASE_MANAGER] Emit ET to initiate embargo termination (CSB-04-007); a receiver that does not hold the CASE_MANAGER role emits no ET → ET queued for participants; EM begins transitioning to EXITED 3. [receiver] Emit CK to acknowledge receipt of CP → CK queued for sender Postconditions - Receiver CS is public-aware; the CASE_MANAGER has emitted ET; EM is EXITED; CK emitted	Satisfies: VP-09-001 — Embargoes SHALL terminate immediately when information becomes public Satisfies: VP-11-003 — SHALL initiate embargo termination upon becoming aware of publicly available information Satisfies: MSM-03-004 — CP shorthand wire-type mapping
CSB-04-004	MUST	A Participant in a non-Closed RM state (q^rm ∉ C) already in CS Public Aware (q^cs ∈ ···P··) receiving a duplicate CP MUST emit CK without any CS or EM state transition. All C messages warrant acknowledgment. Duplicate CP does not re-trigger CS or EM transitions. ECA Details Preconditions - CS matches pattern ...P.. - CS pattern: ...P.. Steps 1. [receiver] Emit CK to acknowledge receipt of CP (no state change) → CK queued for sender; CS and EM states unchanged Postconditions* - CK emitted; no state change	Satisfies: MSM-03-004 — CP shorthand wire-type mapping
CSB-04-005	MUST	The CASE_MANAGER in a non-Closed RM state (q^rm ∉ C) with CS not yet public (q^cs ∈ ···p··) and EM Proposed (q^em ∈ P) receiving CP MUST transition EM to None (q^em P → N) by abandoning each open proposal (EMB-16-001). Public awareness makes further embargo negotiation moot; the pending proposal is abandoned per VP-09-001. The abandonment is shared EM state, so the CASE_MANAGER, which can be the Case Owner itself, makes it when it records the P/X/A status (RSH-03-001, EMB-16-001). A Participant that does not hold the role writes no EM state; its replica follows the replayed entries (EMB-16-002, EP-09-008).
CSB-04-006	MUST	A Participant in a non-Closed RM state (q^rm ∉ C) with CS not yet public (q^cs ∈ ···p··) and EM Proposed (q^em ∈ P) receiving CP MUST emit CK to acknowledge receipt. All C messages warrant acknowledgment per VP-12 messaging norms.*
CSB-04-007	MUST	This rule covers a CASE_MANAGER whose RM state is not Closed (q^rm ∉ C) and whose EM is Active or Revise (q^em ∈ {A, R}). Its CS is not yet public (q^cs ∈ ···p··). On receiving CP, it MUST initiate embargo termination by emitting ET in the act that adopts the P value. VP-09-001 requires immediate embargo termination when public awareness occurs. Only the CASE_MANAGER writes shared EM state, so it emits the ET when it records the P/X/A status (RSH-03-001, EP-09-008); it can be the Case Owner itself. A non-manager Participant reports the CS change and emits no ET (EMB-03-003, ADR-0118). Adopting P also authorizes the termination, so no second approval is asked (ADR-0166).	Refines: CSB-12-001 — The adoption of a received CP
CSB-04-008	MUST	A Participant in a non-Closed RM state (q^rm ∉ C) with CS not yet public (q^cs ∈ ···p··) and EM Active or Revise (q^em ∈ {A, R}) receiving CP MUST emit CK to acknowledge receipt. All C messages warrant acknowledgment per VP-12 messaging norms.*

Receive CX (Exploit Public)

Behaviors triggered when a participant receives a CX (Exploit Public) message, recording public availability of an exploit and initiating embargo teardown if an active embargo exists.

Trigger: Message Received — CX

ID	Priority	Requirement	Related
CSB-05-001	MUST	A Participant in a non-Closed RM state (q^rm ∉ C) with CS not yet public and not yet exploit-public (q^cs ∈ ···px·) and EM None or Exited (q^em ∈ {N, X}) receiving CX MUST transition their local CS to both Public Aware and Exploit Public (q^cs ···px· → ···PX·) and emit CK to acknowledge receipt. CX in state ···px· implies the pX→PX invariant (constraint C-15): exploit public without prior public awareness is an ephemeral state that immediately resolves to both P and X. The CS transition is atomic. ECA Details Preconditions - EM state is None or Exited; CS matches pattern ...px. - EM state: NONE, EXITED - CS pattern: ...px. Steps 1. [receiver] Transition local CS to Public Aware and Exploit Public (···PX·) → Receiver CS public bit P and exploit bit X both set 2. [receiver] Emit CK to acknowledge receipt of CX → CK queued for sender Postconditions - Receiver CS is ···PX·; CK emitted	Satisfies: MSM-03-005 — CX shorthand wire-type mapping
CSB-05-002	MUST	A Participant in a non-Closed RM state (q^rm ∉ C) with CS not yet public and not yet exploit-public (q^cs ∈ ···px·) and EM Proposed (q^em ∈ P) receiving CX MUST transition their local CS to ···PX·. Exploit publication terminates a pending embargo proposal per VP-09-001. The pX→PX invariant applies (constraint C-15). ECA Details Preconditions - EM state is Proposed; CS matches pattern ...px. - EM state: PROPOSED - CS pattern: ...px. Steps 1. [receiver] Transition local CS to Public Aware and Exploit Public (···PX·) → Receiver CS public bit P and exploit bit X both set 2. [receiver] Transition EM from PROPOSED to NONE (embargo proposal abandoned) → Receiver EM state is NONE 3. [receiver] Emit CK to acknowledge receipt of CX → CK queued for sender Postconditions - Receiver CS is ···PX·; EM is NONE; CK emitted	Satisfies: VP-09-001 — Embargoes SHALL terminate immediately when information becomes public Satisfies: MSM-03-005 — CX shorthand wire-type mapping
CSB-05-003	MUST	A Participant in a non-Closed RM state (q^rm ∉ C) with CS not yet public and not yet exploit-public (q^cs ∈ ···px·) and EM Active or Revise (q^em ∈ {A, R}) receiving CX MUST transition their local CS to ···PX·. VP-09-001 requires immediate embargo termination when exploit publication occurs. The pX→PX invariant applies. The CS transition is recorded before teardown begins (CSB-05-010). ECA Details Preconditions - EM state is Active or Revise; CS matches pattern ...px. - EM state: ACTIVE, REVISE - CS pattern: ...px. Steps 1. [receiver] Transition local CS to Public Aware and Exploit Public (···PX·) → Receiver CS public bit P and exploit bit X both set 2. [CASE_MANAGER] Emit ET to initiate embargo termination (CSB-05-008); a receiver that does not hold the CASE_MANAGER role emits no ET → ET queued for participants; EM begins transitioning to EXITED 3. [receiver] Emit CK to acknowledge receipt of CX → CK queued for sender Postconditions - Receiver CS is ···PX·; the CASE_MANAGER has emitted ET; EM is EXITED; CK emitted	Satisfies: VP-09-001 — Embargoes SHALL terminate immediately when exploit publication occurs Satisfies: MSM-03-005 — CX shorthand wire-type mapping
CSB-05-004	MUST	A Participant in a non-Closed RM state (q^rm ∉ C) with CS already public but not yet exploit-public (q^cs ∈ ···Px·) receiving CX MUST transition their local CS exploit bit to X (q^cs ···Px· → ···PX·) and emit CK. When public awareness already exists, CX transitions only the exploit bit. No new embargo teardown is triggered since the embargo should already have been terminated when P was reached. ECA Details Preconditions - CS matches pattern ...Px. - CS pattern: ...Px. Steps 1. [receiver] Transition local CS exploit bit to X (···PX·) → Receiver CS exploit bit X set; public bit P remains set 2. [receiver] Emit CK to acknowledge receipt of CX → CK queued for sender Postconditions - Receiver CS is ···PX·; CK emitted	Satisfies: MSM-03-005 — CX shorthand wire-type mapping
CSB-05-005	MUST	A Participant in a non-Closed RM state (q^rm ∉ C) with CS already exploit-public (q^cs ∈ ···PX·) receiving a duplicate CX MUST emit CK without any CS or EM state transition. All C messages warrant acknowledgment. Duplicate CX does not re-trigger CS or EM transitions. ECA Details Preconditions - CS matches pattern ...PX. - CS pattern: ...PX. Steps 1. [receiver] Emit CK to acknowledge receipt of CX (no state change) → CK queued for sender; CS and EM states unchanged Postconditions* - CK emitted; no state change	Satisfies: MSM-03-005 — CX shorthand wire-type mapping
CSB-05-006	MUST	The CASE_MANAGER in a non-Closed RM state (q^rm ∉ C) with CS not yet public and not yet exploit-public (q^cs ∈ ···px·) and EM Proposed (q^em ∈ P) receiving CX MUST transition EM to None (q^em P → N) by abandoning each open proposal (EMB-16-001). Exploit publication makes further embargo negotiation moot; the pending proposal is abandoned per VP-09-001. The abandonment is shared EM state, so the CASE_MANAGER, which can be the Case Owner itself, makes it when it records the P/X/A status (RSH-03-001, EMB-16-001). A Participant that does not hold the role writes no EM state; its replica follows the replayed entries (EMB-16-002, EP-09-008).
CSB-05-007	MUST	A Participant in a non-Closed RM state (q^rm ∉ C) with CS not yet public and not yet exploit-public (q^cs ∈ ···px·) and EM Proposed (q^em ∈ P) receiving CX MUST emit CK to acknowledge receipt. All C messages warrant acknowledgment per VP-12 messaging norms.*
CSB-05-008	MUST	This rule covers a CASE_MANAGER whose RM state is not Closed (q^rm ∉ C) and whose EM is Active or Revise (q^em ∈ {A, R}). Its CS is not yet public and not yet exploit-public (q^cs ∈ ···px·). On receiving CX, it MUST initiate embargo termination by emitting ET in the act that adopts the X value. VP-09-001 requires immediate embargo termination when exploit publication occurs. Only the CASE_MANAGER writes shared EM state, so it emits the ET when it records the P/X/A status (RSH-03-001, EP-09-008); it can be the Case Owner itself. A non-manager Participant reports the CS change and emits no ET (EMB-03-003, ADR-0118). Adopting X also authorizes the termination, so no second approval is asked (ADR-0166).	Refines: CSB-13-002 — The adoption of a received CX
CSB-05-009	MUST	A Participant in a non-Closed RM state (q^rm ∉ C) with CS not yet public and not yet exploit-public (q^cs ∈ ···px·) and EM Active or Revise (q^em ∈ {A, R}) receiving CX MUST emit CK to acknowledge receipt. All C messages warrant acknowledgment per VP-12 messaging norms.*
CSB-05-010	MUST	A Participant in a non-Closed RM state (q^rm ∉ C) with CS not yet public and not yet exploit-public (q^cs ∈ ···px·) and EM Active or Revise (q^em ∈ {A, R}) receiving CX MUST record the CS transition to ···PX· before embargo teardown is initiated. The ledger commits the CS state change before any effect acts on it (CLP-10-006), so every replica sees the cause before its effect.

Receive CA (Attacks Observed)

Behaviors triggered when a participant receives a CA (Attacks Observed) message, recording active exploitation of the vulnerability and initiating embargo teardown if an active embargo exists.

Trigger: Message Received — CA

ID	Priority	Requirement	Related
CSB-06-001	MUST	A Participant in a non-Closed RM state (q^rm ∉ C) with CS not yet public and attacks not yet observed (q^cs ∈ ···p·a) and EM None or Exited (q^em ∈ {N, X}) receiving CA MUST transition their local CS attacks bit to A (q^cs ···p·a → ···p·A) and emit CK. An observed attack is evidence of exploitation, not public information about the vulnerability: an attack can be seen on one network while nothing about the vulnerability has been published. A CS transition changes one dimension (CSB-17-002), and ···p·A is a state a case can rest in (CSB-17-003), so the public bit waits for its own P event. When EM is None or Exited, no embargo teardown is needed. ECA Details Preconditions - EM state is None or Exited; CS matches pattern ...p.a - EM state: NONE, EXITED - CS pattern: ...p.a Steps 1. [receiver] Transition local CS attacks bit to A (···p·A) → Receiver CS attacks bit A set; public bit p remains unset 2. [receiver] Emit CK to acknowledge receipt of CA → CK queued for sender Postconditions - Receiver CS is ···p·A; CK emitted	Satisfies: MSM-03-006 — CA shorthand wire-type mapping
CSB-06-002	MUST	A Participant in a non-Closed RM state (q^rm ∉ C) with CS not yet public and attacks not yet observed (q^cs ∈ ···p·a) and EM Proposed (q^em ∈ P) receiving CA MUST transition their local CS attacks bit to A (q^cs ···p·a → ···p·A). Observed attacks abandon a pending embargo proposal (EMB-16-001) without making the vulnerability public, so only the attacks bit changes (CSB-17-002). ECA Details Preconditions - EM state is Proposed; CS matches pattern ...p.a - EM state: PROPOSED - CS pattern: ...p.a Steps 1. [receiver] Transition local CS attacks bit to A (···p·A) → Receiver CS attacks bit A set; public bit p remains unset 2. [receiver] Transition EM from PROPOSED to NONE (embargo proposal abandoned) → Receiver EM state is NONE 3. [receiver] Emit CK to acknowledge receipt of CA → CK queued for sender Postconditions - Receiver CS is ···p·A; EM is NONE; CK emitted	Satisfies: VP-09-003 — Embargoes SHOULD terminate immediately when attacks are observed Satisfies: MSM-03-006 — CA shorthand wire-type mapping
CSB-06-003	MUST	A Participant in a non-Closed RM state (q^rm ∉ C) with CS not yet public and attacks not yet observed (q^cs ∈ ···p·a) and EM Active or Revise (q^em ∈ {A, R}) receiving CA MUST transition their local CS attacks bit to A (q^cs ···p·a → ···p·A). Observed attacks warrant embargo termination (VP-09-003, CSB-18-004) without making the vulnerability public, so only the attacks bit changes (CSB-17-002). The CS transition is recorded before teardown begins (CSB-06-010). ECA Details Preconditions - EM state is Active or Revise; CS matches pattern ...p.a - EM state: ACTIVE, REVISE - CS pattern: ...p.a Steps 1. [receiver] Transition local CS attacks bit to A (···p·A) → Receiver CS attacks bit A set; public bit p remains unset 2. [CASE_MANAGER] Emit ET to initiate embargo termination (CSB-06-008); a receiver that does not hold the CASE_MANAGER role emits no ET → ET queued for participants; EM begins transitioning to EXITED 3. [receiver] Emit CK to acknowledge receipt of CA → CK queued for sender Postconditions - Receiver CS is ···p·A; the CASE_MANAGER has emitted ET; EM is EXITED; CK emitted	Satisfies: VP-09-003 — Embargoes SHOULD terminate immediately when attacks are observed Satisfies: MSM-03-006 — CA shorthand wire-type mapping
CSB-06-004	MUST	A Participant in a non-Closed RM state (q^rm ∉ C) with CS already public but attacks not yet observed (q^cs ∈ ···P·a) receiving CA MUST transition their local CS attacks bit to A (q^cs ···P·a → ···P·A) and emit CK. When public awareness already exists, CA transitions only the attacks bit. The public bit is already set; no new P transition is needed. ECA Details Preconditions - CS matches pattern ...P.a - CS pattern: ...P.a Steps 1. [receiver] Transition local CS attacks bit to A (···P·A) → Receiver CS attacks bit A set; public bit P remains set 2. [receiver] Emit CK to acknowledge receipt of CA → CK queued for sender Postconditions - Receiver CS is ···P·A; CK emitted	Satisfies: MSM-03-006 — CA shorthand wire-type mapping
CSB-06-005	MUST	A Participant in a non-Closed RM state (q^rm ∉ C) with CS attacks already observed (q^cs ∈ ·····A) receiving a duplicate CA MUST emit CK without any CS or EM state transition. All C messages warrant acknowledgment. Duplicate CA does not re-trigger CS or EM transitions, whether or not the case is public: ···p·A is a resting state (CSB-17-003). ECA Details Preconditions - CS matches pattern .....A - CS pattern: .....A Steps 1. [receiver] Emit CK to acknowledge receipt of CA (no state change) → CK queued for sender; CS and EM states unchanged Postconditions* - CK emitted; no state change	Satisfies: MSM-03-006 — CA shorthand wire-type mapping
CSB-06-006	MUST	The CASE_MANAGER in a non-Closed RM state (q^rm ∉ C) with CS not yet public and attacks not yet observed (q^cs ∈ ···p·a) and EM Proposed (q^em ∈ P) receiving CA MUST transition EM to None (q^em P → N) by abandoning each open proposal (EMB-16-001). Observed attacks make further embargo negotiation moot; the pending proposal is abandoned per VP-06-001 and EMB-16-001. The abandonment is shared EM state, so the CASE_MANAGER, which can be the Case Owner itself, makes it when it records the P/X/A status (RSH-03-001, EMB-16-001). A Participant that does not hold the role writes no EM state; its replica follows the replayed entries (EMB-16-002, EP-09-008).
CSB-06-007	MUST	A Participant in a non-Closed RM state (q^rm ∉ C) with CS not yet public and attacks not yet observed (q^cs ∈ ···p·a) and EM Proposed (q^em ∈ P) receiving CA MUST emit CK to acknowledge receipt. All C messages warrant acknowledgment per VP-12 messaging norms.*
CSB-06-008	MUST	This rule covers a CASE_MANAGER whose RM state is not Closed (q^rm ∉ C) and whose EM is Active or Revise (q^em ∈ {A, R}). Its CS is not yet public and has no attacks observed (q^cs ∈ ···p·a). On receiving CA, it MUST initiate embargo termination by emitting ET in the act that adopts the A value. Observed attacks warrant embargo termination (VP-09-003), and an active embargo cannot coexist with the attacks bit (CSB-18-004). Only the CASE_MANAGER writes shared EM state, so it emits the ET when it records the P/X/A status (RSH-03-001, EP-09-008); it can be the Case Owner itself. A non-manager Participant reports the CS change and emits no ET (EMB-03-003, ADR-0118). Adopting A also authorizes the termination, so no second approval is asked (ADR-0166).	Refines: CSB-14-001 — The adoption of a received CA
CSB-06-009	MUST	A Participant in a non-Closed RM state (q^rm ∉ C) with CS not yet public and attacks not yet observed (q^cs ∈ ···p·a) and EM Active or Revise (q^em ∈ {A, R}) receiving CA MUST emit CK to acknowledge receipt. All C messages warrant acknowledgment per VP-12 messaging norms.*
CSB-06-010	MUST	A Participant in a non-Closed RM state (q^rm ∉ C) with CS not yet public and attacks not yet observed (q^cs ∈ ···p·a) and EM Active or Revise (q^em ∈ {A, R}) receiving CA MUST record the CS transition to ···p·A before embargo teardown is initiated. The ledger commits the CS state change before any effect acts on it (CLP-10-006), so every replica sees the cause before its effect.

Receive CE (CS Error)

Behaviors triggered when a participant receives a CE (CVD Case State Error) signal, which has no dedicated semantic dispatch value and is handled outside the standard AS2 pattern-matching pipeline.

Trigger: Message Received — CE

ID	Priority	Requirement	Related
CSB-07-001	SHOULD	This rule covers a Participant in a non-Closed RM state (q^rm ∉ C) that receives CE. It SHOULD emit CK to acknowledge it, and SHOULD emit GI to ask about the nature of the CS error. CE signals a protocol error in the CS process. Acknowledging with CK and following up with GI allows the sender to explain the error and enables recovery. CE does not trigger a CS state transition. ECA Details Preconditions - Participant is in an active RM state (Received/Invalid/Valid/Deferred/Accepted) - RM state: RECEIVED, INVALID, VALID, DEFERRED, ACCEPTED Steps 1. [receiver] Emit CK to acknowledge receipt of CE → CK queued for sender 2. [receiver] Emit GI to inquire about the nature of the error → GI queued for sender Postconditions - CK and GI emitted; CS state unchanged	Satisfies: MSM-03-007 — CE shorthand wire-type mapping

Receive CK (CS Acknowledgment)

Behaviors triggered when a participant receives a CK (CVD Case State Acknowledgment) passthrough signal, which has no dedicated semantic dispatch value and requires no state transition.

Trigger: Message Received — CK

ID	Priority	Requirement	Related
CSB-08-001	MAY	A Participant receiving CK MAY process it as a passthrough acknowledgment with no state transition and no required response. CK is a pure acknowledgment message. It confirms the sender received a prior C message. No state change or response is required from the receiver.*	Satisfies: MSM-03-008 — CK shorthand wire-type mapping

Enter CS Vendor Aware (V)

Trigger: State Entered — CS.V

ID	Priority	Requirement	Related
CSB-09-001	SHOULD	A Vendor Participant entering CS Vendor Aware (q^cs ∈ Vfdpxa) with EM None (q^em ∈ N) SHOULD begin embargo negotiations promptly. VP-14-005 recommends starting the EM process as soon as possible once a Vendor is aware. Constraint C-32: EM SHOULD begin promptly on Vfdpxa entry when no embargo exists. ECA Details Preconditions - EM state is None; Participant holds the Vendor role; CS matches pattern Vfd... - EM state: NONE - Role: vendor - CS pattern: Vfd...	Satisfies: VP-14-005 — Once a case has reached Vendor Aware, if the EM process has not started, it SHOULD begin as soon as possible
CSB-09-002	SHOULD	A Participant entering CS Vendor Aware SHOULD emit CV to announce the transition to other case Participants. State-change notifications support shared situation awareness. CV informs other Participants that a Vendor is now aware, enabling them to coordinate embargo and fix timing accordingly. ECA Details Preconditions - CS matches pattern Vfd... - CS pattern: Vfd... Steps 1. [participant] Emit CV to announce Vendor Aware CS transition → CV queued for case participants Postconditions - CV emitted; other Participants informed of V transition	Satisfies: VP-12-001 — CV messages SHOULD be sent only by Participants with direct knowledge of the notification

Enter CS Fix Ready (F)

Trigger: State Entered — CS.F

ID	Priority	Requirement	Related
CSB-10-001	SHOULD NOT	A Participant entering CS Fix Ready (q^cs ∈ VFd···) SHOULD NOT start new embargo negotiations. If an embargo proposal is pending (q^em ∈ P), the Participant SHOULD reject it. The one exception is the brief publication or deployment embargo of VP-06-008. VP-14-007 discourages starting or completing new embargo negotiations once a fix is ready, and VP-06-008 names its one exception. Constraint C-34: fix readiness is late in the process for beginning embargo negotiations. ECA Details Preconditions - CS matches pattern VFd... - CS pattern: VFd...	Satisfies: VP-14-007 — Once a case has reached Fix Ready, new embargo negotiations SHOULD NOT start and pending embargoes SHOULD be rejected, except for the VP-06-008 publication or deployment embargo
CSB-10-002	SHOULD	A Participant entering CS Fix Ready SHOULD emit CF to announce the transition to other case Participants. State-change notifications support shared situation awareness. CF informs other Participants that a fix is available, enabling them to coordinate embargo extension or termination decisions. ECA Details Preconditions - CS matches pattern VFd... - CS pattern: VFd... Steps 1. [participant] Emit CF to announce Fix Ready CS transition → CF queued for case participants Postconditions - CF emitted; other Participants informed of F transition

Enter CS Fix Deployed (D)

Trigger: State Entered — CS.D

ID	Priority	Requirement	Related
CSB-11-001	SHOULD	When a Participant enters CS Fix Deployed (q^cs ∈ VFD···) with an active embargo (q^em ∈ {A, R}), the Case Owner, or the CASE_MANAGER it delegates to, SHOULD terminate the embargo by emitting ET. VP-14-015 recommends terminating any existing embargo once the fix has been deployed. Constraint C-35: embargo termination SHOULD follow fix deployment. Ending an embargo is the Case Owner's decision, or the delegated CASE_MANAGER's, so the Participant that deploys the fix reports its CS change and does not emit ET itself (EMB-03-003, ADR-0118, EP-09-008). The Case Owner can hold the CASE_MANAGER role itself. ECA Details Preconditions - EM state is Active or Revise; CS matches pattern VFD... - EM state: ACTIVE, REVISE - CS pattern: VFD... Steps 1. [Case Owner or CASE_MANAGER] Emit ET to terminate the active embargo → ET queued for participants; EM begins transitioning to EXITED Postconditions - ET emitted; EM is EXITED	Satisfies: VP-14-015 — By the time a fix has been deployed, any existing embargo SHOULD terminate
CSB-11-002	SHOULD	A Participant entering CS Fix Deployed SHOULD emit CD to announce the transition to other case Participants. State-change notifications support shared situation awareness. CD informs other Participants that the fix is deployed, allowing them to coordinate publication and embargo termination decisions. ECA Details Preconditions - CS matches pattern VFD... - CS pattern: VFD... Steps 1. [participant] Emit CD to announce Fix Deployed CS transition → CD queued for case participants Postconditions - CD emitted; other Participants informed of D transition

Enter CS Public Aware (P)

Trigger: State Entered — CS.P

ID	Priority	Requirement	Related
CSB-12-001	MUST	This rule covers the CASE_MANAGER when it adopts a P value (q^cs → ···P··) while an embargo is active (q^em ∈ {A, R}). Acting for the Case Owner, it MUST end the embargo immediately, by emitting ET in the act that adopts the value. VP-09-001 requires immediate embargo termination upon public disclosure. Ending an embargo is the Case Owner's decision, and only the CASE_MANAGER writes shared EM state; it can be the Case Owner itself (EMB-03-003, ADR-0118). Adopting P also authorizes the termination (ADR-0166). A non-manager Participant reports P instead (CSB-12-005), and CSB-04-007 covers a received CP. CSB-12-004 orders the CS transition before the teardown. ECA Details Preconditions - EM state is Active or Revise; CS matches pattern ...P.. - EM state: ACTIVE, REVISE - CS pattern: ...P.. Steps 1. [CASE_MANAGER] Adopt the P value into the canonical case status → Case CS public bit set to P 2. [CASE_MANAGER] Emit ET to terminate the embargo, in the same act → ET queued for participants; EM transitions to EXITED Postconditions - CS public bit is P; the CASE_MANAGER has emitted ET; EM is EXITED	Satisfies: VP-09-001 — Embargoes SHALL terminate immediately when information becomes public
CSB-12-005	MUST	This rule covers a Participant that is not the CASE_MANAGER and enters CS Public Aware (q^cs → ···P··) while an embargo is active (q^em ∈ {A, R}). It MUST report the P value to the CASE_MANAGER instead of emitting ET. VP-11-003 has a Participant that learns the vulnerability is public initiate embargo termination. Ending the embargo is the Case Owner's decision, carried out by the CASE_MANAGER (EMB-03-003, ADR-0118, VP-11-012), so the Participant's part is the report. The CASE_MANAGER then ends the embargo in the act that adopts the P value (CSB-12-001, ADR-0166). Participants message only the CASE_MANAGER (PCR-08-001). ECA Details Preconditions - EM state is Active or Revise; CS matches pattern ...P.. - EM state: ACTIVE, REVISE - CS pattern: ...P.. Steps 1. [participant] Report the P value to the CASE_MANAGER → Status report queued for the CASE_MANAGER only; no ET queued Postconditions - The CASE_MANAGER has the P report; the Participant has emitted no ET	Satisfies: VP-11-003 — Participants SHALL initiate embargo termination on learning that information about the vulnerability is public
CSB-12-004	MUST	This rule covers the CASE_MANAGER when it adopts a P value (q^cs → ···P··) while an embargo is active (q^em ∈ {A, R}). It MUST record the adopted P value before it ends the embargo under CSB-12-001. Every replica replays the ledger in order, so a teardown committed ahead of its cause would show the embargo ending for no recorded reason. CSB-04-003 is the received transition this rule orders; the ledger mechanism is CLP-10-006.	Refines: CSB-12-001
CSB-12-002	MUST NOT	A Participant entering CS Public Aware MUST NOT seek new embargoes or accept new embargo proposals for this case. VP-06-001 prohibits seeking new embargoes once public awareness has occurred. This applies to all future EP messages for this case. ECA Details Preconditions - CS matches pattern ...P.. - CS pattern: ...P..	Satisfies: VP-06-001 — Once Public Awareness, new embargoes SHALL NOT be sought
CSB-12-003	SHOULD	A Participant entering CS Public Aware SHOULD emit CP to announce the transition to other case Participants if CP was not already the triggering event (i.e., the transition was triggered locally or by a different message type). State-change notifications support shared situation awareness. CP informs other Participants that the vulnerability is now public. This item applies when the P transition is triggered by a local event (e.g., own publication) rather than by receiving CP from another Participant. ECA Details Preconditions - CS matches pattern ...P.. - CS pattern: ...P.. Steps 1. [participant] Emit CP to announce Public Aware CS transition → CP queued for case participants Postconditions - CP emitted; other Participants informed of P transition

Enter CS Exploit Public (X)

Trigger: State Entered — CS.X

ID	Priority	Requirement	Related
CSB-13-001	MUST	A Participant whose CS sets the exploit bit while the public bit is unset (···px·) MUST also trigger CS→P (the pX→PX invariant). It triggers CS→P before or with the exploit transition. The ephemeral state ···pX· (exploit public without public awareness) cannot exist as a stable state. Constraint C-15 requires the transition to be ···px· → ···PX·, not ···px· → ···pX· → ···PX·. Observable consequence: CX emitted from ···px· state must be accompanied by CP. The precondition uses the post-transition pattern ···pX· (X uppercase, P lowercase) since state_entered fires after the X bit is set. ECA Details Preconditions - CS matches pattern ...pX. - CS pattern: ...pX. Steps 1. [participant] Emit CX to announce exploit public transition → CX queued for case participants 2. [participant] Emit CP to announce public aware transition (C-15 constraint) → CP queued for case participants Postconditions - CS is ···PX·; CX and CP both emitted; pX→PX invariant satisfied
CSB-13-006	MUST	A Participant MUST treat the compound transition of CSB-13-001 as atomic, so that it sets the P and X bits together. If the P and X bits were set in two steps, the participant would pass through the ephemeral state ···pX·, which cannot exist as a stable state (C-15). ECA Details Preconditions - CS matches pattern ...pX. - CS pattern: ...pX. Steps 1. [participant] Transition CS to ···PX· (set both public bit P and exploit bit X atomically) → Receiver CS public bit P and exploit bit X both set Postconditions - CS is ···PX·, with no stored ···pX· state	Refines: CSB-13-001
CSB-13-002	MUST	This rule covers the CASE_MANAGER when it adopts an X value (q^cs → ···PX·) while an embargo is active (q^em ∈ {A, R}). Acting for the Case Owner, it MUST end the embargo immediately, by emitting ET in the act that adopts the value. VP-09-001 requires immediate embargo termination upon exploit publication. Ending an embargo is the Case Owner's decision, and only the CASE_MANAGER writes shared EM state; it can be the Case Owner itself (EMB-03-003, ADR-0118). Adopting X also authorizes the termination (ADR-0166). A non-manager Participant reports X instead (CSB-13-005), and CSB-05-008 covers a received CX. CSB-13-004 orders the CS transition before the teardown. ECA Details Preconditions - EM state is Active or Revise; CS matches pattern ...PX. - EM state: ACTIVE, REVISE - CS pattern: ...PX. Steps 1. [CASE_MANAGER] Adopt the X value into the canonical case status → Case CS exploit bit set to X 2. [CASE_MANAGER] Emit ET to terminate the embargo, in the same act → ET queued for participants; EM transitions to EXITED Postconditions - CS exploit bit is X; the CASE_MANAGER has emitted ET; EM is EXITED	Satisfies: VP-09-001 — Embargoes SHALL terminate immediately when exploit becomes public
CSB-13-005	MUST	This rule covers a Participant that is not the CASE_MANAGER and enters CS Exploit Public (q^cs → ···PX·) while an embargo is active (q^em ∈ {A, R}). It MUST report the X value to the CASE_MANAGER instead of emitting ET. VP-11-003 has a Participant that learns of public exploit code initiate embargo termination. Ending the embargo is the Case Owner's decision, carried out by the CASE_MANAGER (EMB-03-003, ADR-0118, VP-11-012), so the Participant's part is the report. The CASE_MANAGER then ends the embargo in the act that adopts the X value (CSB-13-002, ADR-0166). Participants message only the CASE_MANAGER (PCR-08-001). ECA Details Preconditions - EM state is Active or Revise; CS matches pattern ...PX. - EM state: ACTIVE, REVISE - CS pattern: ...PX. Steps 1. [participant] Report the X value to the CASE_MANAGER → Status report queued for the CASE_MANAGER only; no ET queued Postconditions - The CASE_MANAGER has the X report; the Participant has emitted no ET	Satisfies: VP-11-003 — Participants SHALL initiate embargo termination on learning of public exploit code
CSB-13-004	MUST	This rule covers the CASE_MANAGER when it adopts an X value (q^cs → ···PX·) while an embargo is active (q^em ∈ {A, R}). It MUST record the adopted X value before it ends the embargo under CSB-13-002. Every replica replays the ledger in order, so a teardown committed ahead of its cause would show the embargo ending for no recorded reason. The received form of this rule is CSB-05-010; the ledger mechanism is CLP-10-006.	Refines: CSB-13-002
CSB-13-003	MUST NOT	A Participant entering CS Exploit Public MUST NOT seek new embargoes or accept new embargo proposals for this case. VP-06-001 prohibits seeking new embargoes once exploit publication has occurred. ECA Details Preconditions - CS matches pattern ....X. - CS pattern: ....X.	Satisfies: VP-06-001 — Once Exploit Publication, new embargoes SHALL NOT be sought

Enter CS Attacks Observed (A)

Trigger: State Entered — CS.A

ID	Priority	Requirement	Related
CSB-14-001	SHOULD	This rule covers the CASE_MANAGER when it learns of an A value (q^cs → ·····A) while an embargo is active (q^em ∈ {A, R}). Acting for the Case Owner, it SHOULD end the embargo by adopting the value, in an act that emits ET. VP-09-003 recommends ending the embargo when attacks are observed. It is SHOULD, not SHALL, to leave room for judgment. Under ADR-0166 that judgment is whether to adopt A: an adopted A ends the embargo in the same act (CSB-06-008, RSH-03-001). The Case Owner may delegate that decision in advance (RSH-07-003) and keeps the authority (VP-11-006). A non-manager Participant reports A instead (CSB-14-006). ECA Details Preconditions - EM state is Active or Revise; CS matches pattern .....A - EM state: ACTIVE, REVISE - CS pattern: .....A Steps 1. [CASE_MANAGER] Adopt the A value into the canonical case status → Case CS attacks bit set to A 2. [CASE_MANAGER] Emit ET to terminate the embargo, in the same act → ET queued for participants; EM transitions to EXITED Postconditions - CS attacks bit is A; the CASE_MANAGER has emitted ET; EM is EXITED	Satisfies: VP-09-003 — Embargoes SHOULD terminate immediately when there is evidence of active exploitation
CSB-14-006	SHOULD	This rule covers a Participant that is not the CASE_MANAGER and enters CS Attacks Observed (q^cs → ·····A) while an embargo is active (q^em ∈ {A, R}). It SHOULD report the A value to the CASE_MANAGER instead of emitting ET. VP-11-007 has a Participant that learns of attacks initiate embargo termination. Ending the embargo is the Case Owner's decision, carried out by the CASE_MANAGER (EMB-03-003, ADR-0118, VP-11-012), so the Participant's part is the report, sent to the CASE_MANAGER (PCR-08-001). The Case Owner may delegate in advance the decision to adopt a reported A (RSH-07-003); it then decides ahead of time and keeps the authority (VP-11-006). ECA Details Preconditions - EM state is Active or Revise; CS matches pattern .....A - EM state: ACTIVE, REVISE - CS pattern: .....A Steps 1. [participant] Report the A value to the CASE_MANAGER → Status report queued for the CASE_MANAGER only; no ET queued Postconditions - The CASE_MANAGER has the A report; the Participant has emitted no ET	Satisfies: VP-11-007 — Participants SHOULD initiate embargo termination on learning of attacks
CSB-14-005	SHOULD	This rule covers the CASE_MANAGER when it adopts an A value (q^cs → ·····A) while an embargo is active (q^em ∈ {A, R}). It SHOULD record the adopted A value before it ends the embargo under CSB-14-001. Every replica replays the ledger in order, so a teardown committed ahead of its cause would show the embargo ending for no recorded reason. The received form of this rule is CSB-06-010; the ledger mechanism is CLP-10-006.	Refines: CSB-14-001
CSB-14-003	MUST NOT	A Participant entering CS Attacks Observed MUST NOT seek new embargoes for this case. VP-06-001 prohibits seeking new embargoes once attacks have been observed. ECA Details Preconditions - CS matches pattern .....A - CS pattern: .....A	Satisfies: VP-06-001 — Once Attacks observed, new embargoes SHALL NOT be sought
CSB-14-004	SHOULD	A Participant entering CS Attacks Observed SHOULD emit CA to announce the transition to other case Participants. State-change notifications support shared situation awareness. CA informs other Participants that active exploitation has been observed, enabling them to re-evaluate embargo and disclosure decisions. VP-12-002 recommends that fix development accelerate and embargo teardown begin. ECA Details Preconditions - CS matches pattern .....A - CS pattern: .....A Steps 1. [participant] Emit CA to announce Attacks Observed CS transition → CA queued for case participants Postconditions - CA emitted; other Participants informed of A transition	Satisfies: VP-12-002 — Once attacks have been observed, fix development SHOULD accelerate and embargo teardown process SHOULD begin

Trigger-Side VFD Role Preconditions

Precondition requirements for self-reported CS trigger endpoints (notify-fix-ready, notify-fix-deployed, notify-published). These complement the receive-side CSB-02, CSB-03, and CSB-04 groups by specifying which CVD roles may initiate each VFD transition locally and what state each trigger endpoint MUST set.

ID	Priority	Requirement	Related
CSB-15-001	MUST	A participant MUST hold the VENDOR role in the case to report its own fix-ready transition (f → F). Fix readiness (F event) represents that the actor has produced a fix. Only actors who develop or maintain the affected product (Vendors) can produce a fix; Deployers operate existing deployments and do not produce fixes. Finders, Reporters, and Coordinators likewise MUST NOT self-report fix readiness. ECA Details Preconditions - A participant is about to report its own f → F transition Steps 1. [participant] Check that the participant holds the VENDOR role in the case → The check passes for a Vendor; the transition is refused otherwise 2. [participant] If the check passes, report its vf state as F → The report goes to the CASE_MANAGER Postconditions - Only a VENDOR participant reports F
CSB-15-007	MUST NOT	A participant without the VENDOR role in the case MUST NOT record its own fix-ready transition (f → F). Such a participant has no vendor-fix (vf) path. Only a Vendor can produce a fix (CSB-15-001). A recorded F from any other participant would claim a fix it cannot have produced, and every reader of its status would believe it. ECA Details Postconditions - Only a VENDOR participant records F	Extends: CSB-15-001
CSB-15-002	MUST	A participant MUST hold the DEPLOYER role in the case to report its own fix-deployed transition (d → D). Fix deployment (D event) represents applying a fix in one's own environment. Only actors who are responsible for operating deployed instances (Deployers) can perform this action. A shipping-product Vendor who does not control downstream deployment holds only the VENDOR role, not DEPLOYER, and has no deployer path. ECA Details Preconditions - A participant is about to report its own d → D transition Steps 1. [participant] Check that the participant holds the DEPLOYER role in the case → The check passes for a Deployer; the transition is refused for a VENDOR-only or any other non-DEPLOYER participant 2. [participant] If the check passes, report its d state as D → The report goes to the CASE_MANAGER Postconditions - Only a DEPLOYER participant reports D
CSB-15-009	MUST NOT	A participant without the DEPLOYER role in the case MUST NOT record its own fix-deployed transition (d → D). Such a participant has no deployer (d) path. Only a Deployer operates the deployed instances (CSB-15-002). A recorded D from any other participant would claim a deployment it cannot have done. ECA Details Postconditions - Only a DEPLOYER participant records D	Extends: CSB-15-002
CSB-15-003	MUST	A participant that reports that the vulnerability is public MUST record only the P event (pxa → Pxa) in its participant status. Conflating P and D transitions causes non-deployer actors (Finders, Reporters, Coordinators) to incorrectly acquire deployment state when they announce public disclosure. The P event is participant-agnostic; the D event is valid only for a DEPLOYER participant that has separately completed deployment (CSB-15-002). ECA Details Preconditions - A participant reports that the vulnerability is public Steps 1. [participant] Record P (Pxa) in its participant status → Public awareness recorded Postconditions - The participant status records P
CSB-15-011	MUST NOT	A participant's report of the P event MUST NOT also advance its d dimension. The D event (fix deployed) is participant-specific and distinct from the P event (public awareness). A participant that reports fix deployment reports it separately, and must hold the DEPLOYER role (CSB-15-002). ECA Details Steps 1. [participant] Leave the vf and d dimensions unchanged (do not advance d to D) → vf and d reflect prior state; D event not triggered by P event Postconditions - The participant status's vf and d dimensions are unchanged	Extends: CSB-15-003
CSB-15-004	MUST	A participant that holds the DEPLOYER role but not the VENDOR role MUST be permitted to make the d→D transition only when at least one participant holding the VENDOR role in the same case has reached F (fix ready). Such a participant has no vendor-fix (VF) state of its own and is at d before the transition; the transition moves it to D, recording deployment of a fix another participant produced. A participant with the DEPLOYER role and no VENDOR role has a deployer path and no vendor path (ADR-0075). It can deploy only a fix that exists, so its d→D move waits until at least one VENDOR participant in the case is at F. Its d dimension starts at d and moves to D when that gate passes. The gate asks only that some VENDOR is at F, because the protocol does not record which vendor a deployer depends on, and a rule that named the vendor would need that record. ECA Details Preconditions - The participant holds the DEPLOYER role but not VENDOR in the case (no vendor path; deployer path at d); at least one other participant holds the VENDOR role and is at F Steps 1. [participant] Check that the participant holds DEPLOYER and not VENDOR, and that at least one participant in the case holds VENDOR and is at F (causal gate) → All checks pass; d → D transition allowed 2. [participant] Record its d state as D and report it → d is D (it was d); the participant still has no vendor path; the report goes to the CASE_MANAGER Postconditions - The DEPLOYER-only participant records D with no vendor path throughout; at least one VENDOR participant is at F in the same case	Refines: CSB-15-002 — CSB-15-002 gates d→D on the DEPLOYER role; CSB-15-004 adds the causal precondition requiring at least one VENDOR participant to be at F first

CS Write-Boundary Transition Validation

Requirements for CS state write paths (VFD and PXA) to validate source→target transition validity before persisting a ParticipantStatus snapshot. Complements CSB-15 (trigger-side role preconditions) and SDO-02-002 (dimension object transition contract) by requiring that the BT write node itself is fail-closed regardless of upstream guard coverage.

ID	Priority	Requirement	Related
CSB-16-001	MUST	A participant MUST advance its own vendor-path (vf) or deployer-path (d) dimension only along a transition its sub-machine permits. The vendor path uses CS_vf, and the deployer path uses CS_d. Restating the current state is a status confirmation and is permitted. A participant's status is its own claim about the case, and every other participant reads it. A jump the sub-machine does not permit therefore misstates the history of the vulnerability (SDO-02-004). The vendor and deployer paths are separate sub-machines (ADR-0075), so a participant that holds both roles is held to each path independently. The rule covers a participant's own writes. A receiver applies a weaker forward-only check to the status of a peer, because a peer can advance several steps between two messages. ECA Details Preconditions - A participant is about to record a new vf state (Vendor path) or d state (Deployer path) for itself Steps 1. [participant] Read its current vf state (if a Vendor) or d state (if a Deployer) → Current dimension state available; a participant without the role has no such dimension 2. [participant] For each dimension it holds: if the target is the current state, proceed; if the sub-machine permits current → target, proceed; otherwise refuse → Only permitted transitions or same-state confirmations are recorded Postconditions - No participant status with an illegal vf or d jump is recorded	Implements: SDO-02-004 Refines: BTND-10-001
CSB-16-005	MUST NOT	A participant MUST NOT record a backward move or an illegal jump of its own vf or d dimension. Every other participant reads a participant's status as its claim about the case, so a recorded backward move or illegal jump misstates the history of the vulnerability (CSB-16-001, SDO-02-004). ECA Details Postconditions - No participant status with an illegal vf or d jump is recorded	Refines: CSB-16-001
CSB-16-002	MUST	A participant MUST advance a PXA state it records only along a transition the PXA state machine permits. This holds in its own participant status and in the case status. Restating the current state is permitted. PXA events are forward-only (p→P, x→X, a→A). Public awareness, a public exploit or observed attacks cannot become untrue later. The rule that limits the vf and d paths to permitted transitions (CSB-16-001) applies to PXA for the same reason. ECA Details Preconditions - A participant is about to record a new PXA state Steps 1. [participant] Read the current PXA state → Current PXA state available 2. [participant] If the target is the current state, proceed; if the PXA state machine permits current → target, proceed; otherwise refuse → Only permitted transitions or same-state confirmations are recorded Postconditions - No status with an illegal PXA regression is recorded	Implements: SDO-02-004 Refines: BTND-10-001
CSB-16-007	MUST NOT	A participant MUST NOT record a backward PXA move, in its own participant status or in the case status. A backward PXA write would show a false regression in the case record, and every participant reads that record (CSB-16-002). ECA Details Postconditions - No status with an illegal PXA regression is recorded	Refines: CSB-16-002

CS Compound State and History Validity

CS-internal validity invariants over the compound (VFD x PXA) case state and over whole case histories. Where CSB-16 validates a single write at the persistence boundary, CSB-17 defines which compound states exist, which single-event transitions between them are causally possible, and which orderings of the six CS events a real case could have produced. Mined from the legacy vultron.core.case_states hypercube model and re-expressed against the current CS enums; see ADR-0060.

ID	Priority	Requirement	Related
CSB-17-001	MUST	An implementation MUST treat exactly 32 compound CS states as valid: the cross product of the 4 valid VFD states (vfd, Vfd, VFd, VFD) and the 8 PXA states. The VFD dimension is a linear chain, not a free product of three bits: readiness presupposes awareness and deployment presupposes readiness. Enumerating only the reachable combinations makes the two impossible combinations unrepresentable rather than merely rejected at runtime, which is why CS_vfd has four members and not eight. ECA Details Postconditions - The CS enum has exactly 32 members, one per valid compound state	Refines: SM-09-002 — SM-09-002 states the vF/fD prohibition as a rejection rule; this refines it to a structural guarantee by enumerating only the 32 reachable combinations, so the impossible ones are unrepresentable.
CSB-17-002	MUST	A CS transition MUST change exactly one of the six CS dimensions. CS events are irreversible and are observed one at a time; a compound state change of Hamming distance greater than one conflates two distinct events and loses their ordering, which is exactly the information history validity depends on. These two conditions alone admit 72 transitions; applying the ephemeral-state rule of CSB-17-003 leaves exactly 58 valid CS transitions. ECA Details Preconditions - A (source, destination) pair of compound CS states Steps 1. [validator] Identify the single dimension that differs between source and destination; reject if more than one differs. If none differs, the write is a same-state re-assertion, which CSB-16-001 and CSB-16-002 permit as a status confirmation: accept it only when the caller has opted in (the allow_null parameter), and reject it otherwise, because a transition validator's default answer for "no change" must be "that is not a transition". → A single CS event accounts for the change, or the caller has explicitly asked for same-state writes to pass 2. [validator] Delegate to the changed dimension's own transition table (is_valid_vfd_transition or is_valid_pxa_transition). → Monotonicity and VFD prerequisite ordering are enforced 3. [validator] Apply the ephemeral-state rule of CSB-17-003 to the source state. → A transition out of a vP or pX state fires only the event that state requires Postconditions - Only Hamming-distance-1 monotone transitions are accepted	Constrains: CSB-16-001 — Adds the one-dimension-at-a-time and monotonicity constraints that a per-dimension write validator cannot see. The same-state write CSB-16 permits is preserved via the opt-in described in step 1. Constrains: CSB-16-002 Depends on: CSB-17-003 — The 58-transition count holds only with the ephemeral rule applied.
CSB-17-014	MUST	A CS transition MUST change its one dimension from the not-yet-happened value to the happened value. CS events are irreversible, so a change from the happened value back to the not-yet-happened value describes no event. With CSB-17-002 this condition admits 72 transitions, and the ephemeral-state rule of CSB-17-003 leaves 58. ECA Details Postconditions - Only monotone transitions are accepted	Extends: CSB-17-002
CSB-17-003	MUST	An implementation MUST treat the compound states vP (public aware while the vendor is unaware) and pX (exploit public while the public is unaware) as ephemeral. Neither condition can persist in reality: public awareness reaches the vendor, and a published exploit makes the public aware. Modelling these as ephemeral rather than invalid preserves the causal ordering of the events while forbidding the case from progressing in any other direction first. The pX ephemeral rule is the pX to PX invariant of CSB-13-001 generalised from the entry cascade to every successor of a pX state. ECA Details Preconditions - The case is in one of the 12 ephemeral compound CS states Postconditions - Each ephemeral state has exactly one valid successor state	Extends: CSB-13-001 Refines: SM-09-001 — SM-09-003 governs the persistence boundary: an incoming status write carrying vP or pX MUST be promoted to the forced form before it is stored. CSB-17-003 governs trajectory validation, where the same two conditions are modelled as ephemeral states with exactly one legal successor. The two are consistent because they apply at different boundaries: no vP or pX state is ever persisted, but such a state is still a legal intermediate point in a replayed history, and CSB-17-004 therefore permits a history prefix to end in one.
CSB-17-004	SHOULD	A consumer validating a reported CS history SHOULD validate it causally by replaying the event sequence through CSB-17-002 and CSB-17-003 from the initial state vfdpxa, rather than checking states point-in-time or comparing wall-clock timestamps. A complete history contains all six CS events exactly once; there are exactly 70 valid complete histories out of 720 orderings. Validity of a case trajectory is a property of the whole ordered sequence, not of any single state: VFDPXA and VFDXAP visit only valid states, but only the first is a possible case history. Wall-clock timestamps cannot substitute, because they may be missing, skewed, or recorded by different participants. SHOULD rather than MUST because a consumer holding only a current state, with no event log to replay, cannot do better. ECA Details Preconditions - An ordered sequence of CS events, possibly incomplete Steps 1. [validator] Reject any event that occurs more than once in the sequence → Each CS event happens at most once 2. [validator] Replay the sequence from vfdpxa, requiring each step to satisfy CSB-17-002 and CSB-17-003 given every event that preceded it. → Causally impossible orderings are rejected Postconditions - A complete valid history terminates in VFDPXA
CSB-17-005	MUST	An incomplete CS history MUST be validated as a prefix. Real cases are usually still in progress, so requiring six events would reject every live case. Ending in an ephemeral state is unavoidable at the prefix level: CSB-17-003's forced successor has not happened yet when the prefix is cut, which is different from persisting an ephemeral state — SM-09-003 still forbids that. Pinning acceptance to CSB-17-004's prefix closure keeps both directions honest: a validator that merely never rejects a genuine prefix could still accept dead ends. ECA Details Preconditions - An ordered sequence of CS events with fewer than six entries Steps 1. [validator] Apply CSB-17-004's replay to the sequence without requiring that it terminate in VFDPXA. → The prefix is accepted iff it is a prefix of at least one valid complete history Postconditions - A prefix ending in an ephemeral state is accepted, and its forced successor per CSB-17-003 is the only legal continuation	Refines: CSB-17-004 Depends on: CSB-17-003
CSB-17-006	MUST	An implementation MUST NOT allow a fix to be ready while the vendor is unaware (the vF compound state is impossible). Fix readiness presupposes vendor awareness; the vF combination is structurally excluded from the 32 valid compound CS states.
CSB-17-007	MUST	An implementation MUST NOT allow a fix to be deployed that was never ready (the fD compound state is impossible). Fix deployment presupposes fix readiness; the fD combination is structurally excluded from the 32 valid compound CS states.
CSB-17-008	MUST	A CS transition that changes two or more dimensions at once, that reverses a dimension, or that skips a VFD prerequisite MUST be rejected. Each of the three prohibited forms conflates or reorders distinct causal events; rejecting them enforces the one-event-at-a-time and monotonicity invariants.
CSB-17-009	MUST	From a vP state the next CS event MUST be V. The forced-successor rule is the operational consequence of CSB-17-003's ephemeral classification: each ephemeral state has exactly one valid continuation, enforcing the vP→VP invariant.
CSB-17-012	MUST	From a pX state the next CS event MUST be P. The forced-successor rule for pX states enforces the pX→PX invariant; pX is ephemeral and P is the only valid continuation.	Refines: CSB-17-003
CSB-17-013	MUST	Any CS event other than the forced successor MUST be rejected when the current state is ephemeral (vP or pX). Accepting any other event would break the vP→VP and pX→PX invariants that the forced-successor rule exists to enforce.	Refines: CSB-17-003
CSB-17-010	MUST NOT	Prefix validation MUST NOT require all six CS events to be present. Real cases are still in progress at validation time, so requiring all six events would reject every live case.
CSB-17-015	MAY	A CS history prefix MAY end in an ephemeral state. An ephemeral-ending prefix is valid as long as its forced successor has not yet been observed.
CSB-17-011	MUST	Every accepted incomplete CS history prefix MUST have at least one valid completion among the 70 valid complete histories of CSB-17-004. Pinning acceptance to the prefix closure of CSB-17-004 prevents a validator from accepting dead-end prefixes that cannot lead to any valid complete history.

Cross-Machine State Entailments

Invariants that span two state machines simultaneously. These are causal entailments, not local transition constraints: they capture states that are logically contradictory given the sequence of events that produced them. CSB-18-001 is enforced at emit time via ValidateTriggerTransitionsNode and on the receive path via composite_state_violations() (composite_state_invariants.py). CSB-18-002 through CSB-18-004 (PXA↔EM) are enforced on the receive path via ThreatTerminationBranchNode in add_participant_status_tree; violation_pxa_em_entailment() (composite_state_invariants.py) is the post-cascade diagnostic caller via PxaEmInvariantDiagnosticNode (CONCERN-3008, issue #3115).

ID	Priority	Requirement	Related
CSB-18-001	MUST NOT	A participant's composite state MUST NOT have the VFD F-bit set (q^cs ∈ VFd··· or VFD···) while the participant's RM state is outside {ACCEPTED, DEFERRED, CLOSED}. A fix cannot be ready before the vulnerability has been accepted for action. The F bit records that the vendor has a fix. A vendor makes a fix only after it accepts the report for action. An F bit with an RM state before acceptance (START, RECEIVED, INVALID or VALID) is therefore causally impossible. The true rule is about history: the participant passed through ACCEPTED at some time. A participant status holds only the current RM state, so the check uses the RM states that ACCEPTED can reach. DEFERRED and CLOSED can also be reached without ACCEPTED, so the check is sound but not complete. The set keeps them because a peer can move through ACCEPTED to DEFERRED or CLOSED and report a ready fix in one message. A check of ACCEPTED alone would refuse that valid update. Only the RM history of the participant can give a complete check. ECA Details Preconditions - Any participant state snapshot is available for inspection	Constrains: CSB-16-001
CSB-18-002	MUST NOT	Once a CASE_MANAGER act commits, a participant's composite state MUST NOT have the PXA P-bit set (q^cs ∈ ···P··) while an active embargo exists (q^em ∈ {ACTIVE, REVISE}). Public awareness of a vulnerability while an embargo is active is causally impossible in a well-functioning coordination — the P event causes embargo termination, so EM cannot remain ACTIVE once P has occurred. The P event (public awareness) makes the embargo end. An embargo that stays ACTIVE or REVISE after P is recorded is therefore a causal contradiction, and it misstates the case to every participant that reads it. The emit path does not refuse a P report while an embargo is active, because that report is what causes the embargo to end. The rule is judged per act, not per entry (ADR-0166): the adopting act writes its snapshot before the teardown (RSH-01-004). ECA Details Preconditions - A PXA state and an EM state are both available for the same case
CSB-18-003	MUST NOT	Once a CASE_MANAGER act commits, a participant's composite state MUST NOT have the PXA X-bit set (q^cs ∈ ···X·) while an active embargo exists (q^em ∈ {ACTIVE, REVISE}). Public exploit availability while an embargo is active is causally impossible — the X event entails embargo termination. A public exploit lets attackers use the vulnerability, so secrecy no longer protects users. An embargo that stays ACTIVE or REVISE after X tells participants to keep a secret that attackers already have. It also holds back information that defenders need now, and it misstates the case to every participant that reads it. It is judged when an act commits, as CSB-18-002 is (ADR-0166). ECA Details Preconditions - A PXA state and an EM state are both available for the same case	Refines: CSB-18-002
CSB-18-004	MUST NOT	Once a CASE_MANAGER act commits, a participant's composite state MUST NOT have the PXA A-bit set (q^cs ∈ ···A) while an active embargo exists (q^em ∈ {ACTIVE, REVISE}). Observed attacks while an embargo is active is causally impossible — the A event entails embargo termination. Observed attacks show that the vulnerability is in use. An embargo that stays ACTIVE or REVISE after A holds back the information that defenders need to protect themselves while the attacks go on. It also misstates the case to every participant that reads it. It is judged when an act commits, as CSB-18-002 is (ADR-0166). ECA Details Preconditions - A PXA state and an EM state are both available for the same case	Refines: CSB-18-002

CS Ordering Invariants Under Out-of-Order Ledger Delivery

Normative requirements for how CS ordering invariants interact with the ADR-0037 out-of-order ledger hold. Clarifies when invariant guards are evaluated relative to the hold and the drain.

ID	Priority	Requirement	Related
CSB-19-001	MUST	CS ordering invariants (ephemeral-state guard, history-prefix validity, CP-before-ET ordering) MUST be evaluated at drain time — that is, against the causal-order replay of the held Announces (ADR-0037, SYNC-14-009) — not at the time of original out-of-order receipt. An out-of-order Announce(CaseLedgerEntry) carrying a CS update is held by BufferOutOfOrderEntryNode before any domain effects are applied; the CS state machine is not touched at hold time. When the gap fills, the drain replays each held Announce through the full announce receive BT in log_index order (ADR-0037, CLP-14-001), so CS guards see the entries in correct causal sequence. Evaluating guards at original receipt would produce false violations whenever the predecessor CS entry has not yet arrived.	Depends on: CSB-12-004
CSB-19-002	MUST NOT	A held out-of-order CS ledger entry MUST NOT trigger an ephemeral-state violation or history-prefix validation failure at the time it is held. An ephemeral-state entry (e.g., a pX-state CaseStatus arriving before its P-state predecessor) is structurally valid in isolation; the violation would only be real if the predecessor never arrives. Flagging it at hold time produces a false positive and may cause the entry to be incorrectly rejected, breaking convergence.	Refines: CSB-19-001
CSB-19-003	MUST	Under out-of-order ledger delivery, the CP-before-ET constraint of CSB-12-004 MUST still hold. It holds because the CASE_MANAGER commits in causal order (CLP-14-001): the P-state entry has a lower log_index than the ET entry after it. The drain therefore processes P before ET when it holds both. CSB-12-004 is enforced at the CASE_MANAGER write-side: the CASE_MANAGER commits the P-state entry before committing the ET entry. This means the P-state entry's log_index is strictly lower than the ET entry's log_index. The ADR-0037 drain replays in log_index order, so the constraint cannot be violated by reordered delivery alone. No receiver-side re-enforcement of the temporal constraint is required; the causal order in the ledger is sufficient.	Refines: CSB-19-001 Depends on: CSB-12-004 Depends on: CLP-14-001