# DD-CATEGORIZATION-001: Gateway vs Signal Processing Categorization Split Assessment

**Date**: November 11, 2025
**Status**: ✅ **APPROVED**
**Confidence**: 92%
**Purpose**: Assess the current categorization split between Gateway and Signal Processing services and provide industry best practice recommendations

**Decision**: CONSOLIDATE all categorization (environment classification and priority assignment) into Signal Processing Service. Gateway will set placeholder values (`environment: "pending"`, `priority: "pending"`) and Signal Processing will perform all categorization after K8s context enrichment.

---

## Executive Summary

**Current State**: Categorization is split between two services:
- **Gateway Service**: Environment classification (BR-GATEWAY-051 to 053) + Priority assignment (BR-GATEWAY-007, BR-GATEWAY-013-014)
- **Signal Processing Service**: Environment classification (BR-SP-051 to 053) with business-aware enrichment

**Assessment**: **CONSOLIDATE** all categorization into Signal Processing Service
**Confidence**: 92%
**Rationale**: Industry best practices favor enrichment-time categorization with full context availability

---

## Current Architecture Analysis

### Gateway Service Categorization (Fast Path - <50ms)

**Environment Classification** (BR-GATEWAY-051 to 053):
```go
// Priority order (first match wins):
func classifyEnvironment(namespace string, alert NormalizedSignal) string {
    // 1. Check namespace labels (K8s API with 5-minute cache)
    if env := getNamespaceLabelEnv(namespace); env != "" {
        return env // e.g., "prod"
    }

    // 2. Check ConfigMap override
    if env := configMapEnv[namespace]; env != "" {
        return env // e.g., "staging"
    }

    // 3. Check alert labels (Prometheus alerts only)
    if env := alert.Labels["environment"]; env != "" {
        return env
    }

    // 4. Default fallback
    return "unknown"
}
```

**Priority Assignment** (BR-GATEWAY-007, BR-GATEWAY-013-014):
```rego
package kubernaut.priority

# Example: Critical production payment service → P0
priority = "P0" {
    input.severity == "critical"
    input.environment == "prod"
    input.namespace in ["payment-service", "auth-service", "checkout"]
}

# Fallback: Severity + Environment matrix
priority = "P1" {
    input.severity == "critical"
    input.environment in ["staging", "prod"]
}
```

**Fallback Matrix** (if Rego fails):
| Severity | Environment | Priority |
|----------|-------------|----------|
| critical | production* | P0       |
| critical | staging/production | P1       |
| warning  | production* | P1       |
| warning  | staging     | P2       |
| info     | any         | P3       |
| *        | unknown     | P2       |

**Characteristics**:
- ✅ **Fast**: 2-3ms environment classification, 5-8ms Rego evaluation
- ✅ **Simple**: String lookup and pattern matching
- ✅ **Stateless**: No external dependencies (except cached K8s API)
- ❌ **Limited Context**: Only alert payload + namespace labels
- ❌ **No Business Context**: Cannot consider service criticality, SLA requirements
- ❌ **Duplicate Logic**: Environment classification repeated in Signal Processing

---

### Label and Annotation Data Flow

**Key Clarification**: Gateway passes through ALL source labels/annotations but does NOT query K8s API for resource labels.

| Data Type | Gateway Responsibility | SignalProcessing Responsibility |
|-----------|----------------------|--------------------------------|
| **Alert Labels** (`alert.Labels`) | ✅ Passes through → `Spec.SignalLabels` | Reads from CRD |
| **Common Labels** (`webhook.CommonLabels`) | ✅ Merged into `SignalLabels` | Reads from CRD |
| **Alert Annotations** (`alert.Annotations`) | ✅ Passes through → `Spec.SignalAnnotations` | Reads from CRD |
| **Common Annotations** (`webhook.CommonAnnotations`) | ✅ Merged into `SignalAnnotations` | Reads from CRD |
| **Namespace Name** | ✅ Extracted → `Spec.Namespace` | Reads from CRD |
| **Pod/Resource Name** | ✅ In `SignalLabels["pod"]` | Reads from CRD |
| **Namespace Labels** | ❌ NOT queried | ✅ Queries K8s API |
| **Pod Labels** | ❌ NOT queried | ✅ Queries K8s API |
| **Node Labels** | ❌ NOT queried | ✅ Queries K8s API |
| **Deployment Labels** | ❌ NOT queried | ✅ Queries K8s API |

