Reality Correlation Engine

What the Ticket Doesn't Know

A ticket is a moment of maximum ignorance.

When a user submits a ticket — "my email is not working" — they are describing a symptom they can see from where they sit. The L1 technician who picks it up is working with the same limited view, under time pressure, selecting from a dropdown with 200+ category options. They pick the category that best matches what the user described. They assign it to a resolver group that seems right. They set a priority that reflects the user's urgency.

Then the investigation begins, root cause emerges, the fix is applied, and the ticket is closed. The resolution field gets filled in with "resolved" or "fixed" or "applied workaround." The category field — set at the moment of maximum ignorance — stays exactly as it was.

This is how enterprise IT generates its operational dataset. Millions of tickets, each captured at the beginning of a problem, rarely updated with what was learned at the end.

Every AI product in IT operations learns from this dataset. They ingest the wrong categories, the empty resolutions, the ungrouped related incidents, the gamed priority fields. They train on contaminated data and produce confident answers to wrong questions.

The Reality Correlation Engine exists to fix this. Not by analyzing ticket text more cleverly — that approach has a hard ceiling. But by doing something no other product does: cross-referencing every ticket against what was actually happening in the infrastructure at the time.

The Six Layers of Broken Ticket Data

When I began designing the RCE, I needed to understand not just that ticket data was unreliable, but how it was unreliable — specifically enough to design targeted fixes for each failure mode.

Wrong Categorization at Source

Gartner reports 20–40% miscategorization rates for L1 triage in large enterprises. In environments with complex category trees — 500+ nodes — rates exceed 45%. The user says "my email is slow." The technician categorizes it as "Email — Outlook — Performance." The actual cause is a DNS resolution failure affecting the mail server. The category is wrong. The CI assignment is wrong. The resolver group routing is wrong.

This isn't a training problem. The technician is doing exactly what they can do with the information available at ticket creation: matching user symptom to the closest category. The diagnosis only emerges during investigation. Nobody goes back to fix the category once the ticket is resolved.

Empty Resolution Data

50–60% of resolution fields in enterprise ITSM systems contain "resolved," "fixed," "closed per user," or something equally meaningless. The structural reason: by the time a technician resolves an issue, documenting what they did has zero immediate value to them. The incentive is to close the ticket, meet the SLA, and move to the next one. The resolution field exists for the benefit of some unknown future consumer — AI training, knowledge base, trend analysis — not for the person filling it in.

No Correlation Across Related Tickets

A core switch flapping for 90 seconds generates 15 separate tickets from 15 different users. Email is down. VPN is timing out. The CRM is unreachable. An application is throwing errors. Each ticket is logged independently, categorized differently, assigned to a different group, and resolved separately. There is no parent-child linking. No shared event identifier. No correlation.

An AI product sees 15 independent problems. The actual answer is: one infrastructure event, 15 symptoms, one fix.

Duplicate Inflation

10–15% of enterprise tickets are duplicates. The user calls the helpdesk, then submits a portal request, then sends an email. The monitoring system auto-creates a ticket and a technician manually creates another. Each duplicate inflates the apparent frequency of the problem type — making AI models overestimate how common certain issues are, waste resolver time on triage, and create conflicting resolution records for the same event.

Priority Inflation

Users learn that P3 tickets sit in queue for days. They escalate to P1/P2 to get faster response. Technicians learn that users complain less when priority is higher. Over time, 60–70% of P1/P2 tickets in large enterprises are actually P3/P4 severity based on actual business impact. The priority field stops meaning anything. Any AI trying to predict which incidents need immediate attention is working with systematically dishonest data.

Taxonomy Drift

Category structures evolve. Services are added, teams reorganize, technology platforms change. The ServiceNow category tree updates — but historical tickets retain their old categories. A trend analysis asking "are collaboration issues increasing?" looks at three years of tickets where the same problem was categorized as "Email — BlackBerry Support" in 2021, "Office 365 — Outlook" in 2022, and "M365 — Exchange Online" in 2023. The data looks like three different problem types. They're the same problem with three different labels.

