From 6894f7fc94e1a247f1d33ee15b79362221cd77bd Mon Sep 17 00:00:00 2001
From: Kate Shvaika <kshvaika@redhat.com>
Date: Wed, 25 Mar 2026 10:14:18 +0100
Subject: [PATCH 1/5] stp for new scratch space SC selection logic

Signed-off-by: Kate Shvaika <kshvaika@redhat.com>
---
 .../scratch_space_sc_selection_logic.md       | 428 ++++++++++++++++++
 1 file changed, 428 insertions(+)
 create mode 100644 stps/sig-storage/scratch_space_sc_selection_logic.md

diff --git a/stps/sig-storage/scratch_space_sc_selection_logic.md b/stps/sig-storage/scratch_space_sc_selection_logic.md
new file mode 100644
index 00000000..4735a857
--- /dev/null
+++ b/stps/sig-storage/scratch_space_sc_selection_logic.md
@@ -0,0 +1,428 @@
+# Openshift-virtualization-tests Test plan
+
+## **Scratch Space Storage Class Selection Logic - Quality Engineering Plan**
+
+### **Metadata & Tracking**
+
+- **Enhancement(s):**
+  - [CDI Enhancement](https://github.com/kubevirt/containerized-data-importer)
+  - [HCO PR #4104](https://github.com/kubevirt/hyperconverged-cluster-operator/pull/4104)
+- **Feature Tracking:** https://issues.redhat.com/browse/CNV-72238
+- **Epic Tracking:** https://issues.redhat.com/browse/CNV-79031
+- **QE Owner(s):** Kate Shvaika (kshvaika@redhat.com)
+- **Owning SIG:** sig-storage
+- **Participating SIGs:** sig-storage
+
+**Document Conventions (if applicable):**
+- **SC** - Storage Class
+- **HCO** - HyperConverged Cluster Operator
+- **CDI** - Containerized Data Importer
+- **PVC** - Persistent Volume Claim
+
+### **Feature Overview**
+
+This feature changes the default scratch space storage class selection logic in CDI. The new behavior uses the same storage class as the target PVC for scratch space allocation instead of falling back to virt-default or default storage classes. This aligns with customer expectations that all provisioning for a particular disk should use the same storage class. The scratchSpaceStorageClass HCO configuration option continues to override this behavior when explicitly set.
+
+---
+
+### **I. Motivation and Requirements Review (QE Review Guidelines)**
+
+This section documents the mandatory QE review process. The goal is to understand the feature's value,
+technology, and testability before formal test planning.
+
+#### **1. Requirement & User Story Review Checklist**
+
+<!-- **How to complete this checklist:**
+1. **Checkbox**: Mark [x] if the check is complete; if the item cannot be checked - add an explanation why in the `details` section
+2. Complete the relevant, needed details for the checklist item -->
+
+- [ ] **Review Requirements**
+  <!-- Review the D/S (Downstream) requirements as defined in Jira. Understand the difference between Upstream (U/S) and D/S requirements.
+  Example: "VMs must migrate without network downtime exceeding the defined threshold during node maintenance." -->
+  - *List the key D/S requirements reviewed:*
+    - CDI default behavior changed: scratch space now uses same storage class as target PVC
+    - New logic: scratchSpaceStorageClass config -> same-as-target SC
+    - Previous logic: scratchSpaceStorageClass config -> virt-default SC -> default SC
+    - scratchSpaceStorageClass HCO config continues to take priority when explicitly configured
+    - Customer-visible behavior change for users not using scratchSpaceStorageClass config
+
+- [ ] **Understand Value and Customer Use Cases**
+  <!-- Understand why the feature matters to customers from a D/S perspective and what the real-world use cases are.
+  Example: "Customers need to migrate VMs without network downtime to maintain SLA compliance during node maintenance." -->
+  - *Describe the feature's value to customers:*
+    - VM owners want consistent storage class usage for all disk provisioning operations, including scratch space
+    - When provisioning a disk, customers expect scratch space to use that same storage class as target
+  - *List the customer use cases identified:*
+    - When provisioning a disk, scratch space should use the same storage class as that disk
+
+- [ ] **Testability**
+  <!-- Confirmed requirements are **testable and unambiguous**. -->
+  - *Note any requirements that are unclear or untestable:* None - all requirements are testable through CDI operations (clone, import, upload) with various storage class configurations
+
+- [x] **Acceptance Criteria**
+  <!-- Acceptance criteria are the specific, verifiable conditions that must be met for the feature to be considered complete — they define *how we know it works*.
+  Example: "VM migrates without network downtime exceeding 500ms", "VM deletion is blocked for non-admin users." -->
+  - *List the acceptance criteria:*
+    - scratch space uses same storage class as target PVC if scratchSpaceStorageClass is not set in HCO config
+    - scratchSpaceStorageClass HCO config takes priority when explicitly set
+    - New selection order: scratchSpaceStorageClass config -> same-as-target SC
+    - CDI functional tests verify new behavior and scratchSpaceStorageClass config override
+  - *Note any gaps or missing criteria:* None
+
+- [ ] **Non-Functional Requirements (NFRs)**
+  <!-- Confirmed coverage for NFRs, including Performance, Security, Usability, Downtime, Connectivity, Monitoring (alerts/metrics), Scalability, Portability (e.g., cloud support), and Docs.-->
+  - *List applicable NFRs and their targets:*
+    - Existing CDI metrics should reflect scratch space creation
+    - Documentation update is required to explain new default behavior
+  - *Note any NFRs not covered and why:*
+    Performance and scale testing are not included in this test plan
+
+#### **2. Known Limitations**
+
+The limitations are documented to ensure alignment between development, QA, and product teams.
+The following are confirmed product constraints accepted before testing begins.
+
+<!-- **Difference from Risks:** Limitations are *known facts* — confirmed constraints that are accepted before testing begins.
+Risks are *uncertainties* — things that might happen and could impact testing.
+Example: "Feature does not support IPv6" is a **limitation** (known, confirmed, won't change this release).
+"IPv6 cluster might not be available for testing" is a **risk** (uncertain, needs a mitigation plan). -->
+
+<!-- Document limitations in the feature itself — constraints, trade-offs, or unsupported scenarios in the product implementation.
+
+**Examples:**
+- The feature only supports YYY storage class
+- Feature does not support IPv6 (only IPv4)
+- No support for ARM64 architecture in this release
+- The feature is incompatible with ZZZ feature
+
+If there are no feature limitations, remove the example items and state: "None — reviewed and confirmed with [Name/Date] that no feature limitations apply for this release." -->
+
+- **[Feature Limitation 1]**
+  - *Sign-off:* [Name/Date — confirms awareness and acceptance of this limitation]
+
+- **[Feature Limitation 2]**
+  - *Sign-off:* [Name/Date — confirms awareness and acceptance of this limitation]
+
+Need to be updated: None identified at this time.
+
+
+#### **3. Technology and Design Review**
+
+<!-- **How to complete this checklist:**
+1. **Checkbox**: Mark [x] if done
+2. Complete the relevant, needed details for the checklist item -->
+
+- [ ] **Developer Handoff/QE Kickoff**
+  <!-- A meeting where Dev/Arch walked QE through the design, architecture, and implementation details. **Critical for identifying untestable aspects early.**-->
+  - *Key takeaways and concerns:* [Summarize key points and concerns]
+
+- [x] **Technology Challenges**
+  <!-- Identified potential testing challenges related to the underlying technology.-->
+  - *List identified challenges:*
+    - Multiple CDI operations can trigger scratch space allocation (clone, import, upload)
+  - *Impact on testing approach:*
+    - Tests must cover all CDI operations that use scratch space
+
+- [x] **API Extensions**
+  <!-- Review new or modified APIs and their impact on testing. Covers both new tests for new APIs and updates to existing tests for modified APIs.
+  Example: "New VirtualMachineSnapshot API v1beta2 — 3 new endpoints, 1 modified endpoint. Existing snapshot tests need updating." -->
+  - *List new or modified APIs:*
+    - No API changes - internal CDI logic change only
+    - scratchSpaceStorageClass HCO config option unchanged
+  - *Testing impact:*
+    - No API testing updates required
+    - Functional tests update required
+
+- [x] **Test Environment Needs**
+  <!-- Identified whether special environment setups are needed beyond standard infrastructure.-->
+  - *See environment requirements in Section II.3 and testing tools in Section II.3.1*
+    - Ability to modify HCO configuration (for scratchSpaceStorageClass override testing)
+
+- [x] **Topology Considerations**
+  <!-- Evaluated multi-cluster, network topology, and architectural impacts.-->
+  - *Describe topology requirements:* Standard cluster topology sufficient
+  - *Impact on test design:* No special topology requirements
+
+### **II. Software Test Plan (STP)**
+
+This STP serves as the **overall roadmap for testing**, detailing the scope, approach, resources, and schedule.
+
+#### **1. Scope of Testing**
+
+<!-- Briefly describe what will be tested. The scope must **cover functional and non-functional requirements**.
+Must ensure user stories are included and aligned to downstream user stories from Section I. -->
+
+**Testing Goals**
+
+<!-- Testing goals are specific, measurable objectives — they say *what* must be verified and *how* success is measured.
+
+Define specific, measurable testing objectives for this feature using **SMART criteria**
+(Specific, Measurable, Achievable, Relevant, Time-bound).
+Each goal should tie back to requirements from Section I and be independently verifiable.
+
+**How to Define Good Testing Goals:**
+- **Specific**: Clearly state what will be tested (not "test the feature" but "validate VM live migration
+  with SR-IOV networks")
+- **Measurable**: Define quantifiable success criteria (e.g., "95% of VM migrations complete within xxx seconds")
+- **Achievable**: Realistic given resources and timeline
+- **Relevant**: Directly supports feature acceptance criteria and user stories
+- **Verifiable**: Can be objectively confirmed as complete
+
+**Priority Levels:**
+- **P0**: Blocking GA - must be complete before release
+- **P1**: High priority - required for full feature coverage
+- **P2**: Nice-to-have - can be deferred if timeline constraints exist -->
+
+- **[P0]** Verify scratch space uses same-as-target storage class by default (new behavior)
+- **[P0]** Validate scratchSpaceStorageClass HCO config takes priority over same-as-target logic when explicitly set
+- **[P0]** Confirm all CDI operations requiring scratch space (clone, import, upload) use new selection logic
+
+**Out of Scope (Testing Scope Exclusions)**
+
+The following items are explicitly Out of Scope for this test cycle and represent intentional exclusions.
+No verification activities will be performed for these items, and any related issues found will not be classified as defects for this release.
+
+<!-- **What does Out of Scope mean?**
+Out of Scope items are areas where the product works, but QE has decided not to test them this cycle.
+This is the most critical section in the STP — it explicitly documents the gap between what the product can do and what QE will verify.
+Every item here is a conscious risk accepted by PM/Lead. If an untested area breaks in production, this section proves the decision was deliberate and agreed upon.
+Each item requires PM/Lead sign-off.
+
+**Difference from Risks:** A risk is something that *might* prevent testing — you plan to test it but it could be blocked and you provide a mitigation plan.
+Out of Scope means you have *decided not to test it* — the decision is final and accepted by stakeholders.
+Example: "MultiArch cluster might not be available" is a **risk**. "We will not test on bare-metal MultiArch clusters" is **out of scope**.
+
+**Note:** Replace examples with your actual out-of-scope items. If there are no items, remove the examples and state: "None — reviewed and confirmed that all supported product functionality will be tested this cycle." -->
+
+None
+
+**Test Limitations**
+
+<!-- Document limitations in the test approach — things that constrain how or what we can test, not the feature itself.
+These are distinct from feature limitations (Section I.2) which describe product constraints.
+
+**Difference from Out of Scope:** Test Limitations are constraints *imposed on QE* (e.g., no hardware, no cluster, no environment).
+Out of Scope are *decisions made by QE* (e.g., we choose not to test Windows guests).
+Example: "No bare-metal MultiArch cluster available" is a **test limitation** (QE can't test it even if they wanted to).
+"Windows guest OS will not be tested" is **out of scope** (QE chose not to test it).
+
+**Examples:**
+- CPU xxx will not be tested due to lack of hardware
+- Real integration with [Third-Party Service] cannot be tested; external calls will be mocked using static data due to access/licensing constraints
+- Performance testing limited to 100 VMs due to lab capacity
+- IPv6 testing constrained to single-stack due to dual-stack cluster unavailability
+
+If there are no test limitations, remove the example items and state: "None — reviewed and confirmed that no test limitations apply for this release." -->
+
+None — reviewed and confirmed that no test limitations apply for this release.
+
+#### **2. Test Strategy**
+
+<!-- The following test strategy considerations must be reviewed and addressed. Mark [x] if applicable,
+leave unchecked if not applicable (with justification in Details). Unchecked items without details
+indicate incomplete review.
+
+Note: Strategy defines *which types of testing* apply and the high-level approach. Goals (Section II.1) define the specific, measurable objectives.
+Example: Strategy says "Performance testing is applicable — we will measure migration stuntime." Goals say "[P0] Verify VM stuntime during live migration is below 500ms." -->
+
+**Functional**
+
+- [x] **Functional Testing** — Validates that the feature works according to specified requirements and user stories
+  - *Details:*
+    - Test new default scratch space SC selection (same-as-target)
+    - Test scratchSpaceStorageClass config override behavior
+    - Test all CDI operations that allocate scratch space
+    - Validate behavior with various storage class configurations
+
+- [x] **Automation Testing** — Confirms test automation plan is in place for CI and regression coverage (all tests are expected to be automated)
+  - *Details:*
+    - All functional tests will be automated
+
+- [x] **Regression Testing** — Verifies that new changes do not break existing functionality
+  - *Details:*
+    - Verify existing CDI operations work with new scratch space logic
+    - Confirm scratchSpaceStorageClass config continues to work as before (override behavior unchanged)
+
+**Non-Functional**
+
+- [x] **Performance Testing** — Validates feature performance meets requirements (latency, throughput, resource usage)
+  - *Details:*
+    - Test concurrent scratch space allocations
+
+- [ ] **Scale Testing** — Validates feature behavior under increased load and at production-like scale (e.g., large number of VMs, nodes, or concurrent operations)
+  - *Details:* N/A - inherits existing CDI scratch space scalability characteristics
+
+- [ ] **Security Testing** — Verifies security requirements, RBAC, authentication, authorization, and vulnerability scanning
+  - *Details:* N/A - no new RBAC or security requirements; uses existing CDI permissions
+
+- [x] **Usability Testing** — Validates user experience and accessibility requirements
+  - *Details:*
+    - CDI events/logs should indicate which storage class was selected for scratch space
+
+- [x] **Monitoring** — Does the feature require metrics and/or alerts?
+  - *Details:*
+    - Use existing CDI metrics for scratch space PVC creation
+
+**Integration & Compatibility**
+
+- [x] **Compatibility Testing** — Ensures feature works across supported platforms, versions, and configurations
+  - *Details:*
+    - Test with different storage providers
+
+- [ ] **Upgrade Testing** — Validates upgrade paths from previous versions, data migration, and configuration preservation
+  - *Details:* Not applicable
+
+- [ ] **Dependencies** — Blocked by deliverables from other components/products. Identify what we need from other teams before we can test.
+  - *Details:* Not applicable
+
+- [x] **Cross Integrations** — Does the feature affect other features or require testing by other teams? Identify the impact we cause.
+  - *Details:*
+    - Impacts CDI data import/clone/upload workflows
+
+**Infrastructure**
+
+- [ ] **Cloud Testing** — Does the feature require multi-cloud platform testing? Consider cloud-specific features.
+  - *Details:* Not applicable
+
+#### **3. Test Environment**
+<!-- **Note:** "N/A" means explicitly not applicable. All items must be filled or marked N/A. -->
+
+- **Cluster Topology:** 3-master/3-worker bare-metal
+  <!-- Change if different, e.g., SNO, Compact Cluster, HCP -->
+
+- **OCP & OpenShift Virtualization Version(s):** OCP 4.22 with OpenShift Virtualization 4.22
+  <!-- Specify exact versions to allow version traceability -->
+
+- **CPU Virtualization:** VT-x (Intel) or AMD-V enabled
+  <!-- Change only if specific CPU requirements exist -->
+
+- **Compute Resources:** Minimum per worker node: 8 vCPUs, 32GB RAM
+  <!-- Adjust based on feature requirements -->
+
+- **Special Hardware:** N/A
+  <!-- Fill if needed, e.g., SR-IOV NICs, GPUs -->
+
+- **Storage:** ocs-storagecluster-ceph-rbd-virtualization, hostpath-provisioner, custom SC
+  <!-- Change if specific StorageClass(es) required -->
+
+- **Network:** OVN-Kubernetes, IPv4
+  <!-- Change if needed, e.g., Secondary Networks, IPv6, dual-stack -->
+
+- **Required Operators:** N/A
+  <!-- Add if needed, e.g., NMState Operator -->
+
+- **Platform:** PSIm, Bare metal
+  <!-- Change if needed, e.g., AWS, Azure, GCP -->
+
+- **Special Configurations:** N/A
+  <!-- Change if needed, e.g., Disconnected/air-gapped, Proxy, FIPS mode -->
+
+#### **3.1. Testing Tools & Frameworks**
+
+<!-- Document any **new or additional** testing tools, frameworks, or infrastructure required specifically
+for this feature. **Note:** Only list tools that are **new** or **different** from standard testing infrastructure. -->
+
+- **Test Framework:** Standard
+
+- **CI/CD:** Standard
+
+- **Other Tools:** N/A
+
+#### **4. Entry Criteria**
+
+The following conditions must be met before testing can begin:
+
+- [x] Requirements and design documents are **approved and merged**
+- [x] CDI implementation of new scratch space selection logic is **complete and merged**
+- [x] Test environment can be **set up and configured** (see Section II.3 - Test Environment)
+
+
+#### **5. Risks**
+
+<!-- Document specific risks for this feature. If a risk category is not applicable, mark as "N/A" with
+justification in mitigation strategy. -->
+
+**Timeline/Schedule**
+
+- **Risk:** N/A
+  - **Mitigation:** N/A
+  - *Estimated impact on schedule:* N/A
+  - *Sign-off:* TBD
+
+**Test Coverage**
+
+- **Risk:** N/A
+  - **Mitigation:** N/A
+  - *Areas with reduced coverage:* N/A
+  - *Sign-off:* TBD
+
+**Test Environment**
+
+- **Risk:** N/A
+  - **Mitigation:** Standard test environment is sufficient for testing this feature
+  - *Missing resources or infrastructure:* N/A
+  - *Sign-off:* TBD
+
+**Untestable Aspects**
+
+- **Risk:** Customer production storage configurations may differ from test environments
+  - **Mitigation:** Focus on logic correctness rather than specific storage class types
+  - *Alternative validation approach:* N/A
+  - *Sign-off:* TBD
+
+**Resource Constraints**
+
+- **Risk:** N/A
+  - **Mitigation:** N/A
+  - *Current capacity gaps:* N/A
+  - *Sign-off:* TBD
+
+**Dependencies**
+
+- **Risk:** N/A
+  - **Mitigation:** N/A
+  - *Dependent teams or components:* N/A
+  - *Sign-off:* TBD
+
+**Other**
+
+- **Risk:** N/A
+  - **Mitigation:** No external dependencies
+  - *Sign-off:* TBD
+
+---
+
+### **III. Test Scenarios & Traceability**
+
+<!-- This section links D/S requirements to test coverage, enabling reviewers to verify all requirements are tested. -->
+
+- **[CNV-72238]** — As a user, I want import operations to use the same storage class for scratch space as my target DataVolume
+  - *Test Scenario:* [Tier 2] Verify import requiring conversion allocates scratch space using target DataVolume storage class
+  - *Priority:* P0
+
+- **[CNV-72238]** — As a user, I want upload operations to use the same storage class for scratch space as my target DataVolume
+  - *Test Scenario:* [Tier 2] Verify upload operation allocates scratch space using target DataVolume storage class
+  - *Priority:* P0
+
+- **[CNV-72238]** — As a user, I want clone operations to use the same storage class for scratch space as my source PVC
+  - *Test Scenario:* [Tier 2] Verify PVC clone allocates scratch space using source PVC storage class
+  - *Priority:* P0
+
+- **[CNV-72238]** — As a cluster admin, I want scratchSpaceStorageClass configuration to propagate from HCO to CDI
+  - *Test Scenario:* [Tier 2] Verify scratchSpaceStorageClass set in HCO CR propagates to CDI CR configuration
+  - *Priority:* P0
+
+- **[CNV-72238]** — As a cluster admin, I want to configure scratch space storage class for import operations
+  - *Test Scenario:* [Tier 2] Verify import operation uses scratchSpaceStorageClass configured in HCO
+  - *Priority:* P0
+
+---
+
+### **IV. Sign-off and Approval**
+
+This Software Test Plan requires approval from the following stakeholders:
+
+* **Reviewers:**
+  - TBD
+* **Approvers:**
+  - TBD

From acae0701213a58e4cae4c4c229eb9e10fa709334 Mon Sep 17 00:00:00 2001
From: Kate Shvaika <kshvaika@redhat.com>
Date: Fri, 17 Apr 2026 11:21:38 +0200
Subject: [PATCH 2/5] changes according to the comments from review

Signed-off-by: Kate Shvaika <kshvaika@redhat.com>
---
 .../scratch_space_sc_selection_logic.md       | 41 ++++++++-----------
 1 file changed, 18 insertions(+), 23 deletions(-)

diff --git a/stps/sig-storage/scratch_space_sc_selection_logic.md b/stps/sig-storage/scratch_space_sc_selection_logic.md
index 4735a857..da027037 100644
--- a/stps/sig-storage/scratch_space_sc_selection_logic.md
+++ b/stps/sig-storage/scratch_space_sc_selection_logic.md
@@ -4,9 +4,7 @@
 
 ### **Metadata & Tracking**
 
-- **Enhancement(s):**
-  - [CDI Enhancement](https://github.com/kubevirt/containerized-data-importer)
-  - [HCO PR #4104](https://github.com/kubevirt/hyperconverged-cluster-operator/pull/4104)
+- **Enhancement(s):** https://github.com/kubevirt/containerized-data-importer/pull/4054
 - **Feature Tracking:** https://issues.redhat.com/browse/CNV-72238
 - **Epic Tracking:** https://issues.redhat.com/browse/CNV-79031
 - **QE Owner(s):** Kate Shvaika (kshvaika@redhat.com)
@@ -21,7 +19,7 @@
 
 ### **Feature Overview**
 
-This feature changes the default scratch space storage class selection logic in CDI. The new behavior uses the same storage class as the target PVC for scratch space allocation instead of falling back to virt-default or default storage classes. This aligns with customer expectations that all provisioning for a particular disk should use the same storage class. The scratchSpaceStorageClass HCO configuration option continues to override this behavior when explicitly set.
+Some VM disk provisioning operations require temporary scratch space. This feature changes the default storage class selection for scratch space: it now uses the same storage class as the target disk, instead of falling back to the cluster default. Administrators can configure a specific storage class for scratch space to override this behavior.
 
 ---
 
@@ -36,26 +34,24 @@ technology, and testability before formal test planning.
 1. **Checkbox**: Mark [x] if the check is complete; if the item cannot be checked - add an explanation why in the `details` section
 2. Complete the relevant, needed details for the checklist item -->
 
-- [ ] **Review Requirements**
+- [x] **Review Requirements**
   <!-- Review the D/S (Downstream) requirements as defined in Jira. Understand the difference between Upstream (U/S) and D/S requirements.
   Example: "VMs must migrate without network downtime exceeding the defined threshold during node maintenance." -->
   - *List the key D/S requirements reviewed:*
-    - CDI default behavior changed: scratch space now uses same storage class as target PVC
-    - New logic: scratchSpaceStorageClass config -> same-as-target SC
-    - Previous logic: scratchSpaceStorageClass config -> virt-default SC -> default SC
-    - scratchSpaceStorageClass HCO config continues to take priority when explicitly configured
-    - Customer-visible behavior change for users not using scratchSpaceStorageClass config
+    - When no scratch space storage class is configured, scratch space must use the same storage class as the target disk
+    - When a scratch space storage class is explicitly configured by the administrator, it must override the default same-as-target behavior
+    - Existing administrator configurations for scratch space storage class must continue to work unchanged
 
-- [ ] **Understand Value and Customer Use Cases**
+- [x] **Understand Value and Customer Use Cases**
   <!-- Understand why the feature matters to customers from a D/S perspective and what the real-world use cases are.
   Example: "Customers need to migrate VMs without network downtime to maintain SLA compliance during node maintenance." -->
   - *Describe the feature's value to customers:*
-    - VM owners want consistent storage class usage for all disk provisioning operations, including scratch space
-    - When provisioning a disk, customers expect scratch space to use that same storage class as target
+    - Ensures consistent storage provisioning behavior, reducing confusion and configuration errors
+    - Aligns temporary resource allocation with production storage requirements
   - *List the customer use cases identified:*
-    - When provisioning a disk, scratch space should use the same storage class as that disk
+    - As a VM owner, I want scratch space to use the same storage class as my disk so that provisioning is consistent
 
-- [ ] **Testability**
+- [x] **Testability**
   <!-- Confirmed requirements are **testable and unambiguous**. -->
   - *Note any requirements that are unclear or untestable:* None - all requirements are testable through CDI operations (clone, import, upload) with various storage class configurations
 
@@ -63,10 +59,9 @@ technology, and testability before formal test planning.
   <!-- Acceptance criteria are the specific, verifiable conditions that must be met for the feature to be considered complete — they define *how we know it works*.
   Example: "VM migrates without network downtime exceeding 500ms", "VM deletion is blocked for non-admin users." -->
   - *List the acceptance criteria:*
-    - scratch space uses same storage class as target PVC if scratchSpaceStorageClass is not set in HCO config
-    - scratchSpaceStorageClass HCO config takes priority when explicitly set
-    - New selection order: scratchSpaceStorageClass config -> same-as-target SC
-    - CDI functional tests verify new behavior and scratchSpaceStorageClass config override
+    - When no explicit scratch space storage class is configured, scratch space uses the same storage class as the target PVC
+    - When an explicit scratch space storage class is configured, scratch space uses that configured storage class
+    - Automated tests verify both default (same-as-target) and explicitly configured scratch space storage class behaviors
   - *Note any gaps or missing criteria:* None
 
 - [ ] **Non-Functional Requirements (NFRs)**
@@ -173,9 +168,9 @@ Each goal should tie back to requirements from Section I and be independently ve
 - **P1**: High priority - required for full feature coverage
 - **P2**: Nice-to-have - can be deferred if timeline constraints exist -->
 
-- **[P0]** Verify scratch space uses same-as-target storage class by default (new behavior)
-- **[P0]** Validate scratchSpaceStorageClass HCO config takes priority over same-as-target logic when explicitly set
-- **[P0]** Confirm all CDI operations requiring scratch space (clone, import, upload) use new selection logic
+- **[P0]** Verify that disk provisioning operations automatically allocate scratch space using the same storage class as the target disk when no cluster-level override is configured
+- **[P0]** Validate that cluster administrator configuration for scratch space storage class takes priority over the default behavior
+- **[P0]** Confirm consistent scratch space storage class selection across all disk provisioning workflows (clone, import, upload)
 
 **Out of Scope (Testing Scope Exclusions)**
 
@@ -311,7 +306,7 @@ Example: Strategy says "Performance testing is applicable — we will measure mi
 - **Required Operators:** N/A
   <!-- Add if needed, e.g., NMState Operator -->
 
-- **Platform:** PSIm, Bare metal
+- **Platform:** PSI, Bare metal
   <!-- Change if needed, e.g., AWS, Azure, GCP -->
 
 - **Special Configurations:** N/A

From 1e6e38fdd5091e7dda220bc3cb22d40dcd70c888 Mon Sep 17 00:00:00 2001
From: Kate Shvaika <kshvaika@redhat.com>
Date: Tue, 5 May 2026 14:40:43 +0200
Subject: [PATCH 3/5] added maturity

Signed-off-by: Kate Shvaika <kshvaika@redhat.com>
---
 .../sig-storage/scratch_space_sc_selection_logic.md | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/stps/sig-storage/scratch_space_sc_selection_logic.md b/stps/sig-storage/scratch_space_sc_selection_logic.md
index da027037..c1801884 100644
--- a/stps/sig-storage/scratch_space_sc_selection_logic.md
+++ b/stps/sig-storage/scratch_space_sc_selection_logic.md
@@ -7,6 +7,19 @@
 - **Enhancement(s):** https://github.com/kubevirt/containerized-data-importer/pull/4054
 - **Feature Tracking:** https://issues.redhat.com/browse/CNV-72238
 - **Epic Tracking:** https://issues.redhat.com/browse/CNV-79031
+- **Feature Maturity:**
+  <!-- List each maturity phase with its target version. Use N/A for phases that don't apply.
+  Standard phases: Dev Preview (DP), Tech Preview (TP), General Availability (GA).
+  For features already GA with no prior phases, only list GA.
+
+  Example:
+  - DP: N/A
+  - TP: 4.22
+  - GA: 5.0 -->
+
+  - DP: [version or N/A]
+  - TP: [version or N/A]
+  - GA: [version]
 - **QE Owner(s):** Kate Shvaika (kshvaika@redhat.com)
 - **Owning SIG:** sig-storage
 - **Participating SIGs:** sig-storage

From cfe77f3617d83e4e0a0a65dbc1c505848ff42ce1 Mon Sep 17 00:00:00 2001
From: Kate Shvaika <kshvaika@redhat.com>
Date: Wed, 6 May 2026 16:27:30 +0200
Subject: [PATCH 4/5] resolve comments

Signed-off-by: Kate Shvaika <kshvaika@redhat.com>
---
 .../scratch_space_sc_selection_logic.md       | 199 +++++++++---------
 1 file changed, 100 insertions(+), 99 deletions(-)

diff --git a/stps/sig-storage/scratch_space_sc_selection_logic.md b/stps/sig-storage/scratch_space_sc_selection_logic.md
index c1801884..47a52f3c 100644
--- a/stps/sig-storage/scratch_space_sc_selection_logic.md
+++ b/stps/sig-storage/scratch_space_sc_selection_logic.md
@@ -24,11 +24,8 @@
 - **Owning SIG:** sig-storage
 - **Participating SIGs:** sig-storage
 
-**Document Conventions (if applicable):**
-- **SC** - Storage Class
-- **HCO** - HyperConverged Cluster Operator
-- **CDI** - Containerized Data Importer
-- **PVC** - Persistent Volume Claim
+**Document Conventions (if applicable):** N/A
+
 
 ### **Feature Overview**
 
@@ -77,13 +74,18 @@ technology, and testability before formal test planning.
     - Automated tests verify both default (same-as-target) and explicitly configured scratch space storage class behaviors
   - *Note any gaps or missing criteria:* None
 
-- [ ] **Non-Functional Requirements (NFRs)**
+- [x] **Non-Functional Requirements (NFRs)**
   <!-- Confirmed coverage for NFRs, including Performance, Security, Usability, Downtime, Connectivity, Monitoring (alerts/metrics), Scalability, Portability (e.g., cloud support), and Docs.-->
   - *List applicable NFRs and their targets:*
-    - Existing CDI metrics should reflect scratch space creation
-    - Documentation update is required to explain new default behavior
+    - **Documentation:** Documentation update is required to explain new default behavior
   - *Note any NFRs not covered and why:*
-    Performance and scale testing are not included in this test plan
+    - **UI:** Not applicable. backend storage class selection logic only, no UI changes.
+    - **Monitoring:** Not applicable. Existing metrics reflect scratch space creation, no new metrics required
+    - **Observability:** Not applicable. Scratch space allocation is logged through existing CDI events
+    - **Performance:** Not applicable. No impact on provisioning performance
+    - **Security:** Not applicable. Uses existing CDI RBAC for storage operations, no new security requirements.
+    - **Scalability:** Not applicable. Selection logic scales with existing CDI controller capabilities
+
 
 #### **2. Known Limitations**
 
@@ -96,22 +98,9 @@ Example: "Feature does not support IPv6" is a **limitation** (known, confirmed,
 "IPv6 cluster might not be available for testing" is a **risk** (uncertain, needs a mitigation plan). -->
 
 <!-- Document limitations in the feature itself — constraints, trade-offs, or unsupported scenarios in the product implementation.
-
-**Examples:**
-- The feature only supports YYY storage class
-- Feature does not support IPv6 (only IPv4)
-- No support for ARM64 architecture in this release
-- The feature is incompatible with ZZZ feature
-
 If there are no feature limitations, remove the example items and state: "None — reviewed and confirmed with [Name/Date] that no feature limitations apply for this release." -->
 
-- **[Feature Limitation 1]**
-  - *Sign-off:* [Name/Date — confirms awareness and acceptance of this limitation]
-
-- **[Feature Limitation 2]**
-  - *Sign-off:* [Name/Date — confirms awareness and acceptance of this limitation]
-
-Need to be updated: None identified at this time.
+None — reviewed and confirmed with Kate Shvaika, Danny Sanatar / 2026-05-05 that no feature limitations apply for this release.
 
 
 #### **3. Technology and Design Review**
@@ -120,9 +109,9 @@ Need to be updated: None identified at this time.
 1. **Checkbox**: Mark [x] if done
 2. Complete the relevant, needed details for the checklist item -->
 
-- [ ] **Developer Handoff/QE Kickoff**
+- [x] **Developer Handoff/QE Kickoff**
   <!-- A meeting where Dev/Arch walked QE through the design, architecture, and implementation details. **Critical for identifying untestable aspects early.**-->
-  - *Key takeaways and concerns:* [Summarize key points and concerns]
+  - *Key takeaways and concerns:* Reviewed changes in Scratch Space Storage Class Selection Logic with the developer. Untestable aspects were not identified.
 
 - [x] **Technology Challenges**
   <!-- Identified potential testing challenges related to the underlying technology.-->
@@ -202,7 +191,19 @@ Example: "MultiArch cluster might not be available" is a **risk**. "We will not
 
 **Note:** Replace examples with your actual out-of-scope items. If there are no items, remove the examples and state: "None — reviewed and confirmed that all supported product functionality will be tested this cycle." -->
 
-None
+- **[e.g., Core OCP network functionality]**
+  - *Rationale:* The core functionality is already covered by the OCP Network team; no duplication of their test effort
+  - *PM/Lead Agreement:* [Name/Date]
+
+- **[e.g., Special guest OS coverage (e.g., Windows)]**
+  - *Rationale:* Feature is expected to work with Windows guests but no explicit tests are planned; validation uses Fedora-based guests
+  - *PM/Lead Agreement:* [Name/Date]
+  - 
+None — reviewed and confirmed that all supported product functionality will be tested this cycle.
+  - *Rationale:* Feature changes default storage class selection logic for scratch space only. Scope is narrow and well-defined with clear testable behaviors (default same-as-target vs configured override). All
+   user-facing functionality can be verified through standard disk provisioning operations.
+  - *PM/Lead Agreement:* [Name/Date]
+
 
 **Test Limitations**
 
@@ -222,7 +223,7 @@ Example: "No bare-metal MultiArch cluster available" is a **test limitation** (Q
 
 If there are no test limitations, remove the example items and state: "None — reviewed and confirmed that no test limitations apply for this release." -->
 
-None — reviewed and confirmed that no test limitations apply for this release.
+None — reviewed and confirmed with Kate Shvaika/2026-05-05 that no test limitations apply for this release.
 
 #### **2. Test Strategy**
 
@@ -253,49 +254,47 @@ Example: Strategy says "Performance testing is applicable — we will measure mi
 
 **Non-Functional**
 
-- [x] **Performance Testing** — Validates feature performance meets requirements (latency, throughput, resource usage)
-  - *Details:*
-    - Test concurrent scratch space allocations
+- [ ] **Performance Testing** — Validates feature performance meets requirements (latency, throughput, resource usage)
+  - *Details:* no impact on provisioning performance
 
 - [ ] **Scale Testing** — Validates feature behavior under increased load and at production-like scale (e.g., large number of VMs, nodes, or concurrent operations)
-  - *Details:* N/A - inherits existing CDI scratch space scalability characteristics
+  - *Details:* N/A - Selection logic scales with existing CDI controller capabilities
 
 - [ ] **Security Testing** — Verifies security requirements, RBAC, authentication, authorization, and vulnerability scanning
-  - *Details:* N/A - no new RBAC or security requirements; uses existing CDI permissions
+  - *Details:* no new security requirements 
 
-- [x] **Usability Testing** — Validates user experience and accessibility requirements
-  - *Details:*
-    - CDI events/logs should indicate which storage class was selected for scratch space
+- [ ] **Usability Testing** — Validates user experience and accessibility requirements
+  - *Details:* N/A - Backend storage class selection logic only
+
+- [ ] **Monitoring** — Does the feature require metrics and/or alerts?
+  - *Details:* no new metrics required 
 
-- [x] **Monitoring** — Does the feature require metrics and/or alerts?
-  - *Details:*
-    - Use existing CDI metrics for scratch space PVC creation
 
 **Integration & Compatibility**
 
 - [x] **Compatibility Testing** — Ensures feature works across supported platforms, versions, and configurations
-  - *Details:*
-    - Test with different storage providers
+  - Does the feature maintain backward compatibility with previous API versions and configurations?
+  - *Details:*  Test with different storage class types (OCS, HPP)
 
-- [ ] **Upgrade Testing** — Validates upgrade paths from previous versions, data migration, and configuration preservation
-  - *Details:* Not applicable
+- [x] **Upgrade Testing** — Validates upgrade paths from previous versions, data migration, and configuration preservation
+  - *Details:* Verify existing scratchSpaceStorageClass configurations are preserved during upgrade. Verify new default behavior (same-as-target) applies to operations started after upgrade.
 
-- [ ] **Dependencies** — Blocked by deliverables from other components/products. Identify what we need from other teams before we can test.
-  - *Details:* Not applicable
+- [x] **Dependencies** — Blocked by deliverables from other components/products. Identify what we need from other teams before we can test.
+  - *Details:* Not applicable. No Dependencies.
 
 - [x] **Cross Integrations** — Does the feature affect other features or require testing by other teams? Identify the impact we cause.
-  - *Details:*
-    - Impacts CDI data import/clone/upload workflows
+  - *Details:* Not applicable. Changes do not affect other features.
+
 
 **Infrastructure**
 
-- [ ] **Cloud Testing** — Does the feature require multi-cloud platform testing? Consider cloud-specific features.
+- [x] **Cloud Testing** — Does the feature require multi-cloud platform testing? Consider cloud-specific features.
   - *Details:* Not applicable
 
 #### **3. Test Environment**
 <!-- **Note:** "N/A" means explicitly not applicable. All items must be filled or marked N/A. -->
 
-- **Cluster Topology:** 3-master/3-worker bare-metal
+- **Cluster Topology:** standard 3-master/3-worker
   <!-- Change if different, e.g., SNO, Compact Cluster, HCP -->
 
 - **OCP & OpenShift Virtualization Version(s):** OCP 4.22 with OpenShift Virtualization 4.22
@@ -350,53 +349,53 @@ The following conditions must be met before testing can begin:
 <!-- Document specific risks for this feature. If a risk category is not applicable, mark as "N/A" with
 justification in mitigation strategy. -->
 
-**Timeline/Schedule**
-
-- **Risk:** N/A
-  - **Mitigation:** N/A
-  - *Estimated impact on schedule:* N/A
-  - *Sign-off:* TBD
-
-**Test Coverage**
-
-- **Risk:** N/A
-  - **Mitigation:** N/A
-  - *Areas with reduced coverage:* N/A
-  - *Sign-off:* TBD
-
-**Test Environment**
-
-- **Risk:** N/A
-  - **Mitigation:** Standard test environment is sufficient for testing this feature
-  - *Missing resources or infrastructure:* N/A
-  - *Sign-off:* TBD
-
-**Untestable Aspects**
-
-- **Risk:** Customer production storage configurations may differ from test environments
-  - **Mitigation:** Focus on logic correctness rather than specific storage class types
-  - *Alternative validation approach:* N/A
-  - *Sign-off:* TBD
-
-**Resource Constraints**
-
-- **Risk:** N/A
-  - **Mitigation:** N/A
-  - *Current capacity gaps:* N/A
-  - *Sign-off:* TBD
-
-**Dependencies**
-
-- **Risk:** N/A
-  - **Mitigation:** N/A
-  - *Dependent teams or components:* N/A
-  - *Sign-off:* TBD
-
-**Other**
-
-- **Risk:** N/A
-  - **Mitigation:** No external dependencies
-  - *Sign-off:* TBD
+  **Timeline/Schedule**                       
+                                              
+  - **Risk:** N/A
+    - **Mitigation:** Standard test timeline is sufficient for planned test scenarios. Feature scope is narrow with straightforward test cases.                                                                      
+    - *Estimated impact on schedule:* None                                                                                                                                                                          
+    - *Sign-off:* Kate Shvaika/2026-05-05                                                                                                                                                                                 
+                                                                                                                                                                                                                    
+  **Test Coverage**                                                                                                                                                                                                 
+   
+  - **Risk:** N/A                                                                                                                                                                   
+    - **Mitigation:** All acceptance criteria are covered by planned test scenarios.
+    - *Areas with reduced coverage:* None                                                                                                                                                                           
+    - *Sign-off:* Kate Shvaika/2026-05-05                         
+                                              
+  **Test Environment**                                                                                                                                                                                              
+   
+  - **Risk:** N/A                                                                                                                                      
+    - **Mitigation:** Standard test environment with multiple storage classes is sufficient for testing this feature
+    - *Missing resources or infrastructure:* None                                                                                                                                                                   
+    - *Sign-off:* Kate Shvaika/2026-05-05                         
+                                              
+  **Untestable Aspects**                                                                                                                                                                                            
+   
+  - **Risk:** N/A                                                                                                            
+    - **Mitigation:** All scenarios can be reproduced in test environment
+    - *Alternative validation approach:* None                                     
+    - *Sign-off:* Kate Shvaika/2026-05-05                                                                                                                                                                                
+                                          
+  **Resource Constraints**                                                                                                                                                                                          
+                                                                                                                                                                                                                    
+  - **Risk:** N/A                                                                                                                                               
+    - **Mitigation:** Current QE team capacity is sufficient for planned test execution                                                                                                                             
+    - *Current capacity gaps:* None                         
+    - *Sign-off:* Kate Shvaika/2026-05-05                                                                                                                                                                               
+   
+  **Dependencies**                                                                                                                                                                                                  
+                                                            
+  - **Risk:** N/A
+    - **Mitigation:** No external dependencies.                                                                                       
+    - *Dependent teams or components:* Documentation team for behavior change documentation (non-blocking)
+    - *Sign-off:* Kate Shvaika/2026-05-05                                                                                                                                                                               
+                                                            
+  **Other**                                                                                                                                                                                                         
+   
+  - **Risk:** N/A                                                                                                                                                                      
+    - **Mitigation:** No additional mitigation required     
+    - *Sign-off:* Kate Shvaika/2026-05-05
 
 ---
 
@@ -430,7 +429,9 @@ justification in mitigation strategy. -->
 
 This Software Test Plan requires approval from the following stakeholders:
 
-* **Reviewers:**
-  - TBD
-* **Approvers:**
-  - TBD
+ * **Reviewers:**
+  - Jenia Peimer (@jpeimer)
+  - Jose Manuel Castano (@joscasta)
+  - Danny Sanatar (@dsanatar)
+ * **Approvers:**
+  - Ruth Netser (@rnetser)

From 925abd3f82e500a5212bc3558051bb0f1a738ec5 Mon Sep 17 00:00:00 2001
From: Kate Shvaika <kshvaika@redhat.com>
Date: Fri, 8 May 2026 17:41:23 +0200
Subject: [PATCH 5/5] added Feature Maturity

Signed-off-by: Kate Shvaika <kshvaika@redhat.com>
---
 .../scratch_space_sc_selection_logic.md       | 96 +++++++++----------
 1 file changed, 44 insertions(+), 52 deletions(-)

diff --git a/stps/sig-storage/scratch_space_sc_selection_logic.md b/stps/sig-storage/scratch_space_sc_selection_logic.md
index 47a52f3c..48fde7f9 100644
--- a/stps/sig-storage/scratch_space_sc_selection_logic.md
+++ b/stps/sig-storage/scratch_space_sc_selection_logic.md
@@ -11,15 +11,7 @@
   <!-- List each maturity phase with its target version. Use N/A for phases that don't apply.
   Standard phases: Dev Preview (DP), Tech Preview (TP), General Availability (GA).
   For features already GA with no prior phases, only list GA.
-
-  Example:
-  - DP: N/A
-  - TP: 4.22
-  - GA: 5.0 -->
-
-  - DP: [version or N/A]
-  - TP: [version or N/A]
-  - GA: [version]
+  - GA: 4.22
 - **QE Owner(s):** Kate Shvaika (kshvaika@redhat.com)
 - **Owning SIG:** sig-storage
 - **Participating SIGs:** sig-storage
@@ -198,7 +190,7 @@ Example: "MultiArch cluster might not be available" is a **risk**. "We will not
 - **[e.g., Special guest OS coverage (e.g., Windows)]**
   - *Rationale:* Feature is expected to work with Windows guests but no explicit tests are planned; validation uses Fedora-based guests
   - *PM/Lead Agreement:* [Name/Date]
-  - 
+  -
 None — reviewed and confirmed that all supported product functionality will be tested this cycle.
   - *Rationale:* Feature changes default storage class selection logic for scratch space only. Scope is narrow and well-defined with clear testable behaviors (default same-as-target vs configured override). All
    user-facing functionality can be verified through standard disk provisioning operations.
@@ -261,13 +253,13 @@ Example: Strategy says "Performance testing is applicable — we will measure mi
   - *Details:* N/A - Selection logic scales with existing CDI controller capabilities
 
 - [ ] **Security Testing** — Verifies security requirements, RBAC, authentication, authorization, and vulnerability scanning
-  - *Details:* no new security requirements 
+  - *Details:* no new security requirements
 
 - [ ] **Usability Testing** — Validates user experience and accessibility requirements
   - *Details:* N/A - Backend storage class selection logic only
 
 - [ ] **Monitoring** — Does the feature require metrics and/or alerts?
-  - *Details:* no new metrics required 
+  - *Details:* no new metrics required
 
 
 **Integration & Compatibility**
@@ -349,52 +341,52 @@ The following conditions must be met before testing can begin:
 <!-- Document specific risks for this feature. If a risk category is not applicable, mark as "N/A" with
 justification in mitigation strategy. -->
 
-  **Timeline/Schedule**                       
-                                              
+  **Timeline/Schedule**
+
+  - **Risk:** N/A
+    - **Mitigation:** Standard test timeline is sufficient for planned test scenarios. Feature scope is narrow with straightforward test cases.
+    - *Estimated impact on schedule:* None
+    - *Sign-off:* Kate Shvaika/2026-05-05
+
+  **Test Coverage**
+
   - **Risk:** N/A
-    - **Mitigation:** Standard test timeline is sufficient for planned test scenarios. Feature scope is narrow with straightforward test cases.                                                                      
-    - *Estimated impact on schedule:* None                                                                                                                                                                          
-    - *Sign-off:* Kate Shvaika/2026-05-05                                                                                                                                                                                 
-                                                                                                                                                                                                                    
-  **Test Coverage**                                                                                                                                                                                                 
-   
-  - **Risk:** N/A                                                                                                                                                                   
     - **Mitigation:** All acceptance criteria are covered by planned test scenarios.
-    - *Areas with reduced coverage:* None                                                                                                                                                                           
-    - *Sign-off:* Kate Shvaika/2026-05-05                         
-                                              
-  **Test Environment**                                                                                                                                                                                              
-   
-  - **Risk:** N/A                                                                                                                                      
+    - *Areas with reduced coverage:* None
+    - *Sign-off:* Kate Shvaika/2026-05-05
+
+  **Test Environment**
+
+  - **Risk:** N/A
     - **Mitigation:** Standard test environment with multiple storage classes is sufficient for testing this feature
-    - *Missing resources or infrastructure:* None                                                                                                                                                                   
-    - *Sign-off:* Kate Shvaika/2026-05-05                         
-                                              
-  **Untestable Aspects**                                                                                                                                                                                            
-   
-  - **Risk:** N/A                                                                                                            
+    - *Missing resources or infrastructure:* None
+    - *Sign-off:* Kate Shvaika/2026-05-05
+
+  **Untestable Aspects**
+
+  - **Risk:** N/A
     - **Mitigation:** All scenarios can be reproduced in test environment
-    - *Alternative validation approach:* None                                     
-    - *Sign-off:* Kate Shvaika/2026-05-05                                                                                                                                                                                
-                                          
-  **Resource Constraints**                                                                                                                                                                                          
-                                                                                                                                                                                                                    
-  - **Risk:** N/A                                                                                                                                               
-    - **Mitigation:** Current QE team capacity is sufficient for planned test execution                                                                                                                             
-    - *Current capacity gaps:* None                         
-    - *Sign-off:* Kate Shvaika/2026-05-05                                                                                                                                                                               
-   
-  **Dependencies**                                                                                                                                                                                                  
-                                                            
+    - *Alternative validation approach:* None
+    - *Sign-off:* Kate Shvaika/2026-05-05
+
+  **Resource Constraints**
+
   - **Risk:** N/A
-    - **Mitigation:** No external dependencies.                                                                                       
+    - **Mitigation:** Current QE team capacity is sufficient for planned test execution
+    - *Current capacity gaps:* None
+    - *Sign-off:* Kate Shvaika/2026-05-05
+
+  **Dependencies**
+
+  - **Risk:** N/A
+    - **Mitigation:** No external dependencies.
     - *Dependent teams or components:* Documentation team for behavior change documentation (non-blocking)
-    - *Sign-off:* Kate Shvaika/2026-05-05                                                                                                                                                                               
-                                                            
-  **Other**                                                                                                                                                                                                         
-   
-  - **Risk:** N/A                                                                                                                                                                      
-    - **Mitigation:** No additional mitigation required     
+    - *Sign-off:* Kate Shvaika/2026-05-05
+
+  **Other**
+
+  - **Risk:** N/A
+    - **Mitigation:** No additional mitigation required
     - *Sign-off:* Kate Shvaika/2026-05-05
 
 ---