**Rationale**:
- Gateway targets <50ms response time; K8s API queries would add 10-50ms latency per query
- SignalProcessing already performs K8s context enrichment (~2s) where label queries are appropriate
- Avoids duplicate K8s API calls across services
- Labels/annotations from alert source are sufficient for Gateway's deduplication and storm detection

**What Gateway Provides in RemediationRequest CRD**:
```yaml
spec:
  # ALL alert labels passed through (truncated to 63 chars per K8s limits)
  signalLabels:
    alertname: "HighMemoryUsage"
    namespace: "prod-payment"
    pod: "payment-api-789"
    severity: "critical"
    cluster: "prod-us-west"
    # ... ALL labels from alert + commonLabels

  # ALL alert annotations passed through
  signalAnnotations:
    summary: "Container memory usage > 90%"
    description: "Pod payment-api-789 memory at 94%"
    runbook_url: "https://..."
    kubernaut.io/team: "payments"  # Custom annotations preserved
    # ... ALL annotations from alert + commonAnnotations
```

**What SignalProcessing Must Query**:
```go
// SignalProcessing enrichment queries K8s API for resource labels
namespace, _ := k8sClient.Get(ctx, nsName, &corev1.Namespace{})
nsLabels := namespace.Labels  // e.g., {"environment": "prod", "team": "platform"}

pod, _ := k8sClient.Get(ctx, podName, namespace, &corev1.Pod{})
podLabels := pod.Labels  // e.g., {"app": "payment-api", "version": "v2.1"}
```

**Implementation References**:
- `pkg/gateway/adapters/prometheus_adapter.go`: `MergeLabels()`, `MergeAnnotations()`
- `pkg/gateway/processing/crd_creator.go`: `SignalLabels`, `SignalAnnotations` field population
- `api/remediation/v1alpha1/remediationrequest_types.go`: CRD spec definition

---

### Signal Processing Service Categorization (Enrichment Path - ~3s)

**Environment Classification** (BR-SP-051 to 053):
```yaml
# After K8s context enrichment completes (~2s)
environmentClassification:
  environment: "production"           # Tier classification
  confidence: 0.95                    # Classification certainty (0.0-1.0)
  businessPriority: "P0"              # Business priority mapping
  slaRequirement: "5m"                # Service-level agreement time
  source: "namespace-labels"          # Classification source
```

**Characteristics**:
- ✅ **Rich Context**: Has full K8s context (~8KB) after enrichment
- ✅ **Business-Aware**: Includes confidence, priority, SLA metadata
- ✅ **Sophisticated**: Can analyze deployment criticality, resource quotas, node health
- ✅ **AI-Ready**: Provides structured data for AI analysis decisions
- ❌ **Slower**: 1-2 seconds (but acceptable for enrichment phase)
- ❌ **Duplicate Logic**: Repeats Gateway's environment classification

---

## Industry Best Practices Analysis

### 1. **Single Responsibility Principle** (92% Confidence)

**Best Practice**: Each service should have ONE clear responsibility
- **Gateway**: Alert ingestion, normalization, deduplication, storm detection
- **Signal Processing**: Alert enrichment, classification, context integration

**Current Violation**: Both services perform environment classification

**Recommendation**: ✅ **CONSOLIDATE** into Signal Processing
- Gateway focuses on fast ingestion and triage
- Signal Processing performs ALL categorization with full context

**Industry Examples**:
- **Datadog**: Ingestion service (fast) → Enrichment service (categorization)
- **PagerDuty**: Event API (ingestion) → Event Orchestration (enrichment + routing)
- **Splunk**: HTTP Event Collector (ingestion) → Indexers (enrichment + classification)

---

### 2. **Context-Driven Categorization** (95% Confidence)

**Best Practice**: Categorization should happen when maximum context is available

**Current State**:
- **Gateway**: Categorizes with minimal context (alert + namespace labels only)
- **Signal Processing**: Has full K8s context (~8KB) after enrichment

**Problem with Gateway Categorization**:
```yaml
# Gateway sees:
namespace: "payment-service"
severity: "critical"
labels:
  environment: "prod"

# But CANNOT see:
- Deployment criticality (3 replicas vs 1 replica)
- Service SLA requirements (5min vs 30min)
- Resource quotas (near limit vs plenty of capacity)
- Node health (degraded vs healthy)
- Historical failure patterns (frequent vs rare)
```