Why Every Existing Solution Hits the Same Ceiling

The market for ITSM AI is large and growing. ServiceNow Predictive Intelligence, Moveworks, Aisera, virtual agents from every major vendor — they all work on ticket data quality in some form. None of them solve the core problem.

The shared failure: they treat ticket intelligence as a text processing problem.

ServiceNow Predictive Intelligence trains machine learning models on historical ticket data to auto-categorize incoming tickets. It achieves 70–80% accuracy in well-trained instances. The catch: it trains on contaminated historical data — the miscategorized tickets we just described. The model learns to replicate existing miscategorizations with high confidence. If 30% of DNS issues were historically categorized as "Application," the model learns that pattern and perpetuates it. It is learning fiction with high precision.

Moveworks and Aisera apply NLP to interpret user requests and suggest resolutions. They can categorize "my email is slow" as an email issue. They cannot determine that the actual cause is a DNS failure — because they have no visibility into the infrastructure. Their resolution suggestions come from the same historical ticket text, the same empty resolution fields, the same contaminated training data.

Text-based approaches hit a structural ceiling:

• The text is incomplete. User descriptions reflect symptoms, not root causes.
• The training data is contaminated. Models learn miscategorization patterns.
• Resolution data is absent. You cannot learn resolution patterns from fields that say "resolved."
• Correlation requires topology. Text similarity cannot identify that 15 different symptoms trace to one switch flap.

The ceiling is not a product quality limitation — it's an information access limitation. Without knowing what was happening in the infrastructure when the ticket was created, any system is guessing.

The Core Insight: Infrastructure as Ground Truth

The Reality Correlation Engine takes a different approach from the ground up.

The RCE is deployed on-premises or in the customer's cloud environment, with MCP (Model Context Protocol) connections to every system that knows what's actually happening: SolarWinds (server health, CPU, memory, disk utilization, alert history), Cisco DNAC (network topology, link status, packet loss, device health), Azure Monitor and AWS CloudWatch (resource status, deployment events, scaling events), change management systems, DNS management, and the clean CMDB built by the CMDB Intelligence Engine.

At any given moment, the RCE knows what is healthy, what is degraded, what changed recently, what topology connects which assets, and which tickets are open.

This transforms ticket quality from a text analysis challenge into a reality verification exercise:

A ticket says "email is slow." The RCE checks: what was happening in the infrastructure when this ticket was created? The DNS server for the mail relay had elevated response times starting 8 minutes before ticket creation — confirmed by SolarWinds telemetry. The category should be Network, not Email. The CI is the DNS server, not the user's laptop. The resolution, when it arrives, should involve the DNS configuration — not Outlook settings.

The RCE doesn't guess at this. It verifies it.

Eleven Engines, Three Tiers

The RCE architecture is organized into three functional tiers, where each tier depends on the outputs of the tier before it. The sequence is not arbitrary — it reflects the dependency chain of what information each engine needs.

Tier 1 — Foundation

Engine 1: Event-Ticket Mapper

This runs first, before any other engine, and everything downstream depends on it.

The engine continuously maintains a live Event Timeline — a chronological record of everything happening across the infrastructure. When a ticket arrives, it traces the affected CI through the CMDB topology to identify all upstream dependencies: the switches, routers, load balancers, storage arrays, DNS servers, and cloud resources the affected system relies on. It then queries the Event Timeline for any alerts or state changes on those CIs within a configurable window (default: 60 minutes before ticket creation to 30 minutes after).

Events are scored by relevance: how topologically close to the affected CI, how temporally close to the ticket creation, how severe the event, how well the event type matches the reported symptom. The highest-scoring events attach to the ticket with confidence scores and evidence chains.

