ATLAS AUTOMATED DIAGNOSTICS
Atlas Automated Diagnostics is being developed to correlate network, service and operational evidence so Layer 3 can narrow likely causes, understand impact and decide what should be checked next.
MULTIPLE SIGNALS, ONE INVESTIGATION
A quality signal.
A reliability signal.
A capacity signal.
A timing signal.
CORRELATE → LIKELY CAUSES → WHAT TO CHECK NEXT
Bring relevant evidence together.
Look for relationships between signals.
Reduce the list of likely causes.
Suggest what should be checked next.
PROBLEM BEFORE PRODUCT
“The internet is slow” does not identify the cause. Congestion, packet loss, poor wireless conditions, upstream failure, DNS or authentication problems, customer-device issues, overloaded infrastructure and recent changes can feel similar.
The correct response depends on the evidence. The symptom is where investigation starts — not where diagnosis ends.
EVIDENCE BEFORE ASSUMPTION
Useful evidence may include latency, packet loss, utilisation, availability, link state, wireless health, authentication events, DNS or service health, monitoring alerts, relevant security events, recent changes and customer, site or device context.
Not every source is currently integrated. Diagnostic guidance must remain explicit about what evidence is available and what is missing.
Latency, loss, utilisation and availability.
Link state, events and recent behaviour.
DNS, authentication and upstream health.
Customer, site and supported device relationships.
Correlation looks for relationships without pretending that an indicator is a conclusion.
May suggest congestion.
May suggest a link-quality or infrastructure problem.
May suggest shared infrastructure or an upstream issue.
May suggest a customer-specific service, device or path issue.
These are diagnostic indicators, not guaranteed conclusions.
PLAUSIBLE IS NOT CONFIRMED
What the user or system observes.
Relevant signals and context.
Plausible explanations to investigate.
Checks that can confirm or reject them.
A conclusion supported by evidence.
Atlas should help narrow the investigation. It should not imply that every root cause can always be identified automatically.
Potential context may include link-state changes, authentication events, device restarts, configuration changes where available, upstream changes, monitoring-state changes and dependency failures.
A recent change does not automatically mean causation. It is evidence to compare with timing, scope and other signals.
A fault may affect one device, one customer, one wireless sector, one site, several downstream services or a larger network path.
One device or customer.
One site, sector or service.
Several downstream services.
A broader infrastructure or upstream issue.
Operational diagnosis becomes more useful when technical evidence is linked to impact. No real customer data is shown here.
FROM SIGNAL TO GUIDANCE
Gather available evidence.
Check freshness and reliability.
Connect related events.
Consider current and recent state.
Identify plausible causes.
Determine what to check next.
Provide guidance or pass verified evidence onward.
No single metric should define the whole diagnosis.
CLEAR ABOUT UNCERTAINTY
Diagnosis becomes less reliable when data is missing or stale, an integration is unavailable, signals conflict, visibility is incomplete or customer-side evidence is unavailable.
Known and current signals.
Gaps that limit interpretation.
A direction for investigation.
A result supported by checks.
Atlas should communicate uncertainty without inventing numerical confidence scores.
Before evidence is trusted, Atlas should care about last successful ingest, heartbeat, stale data, failed collectors, API availability and processing errors.
The health of the evidence matters as much as the evidence itself.
Explore Intelligent MonitoringReduce investigation time, surface useful evidence, identify relationships, narrow possibilities and guide checks.
Handle unusual faults, incomplete evidence, physical inspection, complex changes and final verification.
Engineering judgement remains essential wherever evidence is incomplete or the network situation is unusual.
What changed? Is it healthy? Is the data fresh? Who may be affected?
Explore Intelligent MonitoringWhat evidence is related? What are plausible causes? What should be checked next? What would verify the diagnosis?
Automated Diagnostics is about interpretation. Network Automation is about performing an approved action.
Detect evidence.
Interpret evidence.
Check the conclusion.
Apply human or policy control.
Perform an approved action.
Verify the outcome.
An alert should never trigger an unrestricted network change.
Atlas may examine latency, packet loss, utilisation, shared infrastructure, recent events and service state before suggesting where investigation should go next.
Slow service.
Quality, capacity, state and scope.
Congestion, wireless quality, infrastructure, upstream service or customer equipment?
The objective is not to guess faster. It is to investigate better.
One isolated failure may be noise. Repeated failures may indicate instability, intermittent link degradation, recurring authentication trouble, upstream issues, dependency problems or equipment problems.
Diagnostics should use history where supported. Current historical-analysis coverage is not presented as complete.
Where relevant and supported, unusual traffic, repeated connection attempts, relevant IDS events or blocked and resolved DNS activity may add context.
Automated Diagnostics is not presented as a SOC, MDR, EDR or malware-analysis platform.
Use supported operational evidence.
Compare timing, scope and relationships.
Consider customer, site and device context.
Reduce the investigation space.
Guide verification.
Pass verified outcomes forward where appropriate.
Is this congestion or packet loss?
Is the problem isolated or shared?
Did anything change before the issue started?
Is the evidence fresh?
Are multiple alarms related?
Is the issue customer-side or network-side?
Is an upstream service involved?
Is a dependency unavailable?
What evidence is still missing?
What should we test next?
An Atlas capability being developed to correlate operational evidence and help narrow likely causes of network and service problems.
No. Monitoring detects state and change. Diagnostics interprets related evidence.
No. Diagnostic quality depends on available, reliable evidence, and some faults still require human investigation.
No. Diagnosis and automation are separate stages. Future automation should remain controlled and approved.
No. It is intended to improve evidence, investigation and decision-making.
It may show when evidence points away from shared infrastructure, but endpoint and device monitoring belongs primarily to Digital Care.
EVIDENCE BEFORE ACTION
Atlas Automated Diagnostics is being developed to bring relevant evidence together, narrow likely causes and help Layer 3 decide what should be checked before making changes to the network or customer service.