**Recommendation**: ✅ **MOVE** to Signal Processing
- Signal Processing has full context for sophisticated categorization
- Can use ML-based classification with confidence scores
- Can consider business criticality, not just namespace patterns

**Industry Examples**:
- **Google Cloud Operations**: Enrichment-time severity adjustment based on resource state
- **AWS CloudWatch**: Alarm evaluation after metric enrichment
- **Elastic Observability**: Alert severity determined after full context aggregation

---

### 3. **Fail-Fast vs Fail-Safe** (90% Confidence)

**Best Practice**: Ingestion should be fail-fast; enrichment should be fail-safe

**Current State**:
- **Gateway**: Fail-fast (reject invalid alerts, <50ms response)
- **Signal Processing**: Fail-safe (graceful degradation, retry logic)

**Problem**: Gateway categorization creates fail-fast dependency on K8s API
```go
// Gateway must query K8s API for namespace labels
ns := &corev1.Namespace{}
if err := c.k8sClient.Get(ctx, types.NamespacedName{Name: namespace}, ns); err != nil {
    // ❌ FAIL: Cannot classify environment
    // ❌ IMPACT: Alert rejected or assigned "unknown" environment
    return "unknown"
}
```

**Recommendation**: ✅ **MOVE** to Signal Processing
- Gateway can accept ALL valid alerts without categorization
- Signal Processing performs categorization with retry logic and graceful degradation
- If categorization fails, Signal Processing can still proceed with "unknown" environment

**Industry Examples**:
- **Prometheus Alertmanager**: Accepts all alerts, enrichment happens in routing stage
- **Grafana OnCall**: Ingestion always succeeds, categorization in escalation engine
- **Opsgenie**: Alert API accepts all, enrichment in notification pipeline

---

### 4. **Rego Policy Placement** (88% Confidence)

**Best Practice**: Policy evaluation should happen where decisions have maximum impact

**Current State**:
- **Gateway**: Rego policies for priority assignment (5-8ms evaluation)
- **Signal Processing**: No Rego policies (uses heuristics)

**Analysis**:
```rego
# Gateway Rego policy (limited context):
priority = "P0" {
    input.severity == "critical"
    input.environment == "prod"
    input.namespace in ["payment-service", "auth-service"]
}

# Signal Processing COULD use (rich context):
priority = "P0" {
    input.severity == "critical"
    input.environment == "prod"
    input.deployment.replicas < input.deployment.minReplicas  # ✅ K8s context
    input.businessContext.sla == "5m"                         # ✅ Business context
    input.historicalFailures > 3                              # ✅ Historical context
}
```

**Recommendation**: ⚠️ **HYBRID APPROACH**
- **Gateway**: Keep Rego for FAST priority assignment (5-8ms)
  - Use for initial triage and routing decisions
  - Simple policies based on alert metadata only
- **Signal Processing**: Add Rego for SOPHISTICATED categorization (1-2s)
  - Use for business-aware priority adjustment
  - Complex policies leveraging full K8s + business context

**Rationale**: Gateway needs fast triage for storm detection and rate limiting; Signal Processing needs sophisticated categorization for AI analysis

**Industry Examples**:
- **Kubernetes Admission Controllers**: Fast webhook (Gateway) + Validating webhook (Enrichment)
- **Istio**: Fast Envoy proxy decisions + Slow Mixer policy evaluation
- **OPA Gatekeeper**: Fast constraint evaluation + Slow audit loop

---

### 5. **Duplicate Logic Anti-Pattern** (94% Confidence)

**Best Practice**: Avoid duplicate categorization logic across services

**Current State**: Environment classification logic is duplicated:
- **Gateway**: `classifyEnvironment()` function (namespace labels → ConfigMap → alert labels → "unknown")
- **Signal Processing**: Same logic repeated with additional business metadata

**Problems**:
1. **Maintenance Burden**: Changes must be synchronized across two services
2. **Consistency Risk**: Gateway and Signal Processing might classify differently
3. **Testing Overhead**: Same logic tested twice in different codebases
4. **Drift Risk**: Over time, implementations diverge