Without this engine, every other engine falls back to text-only analysis. This is why it runs first.

Tier 2 — Core Enrichment

Four engines run in parallel after the Event-Ticket Mapper completes, each addressing a distinct quality failure.

Engine 2: Intelligent Categorization Engine

In real-time mode, this engine checks correlated infrastructure events against the technician's selected category. When monitoring shows a network event but the ticket is categorized as "Hardware — Laptop," the engine generates a suggestion with evidence — it doesn't force a correction while the ticket is open, because the technician may know something the monitoring data doesn't.

In retrospective mode, running on closed tickets, the engine has full context: the original description, all work notes, the resolution, the CI that was actually worked on, and the complete infrastructure event correlation. With this complete picture, corrections are made with high confidence, and the original fields are preserved alongside the enriched ones.

Beyond individual corrections, the engine identifies systemic patterns: which technicians consistently miscategorize which problem types (training opportunities), which category dropdowns are trapping users (UX problems), which time periods show accuracy degradation (staffing or workload patterns).

Engine 3: Resolution Reconstruction Engine

This is the engine I found most technically satisfying to design, because it solves a problem everyone accepts as unsolvable.

The resolution field is empty. The information about what was done exists in the infrastructure itself — in the configuration changes that were made, the services that were restarted, the DNS records that were updated, the patches that were applied. The RCE reads the infrastructure timeline between ticket open and ticket close and reconstructs what happened.

Not from guesswork — from evidence. If the DNS configuration for the mail relay was modified at 2:47 PM and the email latency ticket was opened at 2:31 PM and closed at 3:15 PM, the reconstruction produces: "DNS configuration updated on [server name] at 2:47 PM — modification to [record type]. Change verified effective by 3:08 PM based on monitoring data showing latency returning to baseline."

Over thousands of tickets, this builds something that didn't exist before: a verified knowledge base of resolution patterns, organized by problem type and infrastructure environment. This is what AI resolution systems need — not the contaminated guess-work in existing resolution fields, but verified outcomes tied to specific infrastructure actions.

Engine 4: Incident Correlation Engine

When a single infrastructure event generates 15 tickets, those tickets need to be recognized as one incident with 15 symptoms — not 15 independent problems.

The engine uses three weighted signals. Infrastructure topology carries the most weight: if multiple tickets reference CIs that share an upstream dependency, and that dependency has an active event in the Event Timeline, correlation is infrastructure-verified. Temporal clustering carries medium weight: tickets arriving within a narrow window are candidates, but time alone isn't proof. Text similarity carries the least weight — it's what every competitor relies on exclusively, and it's the weakest signal because different symptoms can come from the same cause, and similar symptoms can come from different causes.

The output transforms the view from noise to signal: one unified incident record with 15 correlated manifestations, a shared causal event, and one resolution path — instead of 15 parallel investigations discovering the same answer.

Engine 10: Change-Incident Correlator

Changes cause most incidents in enterprise IT. A patch deploys at 2:00 PM. Incidents start at 2:15 PM. A technician investigating the incidents starts from scratch, unaware that a change touched the affected system an hour earlier.

The engine maintains a continuous log of all change records and their affected CIs. When incidents arrive, it checks CI overlap and timeline proximity. When a change-incident correlation is detected, the evidence attaches to the ticket automatically: which change, which CI, what was modified, the precise timeline.

Over time, this builds a change risk profile: which types of changes cause the most incidents, which time windows are highest risk, which teams' changes have the highest post-implementation incident rate. This feeds back into change governance — not as blame, but as data for risk-based scheduling and approval.

Tier 3 — Advanced Intelligence

Three engines run after Tier 2 enrichment is complete, generating intelligence that doesn't exist anywhere else.

Engine 5: Duplicate Detection Engine

The distinction between correlated and duplicate is precise. Fifteen tickets about the same core switch failure affecting fifteen different users — those are correlated (Engine 4). One ticket submitted by the same user through the phone, the portal, and email — those are duplicates (Engine 5).

