# Operate phase In [Operate phase](../../general-description/operate-phase.md) the informative description of the operate phase processes are provided. In this chapter, the use cases will be described as derived from the operate phase. The USEF MCM operate phase specifies the following use cases: _Use cases for the operate phase._ | Name | Direction | Message types | |---------------------------------------------------------------|-----------|---------------------------------------------------| | [Exchange updated D-Prognoses](#exchange-updated-d-prognoses) | AGR → DSO | Prognosis / PrognosisResponse | | [Revocation Flexibility Offer](#revocation-flexibility-offer) | AGR → DSO | FlexOfferRevocation / FlexOfferRevocationResponse | | [Exchange Flexibility Orders](#exchange-flexibility-orders) | AGR ← DSO | FlexOrder / FlexOrderResponse | The use cases are explained in the following sections. ## Exchange updated D-Prognoses The process diagram is similar to the figure in [Exchange D-Prognoses per Congestion Point](validate-phase.md#exchange-d-prognoses-per-congestion-point).

	D-prognosis
Goal in context	Changes in D-prognoses to be realized are transmitted.
Preconditions	AGR has created initial D-prognoses in the Plan/Validate phases, and has subsequently detected deviations in Operate that resulted in a portfolio state that requires those prognoses to be re-created.
Successful outcome	Prognosis sent to DSO that reflects all relevant changes
Failure outcome	RejectionReason	Cause of rejection
	<See Message validation>	D-prognosis failed to pass validation by the DSO
	Lacking ISPs	The prognosis does not include all ISPs in the Period it applies to
	Power value rejection	One or more Power values in the prognosis are not plausible
	Subordinate sequence number	The message sequence is lower than that of a previously received D-prognosis
	[User defined]	Any other reasonable cause to reject the message

### Related information The process is similar to that described in [Exchange D-Prognoses per Congestion Point](validate-phase.md#exchange-d-prognoses-per-congestion-point). Deviations can be caused by new flexibility orders from the DSO and by unforeseen change of behavior by assets. The basic process for re-creating D-prognoses is the same as that used to create them in the first place, in the plan/validate phases. When re-creating prognoses in the operate phase, values for ISPs that are already in the past should remain unchanged, as these will be ignored by DSOs anyway. ## Revocation Flexibility Offer The process diagram is similar to the figure in [Revocation of FlexOffer](validate-phase.md#revocation-flexibility-offer).

	Revoke FlexOffer
Goal in context	Inform the DSO that a previously sent flexibility offer is no longer valid, despite the validity period of the offer not having expired yet.
Preconditions	A flexibility offer has been sent to and acknowledged by the DSO
Successful outcome	Flexibility offer revocation notification submitted to the DSO
Failure outcome	RejectionReason	Cause of rejection
	<See Message validation>	FlexOfferRevocation failed to pass validation by the DSO
	Flexibility procured	The FlexOffer cannot be revoked because its flexibility has already been ordered
	[User defined]	Any other reasonable cause to reject the message

### Related information The process is similar to that described in [Revocation Flexibility Offer](validate-phase.md#revocation-flexibility-offer). Flexibility offers may be revoked in the operate phase provided that none of the ISPs in the period the offer applies to are already in, or past, the operate phase. ## Exchange Flexibility Orders This process is triggered when flexibility is required to resolve congestion detected during the operate phase. This might, for example, be the case when the prognoses change after the validate phase and there are still FlexOffers available. The process diagram is similar to the figure in [Exchange Flexibility Orders](validate-phase.md#exchange-flexibility-orders).

	Revoke FlexOrder
Goal in context	Accept (some) flexibility offers to solve congestion during Operate phase.
Preconditions	Congestion detected while monitoring the grid, corresponding FlexOffer has been received and accepted by DSO and is still valid.
Successful outcome	Flexibility procured
Failure outcome	RejectionReason	Cause of rejection
	<See Message validation>	FlexOrder failed to pass validation by the AGR
	ISP mismatch	ISPs from the FlexOrder do not match the ISPs given in the FlexOffer
	Power mismatch	Ordered flexibility does not match the offered flexibility
	Price mismatch	Price in the order does not match the price given in the offer
	[User defined]	Any other reasonable cause to reject the message

### Related information The process is similar to that described in [Exchange Flexibility Orders](validate-phase.md#exchange-flexibility-orders). Note that where a FlexOrder is rejected, manual processing is unlikely to result in timely resolution at this stage. Note that although the updated D-prognosis is unlikely to be of immediate use to the DSO, it’s definitely required for settlement.