**Recommendation**: ✅ **ELIMINATE DUPLICATION**
- **Option A (Preferred)**: Remove environment classification from Gateway entirely
- **Option B**: Gateway sets `environment: "pending"`, Signal Processing overwrites

**Industry Examples**:
- **Kubernetes**: Admission webhooks don't duplicate scheduler logic
- **Prometheus**: Alertmanager doesn't duplicate scrape logic
- **Grafana**: Alert evaluation doesn't duplicate data source queries

---

## Recommended Architecture

### **CONSOLIDATE** Categorization into Signal Processing Service

```
┌─────────────────────────────────────────────────────────────┐
│ Gateway Service (Fast Path: <50ms)                         │
│                                                              │
│ Responsibilities:                                           │
│ 1. Alert ingestion and normalization                       │
│ 2. Fingerprint-based deduplication (Redis)                 │
│ 3. Storm detection (rate + pattern)                        │
│ 4. RemediationRequest CRD creation                         │
│                                                              │
│ ❌ NO environment classification                            │
│ ❌ NO priority assignment                                   │
│ ❌ NO Rego policy evaluation                                │
│                                                              │
│ CRD Fields:                                                 │
│   environment: "pending"  # Placeholder                     │
│   priority: "pending"     # Placeholder                     │
└─────────────────────────────────────────────────────────────┘
                          │
                          v
┌─────────────────────────────────────────────────────────────┐
│ Signal Processing Service (Enrichment Path: ~3s)           │
│                                                              │
│ Responsibilities:                                           │
│ 1. K8s context enrichment (~2s)                            │
│ 2. Environment classification (BR-SP-051 to 053)           │
│ 3. Priority assignment with Rego policies                  │
│ 4. Business categorization (SLA, criticality)              │
│ 5. Recovery context integration (if recovery attempt)      │
│                                                              │
│ ✅ ALL categorization logic centralized                     │
│ ✅ Rich context available for sophisticated decisions      │
│ ✅ Graceful degradation if K8s API unavailable             │
│                                                              │
│ CRD Fields:                                                 │
│   environment: "production"  # Classified                   │
│   priority: "P0"             # Assigned                     │
│   confidence: 0.95           # Classification confidence    │
│   businessPriority: "P0"     # Business-aware priority      │
│   slaRequirement: "5m"       # SLA metadata                 │
└─────────────────────────────────────────────────────────────┘
```

---

## Migration Strategy

### Phase 1: Signal Processing Enhancement (Week 1)

**Tasks**:
1. Add Rego policy engine to Signal Processing Service
2. Migrate Gateway's Rego policies to Signal Processing
3. Enhance policies with K8s context inputs (replicas, quotas, node health)
4. Add business context inputs (SLA, criticality, historical failures)

**Business Requirements**:
- **NEW BR-SP-070**: Priority assignment using Rego policies with K8s context
- **NEW BR-SP-071**: Priority fallback matrix (severity + environment + business)
- **NEW BR-SP-072**: Rego policy hot-reload from ConfigMap

**Confidence**: 90%

---

### Phase 2: Gateway Simplification (Week 2)

**Tasks**:
1. Remove environment classification from Gateway Service
2. Remove priority assignment from Gateway Service
3. Remove Rego policy engine from Gateway Service
4. Set placeholder values in RemediationRequest CRD

**Changes**:
```go
// Gateway creates CRD with placeholders:
spec:
  alertFingerprint: "a1b2c3d4..."
  alertName: "HighMemoryUsage"
  severity: "critical"
  environment: "pending"  // ← Changed from classified value
  priority: "pending"     // ← Changed from assigned value
  namespace: "prod-payment-service"
  // ... rest of fields
```

**Deprecations**:
- **DEPRECATE BR-GATEWAY-051 to 053**: Environment classification
- **DEPRECATE BR-GATEWAY-007**: Priority assignment (Rego)
- **DEPRECATE BR-GATEWAY-013 to 014**: Priority fallback matrix

**Confidence**: 95%

---

### Phase 3: Signal Processing Ownership (Week 3)

**Tasks**:
1. Signal Processing reads `environment: "pending"` and `priority: "pending"`
2. Signal Processing performs classification after K8s enrichment
3. Signal Processing updates RemediationRequest CRD with classified values
4. Signal Processing emits metrics for classification confidence