Infrastructure-based duplicate detection is more accurate than text matching because users describe the same incident differently. Four tickets with different wording about a CRM outage get identified as duplicates when all four correlate to the same infrastructure event, originated within minutes of each other, and reference the same affected service.

Engine 6: Impact-Based Priority Scorer

The engine calculates an evidence-based impact score from infrastructure data: how many CIs are affected, which downstream business services depend on those CIs, how many users are in scope, whether the service is fully down or degraded, whether cascade risk exists in the dependency topology, and business context (business hours, active SLA windows).

The score doesn't replace the human-assigned priority — it runs alongside it in a parallel field. The gap between human-assigned and evidence-based priority is itself a metric: which teams inflate priority most consistently, which categories trigger priority gaming, whether the gap is narrowing over time.

Engine 7: Proactive Incident Intelligence

This is the engine that flips the model from reactive to proactive.

The RCE has continuous visibility into infrastructure degradation: disk filling, memory trending upward, CPU spikes increasing in duration, network error rates climbing. The Resolution Reconstruction Engine (Engine 3) has built a verified knowledge base linking these patterns to the incidents they historically preceded.

When the RCE detects a degradation pattern that matches a historical precursor, it generates a proactive alert — before any user files a ticket. The alert arrives pre-populated: correct category, correct CI, predicted impact, historical resolution path, recommended action.

This is only possible because the system has continuous infrastructure visibility and a verified historical knowledge base. No other product in the market delivers proactive incident intelligence at this fidelity.

Engine 8: Resolution Verification Engine

Tickets get closed prematurely. Technicians close tickets to meet SLA targets. Users confirm "it's working now" when a symptom temporarily subsides. The underlying issue persists. The ticket enters the historical dataset as "resolved" — and AI learns from a false resolution record.

When a ticket is closed, Engine 8 checks infrastructure reality: is the correlated SolarWinds alert cleared, is the affected CI performing within normal parameters, is the service showing healthy? If the infrastructure doesn't confirm resolution, the ticket is flagged — and the historical record notes that the closure was premature.

Engine 9: Recurring Pattern Detector

The same server crashes every two weeks. Each time: new ticket, independent investigation, resolved, closed. Nobody recognizes the pattern because each ticket exists in isolation. The organization repeatedly repairs the symptom instead of eliminating the root cause.

Engine 9 analyzes the enriched historical dataset — with corrected categories, verified resolutions, and infrastructure correlation — to identify genuine recurrence versus coincidental clustering. Genuine recurrence means same root cause, same symptoms, regular interval. Coincidental clustering means different root causes that happened to affect the same CI twice in a month.

The output is a recurring problem register with cost quantification: 14 tickets over 6 months, 4.2 engineer-hours per incident, $3,700 in recurring cost for a root cause fix that requires one change record. The business case for root cause remediation writes itself.

Independent

Engine 11: Taxonomy Normalizer

The simplest engine in the architecture, and the one most frequently overlooked. It maintains a temporal mapping of category changes — every restructuring of the category taxonomy with timestamps and old-to-new mappings. When AI platforms query historical data, categories are automatically normalized to a consistent taxonomy version.

Without this, multi-year trend analysis is unreliable. With it, a query about network incidents over three years returns consistent data regardless of whether the taxonomy was reorganized twice during that period.

The Design Principle That Governs Everything

There is one rule in the RCE that is non-negotiable: user-reported information is never overwritten.

Every field the user filled in — the description, the category, the priority, the work notes — is treated as read-only. The RCE adds enrichment in parallel fields: rce_corrected_category alongside the original category. rce_verified_resolution alongside the original resolution_notes. rce_impact_score alongside the original priority.

The original fields stay intact.

