diff --git a/enhancements/update/targeted-update-edge-blocking.md b/enhancements/update/targeted-update-edge-blocking.md
index c707035a65..eab1cd58c3 100644
--- a/enhancements/update/targeted-update-edge-blocking.md
+++ b/enhancements/update/targeted-update-edge-blocking.md
@@ -198,7 +198,6 @@ type ConditionalUpdate struct {
 
 	// conditions represents the observations of the conditional update's
 	// current status. Known types are:
-	// * Evaluating, for whether the cluster-version operator will attempt to evaluate any risks[].matchingRules.
 	// * Recommended, for whether the update is recommended for the current cluster.
 	// +patchMergeKey=type
 	// +patchStrategy=merge
@@ -314,12 +313,10 @@ Including edges which are recommended for no clusters under `conditionalEdges` g
 ### Cluster-version operator support for the enhanced schema
 
 The cluster-version operator will learn to parse [`conditionalEdges`](#enhanced-cincinnati-json-representation) into [`conditionalUpdates`](#enhanced-clusterversion-representation).
-For `conditionalUpdates` entries where each `risks` entry contains at least one recognized `matchingRules` entry, the operator will set the `Evaluating` condition to `True`.
-Otherwise the `Evaluating` condition will be set to `False`, and the `Recommended` condition can be immediately set to `False` (if there are no `matchingRules` entries at all) or `Unknown` (if there are unrecognized `matchingRules` entries).
-`edges` will continue to go straight into `availableUpdates`.
+The `Recommended` condition can be immediately set to `Unknown` until the `matchingRules` for all the update's risks have been evaluated.
 The operator will log an error if the same target is included in both `edges` and `conditionalEdges`, but will prefer the `conditionalEdges` entry in that case.
 
-Additionally, the operator will continually re-evaluate the blocking conditionals in `conditionalUpdates` and update `conditionalUpdates[].risks` accordingly.
+Additionally, the operator will continually re-evaluate the blocking conditionals in `conditionalUpdates` and update `conditionalUpdates[].conditions` accordingly.
 The timing of the evaluation and freshness are largely internal details, but to avoid [consuming excessive monitoring resources](#malicious-conditions) and because [the rules should be based on slowly-changing state](#clusters-moving-into-the-vulnerable-state-after-updating), the operator will handle polling with the following restrictions:
 
 * The cluster-version operator will cache polling results for each query, so a single query which is used in evaluating multiple risks over multiple conditional update targets will only be evaluated once per round.
@@ -535,10 +532,6 @@ status:
             or
             0 * cluster_infrastructure_provider
     conditions:
-    - lastTransitionTime: 2021-08-28T01:00:00Z
-      type: Evaluating
-      status: True
-      reason: Periodically evaluating risks associated with this update.
     - lastTransitionTime: 2021-08-28T01:05:00Z
       type: Recommended
       status: False