**CRD Update Pattern**:
```go
// Signal Processing updates parent CRD:
remediationRequest.Spec.Environment = "production"
remediationRequest.Spec.Priority = "P0"
remediationRequest.Status.EnvironmentClassification = EnvironmentClassification{
    Environment:      "production",
    Confidence:       0.95,
    BusinessPriority: "P0",
    SLARequirement:   "5m",
    Source:           "namespace-labels-with-k8s-context",
}
```

**Confidence**: 88%

---

## Risk Assessment

### **Risk 1: Gateway Performance Impact** (LOW - 5%)

**Concern**: Removing categorization from Gateway might slow down ingestion

**Mitigation**:
- Gateway categorization only takes 2-3ms (environment) + 5-8ms (Rego) = ~10ms
- Removing this saves 10ms per alert
- Gateway response time improves from 50ms → 40ms
- **Result**: PERFORMANCE IMPROVEMENT, not degradation

**Confidence**: 95%

---

### **Risk 2: Downstream Dependency on Environment/Priority** (MEDIUM - 15%)

**Concern**: Downstream services might depend on Gateway-assigned environment/priority

**Analysis**:
```bash
# Search for dependencies:
grep -r "remediationRequest.Spec.Environment" pkg/
grep -r "remediationRequest.Spec.Priority" pkg/
```

**Mitigation**:
- Audit all services reading RemediationRequest CRD
- Ensure they wait for Signal Processing to complete before reading environment/priority
- Add validation: reject CRDs with `environment: "pending"` or `priority: "pending"`

**Confidence**: 85%

---

### **Risk 3: Signal Processing Failure** (MEDIUM - 20%)

**Concern**: If Signal Processing fails, alerts have no environment/priority

**Mitigation**:
- Signal Processing has graceful degradation (BR-SP-052)
- If K8s API unavailable, use Gateway's simple logic as fallback
- If Rego fails, use fallback matrix
- Worst case: `environment: "unknown"`, `priority: "P2"` (safe defaults)

**Confidence**: 80%

---

### **Risk 4: Migration Complexity** (LOW - 10%)

**Concern**: Three-phase migration might introduce bugs

**Mitigation**:
- Phase 1: Additive only (no breaking changes)
- Phase 2: Feature flag for Gateway categorization (gradual rollout)
- Phase 3: Validate Signal Processing categorization matches Gateway's before cutover
- Rollback plan: Re-enable Gateway categorization if Signal Processing fails

**Confidence**: 90%

---

## Industry Best Practice Recommendations (90%+ Confidence)

### 1. **Centralize Categorization in Enrichment Service** (92%)

**Recommendation**: Move ALL categorization to Signal Processing Service

**Rationale**:
- Enrichment service has maximum context availability
- Avoids duplicate logic and maintenance burden
- Enables sophisticated ML-based categorization
- Aligns with industry patterns (Datadog, PagerDuty, Splunk)

**Implementation**:
- Signal Processing owns environment classification (BR-SP-051 to 053)
- Signal Processing owns priority assignment (NEW BR-SP-070 to 072)
- Gateway focuses solely on fast ingestion and triage

---

### 2. **Use Rego Policies for Business-Aware Categorization** (88%)

**Recommendation**: Enhance Signal Processing Rego policies with K8s + business context

**Rationale**:
- Rego policies in Gateway are limited to alert metadata
- Signal Processing can leverage full K8s context (replicas, quotas, node health)
- Signal Processing can leverage business context (SLA, criticality, historical failures)
- Enables dynamic policy updates without code changes

**Implementation**:
```rego
# Signal Processing Rego policy (rich context):
package signalprocessing.priority

priority = "P0" {
    input.severity == "critical"
    input.environment == "production"
    input.kubernetesContext.deployment.replicas < input.kubernetesContext.deployment.minReplicas
    input.businessContext.sla == "5m"
    input.recoveryContext.historicalFailures > 3
}

priority = "P1" {
    input.severity == "critical"
    input.environment == "production"
    input.kubernetesContext.deployment.replicas >= input.kubernetesContext.deployment.minReplicas
}

# Fallback
priority = "P2" {
    true
}
```

---

### 3. **Implement Confidence Scoring for Categorization** (94%)

**Recommendation**: Add confidence scores to all categorization decisions