This matters for reasons beyond compliance. When an AI platform consumes enriched ticket data, it receives both layers: the user's description (valuable for understanding how users describe problems, for natural language processing, for training models that bridge user language and technical reality) and the infrastructure truth (accurate for pattern analysis, root cause identification, and resolution recommendations).

The mapping between "user said email is slow" and "actual cause was DNS failure" is itself a training signal — one that no existing product can generate because it requires knowing what the infrastructure was actually doing.

When the enrichment is wrong — which will happen — the original data serves as the fallback. The audit trail is preserved. The technician who disagrees with a correction can see the evidence, reject it, and teach the system. Every rejection improves future accuracy.

The Dependency That Makes It Work

The RCE requires one thing that doesn't exist in most enterprise environments: a clean CMDB.

The Event-Ticket Mapper traces affected CIs through CMDB topology to find upstream dependencies. The Incident Correlation Engine uses CMDB service maps to cluster related tickets. The Impact-Based Priority Scorer uses CMDB user-to-service mappings to calculate blast radius. The Proactive Incident Intelligence engine uses CMDB dependency graphs to predict cascade risk.

If the CMDB topology is wrong — stale CIs, missing relationships, undiscovered shadow assets — all of these engines produce findings that seem confident but are built on incorrect infrastructure maps. The same garbage-in problem, one layer removed.

This is why the CMDB Intelligence Engine must run before the RCE. Not as a product bundling decision — as an architectural dependency. The RCE is the second half of the data quality stack. The CMDB IE is the first.

Clean CMDB (CMDB Intelligence Engine) → Clean Tickets (Reality Correlation Engine) → Trustworthy AI (CoResolve)

Together they form the only end-to-end data quality pipeline in the IT operations market. Each product is valuable independently. Together, they address both halves of the reason enterprise AI fails: the infrastructure map is wrong, and the operational data is wrong. Fix both, and AI can finally operate on a foundation that warrants the trust enterprises are being asked to place in it.

What This Taught Me

Text analysis has a structural ceiling, not a quality ceiling.

Every competitor making ITSM AI work harder on ticket text isn't missing better algorithms — they're missing a different data source. The ceiling isn't reachable through better NLP. It's reachable only by connecting to the systems that know what actually happened: the monitoring platforms, the network controllers, the cloud consoles, the change management logs. This is an access problem, not an intelligence problem.

The most valuable knowledge is the knowledge that doesn't exist yet.

The verified resolution knowledge base that Engine 3 builds didn't exist anywhere before the RCE created it. Not in tickets — those fields were empty. Not in documentation — nobody wrote it. Not in any AI training dataset. The RCE generates net new knowledge from the gap between what tickets record and what infrastructure shows actually happened. Building that kind of foundational knowledge asset is a different category of product work than building features.

The best products have a sequencing opinion.

The RCE's dependency on the CMDB Intelligence Engine wasn't a constraint I designed around — it was an insight I leaned into. Designing two products with a clear deployment sequence means the second product inherits the quality guarantees of the first. It also creates a natural land-and-expand motion: the CMDB IE creates the conditions for the RCE, the RCE creates the conditions for CoResolve. The products are better together in a way that's architecturally honest, not just marketed.

Proactive intelligence is a different product category from reactive intelligence.

Engine 7 — the Proactive Incident Intelligence engine — isn't a better version of what existing products do. It's a categorically different capability: detecting infrastructure degradation before users experience it, generating alerts before tickets exist, pre-staging resolution paths before anyone calls the helpdesk. Building that required having both continuous infrastructure visibility and a verified historical knowledge base. Neither alone is sufficient. This is why the engine is in Tier 3 — it depends on everything else being in place first.

Conceived, architected, and owned as part of the TechOps AI Orchestration Platform at FuturePath.AI. The Reality Correlation Engine forms the second layer of the data quality foundation, built on top of the clean CMDB delivered by the CMDB Intelligence Engine and feeding enriched ticket data into all nine products in the TechOps portfolio.