Skip to main content

DLR Processor — AI Integration

Status: populated Owner: Platform Engineering Last updated: 2026-04-18

1. Current AI Usage​

The DLR Processor does not use AI/ML models in its primary processing pipeline. All status normalisation is deterministic rule-based mapping.

2. Planned / Future AI Enhancements​

2.1 Anomaly Detection for Orphan Spikes​

Trigger: A sudden rise in dlr.orphaned_receipts inserts may indicate an operator routing misconfiguration or a platform message-ID mapping bug. Approach: Time-series anomaly detection (streaming Z-score or Prophet forecast) on dlr_orphan_rate metric. Alert threshold at > 3σ deviation over a 5-minute window. Owner: SRE / ML Platform team (future epic EP-DLR-05).

2.2 Smart Reconciliation Scoring​

Trigger: Orphaned receipts that cannot be immediately correlated may be resolvable through fuzzy matching of destAddr + deliveredAt + operatorId against recently-sent messages. Approach: Lightweight embedding similarity (sentence-transformers on carrier metadata fields) to score candidate messageId matches. Score threshold ≥ 0.92 triggers auto-reconciliation; below threshold queues for human review. Owner: Platform Engineering (post-MVP).

2.3 Error Code Classification​

Trigger: Carrier error codes (errorCode field) are inconsistently formatted across operators. Automatic classification into buckets (HANDSET_UNREACHABLE, NUMBER_INVALID, NETWORK_CONGESTION, etc.) would improve analytics. Approach: Fine-tuned text classifier on operator error code strings. Training data: historical annotated records from dlr.delivery_receipts.

3. Integration Constraints​

  • Any AI/ML inference in the hot path must complete within 50 ms (p99) to preserve DLR processing latency SLO.
  • Model inference calls must not be required for correctness — they may enhance observability or reconciliation but must degrade gracefully.
  • No PII (phone numbers, message content) may be sent to external AI APIs. All inference must use internal models or locally-deployed endpoints.