**Rationale**:
- Confidence scores enable AI analysis to weight categorization reliability
- Low-confidence categorizations can trigger human review
- Confidence degrades gracefully when context is incomplete
- Industry standard (Google Cloud Operations, AWS CloudWatch)

**Implementation**:
```yaml
environmentClassification:
  environment: "production"
  confidence: 0.95  # High confidence (namespace label + K8s context)
  source: "namespace-labels-with-k8s-context"

# vs

environmentClassification:
  environment: "production"
  confidence: 0.60  # Low confidence (pattern matching only)
  source: "namespace-pattern-matching"
```

---

### 4. **Use Multi-Dimensional Categorization** (91%)

**Recommendation**: Categorize signals across multiple dimensions, not just environment + priority

**Rationale**:
- Single-dimensional categorization (environment + priority) is insufficient for complex systems
- Multi-dimensional categorization enables sophisticated routing and escalation
- Industry trend: Datadog (tags), PagerDuty (services + teams), Splunk (fields)

**Implementation**:
```yaml
categorization:
  environment: "production"
  priority: "P0"
  businessUnit: "payments"
  serviceOwner: "platform-team"
  criticality: "mission-critical"
  sla: "5m"
  region: "us-east-1"
  cluster: "prod-us-east-1-k8s"
  costCenter: "engineering-ops"
```

**Benefits**:
- Enables routing by business unit, service owner, region
- Enables cost attribution by cost center
- Enables SLA tracking by criticality tier
- Enables multi-dimensional analytics

---

### 5. **Implement Categorization Audit Trail** (89%)

**Recommendation**: Log all categorization decisions with reasoning

**Rationale**:
- Categorization decisions impact remediation behavior
- Audit trail enables debugging incorrect categorizations
- Compliance requirement for production systems
- Industry standard (PagerDuty incident timeline, Datadog event stream)

**Implementation**:
```yaml
status:
  categorizationAudit:
  - timestamp: "2025-11-11T10:00:00Z"
    decision: "environment=production"
    confidence: 0.95
    reasoning: "namespace label 'environment=prod' found"
    source: "namespace-labels"
  - timestamp: "2025-11-11T10:00:01Z"
    decision: "priority=P0"
    confidence: 0.90
    reasoning: "Rego policy matched: critical + production + payment-service"
    policyName: "production-critical-services"
    source: "rego-policy"
```

---

## Final Recommendation

### **CONSOLIDATE** Categorization into Signal Processing Service

**Confidence**: 92%

**Rationale**:
1. ✅ **Single Responsibility**: Gateway focuses on ingestion, Signal Processing on enrichment + categorization
2. ✅ **Context-Driven**: Categorization happens when maximum context is available
3. ✅ **Fail-Safe**: Signal Processing has graceful degradation, Gateway remains fail-fast
4. ✅ **No Duplication**: Eliminates duplicate environment classification logic
5. ✅ **Sophisticated Policies**: Enables Rego policies with K8s + business context
6. ✅ **Industry Alignment**: Matches patterns from Datadog, PagerDuty, Splunk, Google Cloud

**Migration Timeline**: 3 weeks (low risk, phased rollout)

**Performance Impact**: POSITIVE (Gateway 10ms faster, Signal Processing 1-2s acceptable)

**Business Impact**: HIGH (enables business-aware categorization for AI analysis)

---

## Cross-References

**Related BRs**:
- **Gateway**: BR-GATEWAY-007 (Priority), BR-GATEWAY-051 to 053 (Environment)
- **Signal Processing**: BR-SP-051 to 053 (Environment), NEW BR-SP-070 to 072 (Priority)

**Related ADRs**:
- ADR-001: CRD Microservices Architecture
- ADR-015: Alert-to-Signal Naming Migration

**Related DDs**:
- DD-001: Recovery Context Enrichment
- DD-GATEWAY-002: Integration Test Architecture
- DD-SIGNAL-PROCESSING-001: Service Rename

---

**Status**: ✅ **APPROVED**
**Implementation**: To be implemented when Signal Processing Service development begins
**Next Steps**: Update Gateway BRs (BR-GATEWAY-051 to 053, BR-GATEWAY-007, BR-GATEWAY-013 to 014) to reference Signal Processing ownership
**Author**: AI Assistant (Cursor)
**Date**: November 11, 2025
**Approved By**: User
**Approval Date**: November 11, 2025

