Critical infrastructure use case · Amazon Web Services + Snowflake + OpenAI + ServiceNow
Log pattern to incident
Individually ordinary log entries can form a meaningful failure pattern that is difficult to spot across services and time windows. Operators receive a proposed incident supported by related log events, with hypotheses separated from observed evidence.
Systems involved
What each system contributes
61 actions
- S315
- Lambda10
- EC215
Trigger source: AWS S3, AWS SNS, AWS SQS, AWS CloudWatch, AWS CloudWatch Events
35 actions
- Tables6
- Views6
- Data Loading & Stages8
25 actions
- Chat Completions8
Approved threshold monitoring stays in place. Log reads outside the pre-built AWS actions are configured through permitted APIs or Rules + Code for the sources in scope. The model step runs against the AI provider you choose, including Anthropic, Google Gemini or a model you host yourself. Anything outside a pre-built action runs through an API, protocol or database call, or as Rules + Code in Python, Bash, Go, Java, .NET, PHP, PowerShell or JavaScript/TypeScript, with the same approvals and audit.
Architecture
One governed run
How it starts: A defined review window of operational logs becomes available or an operator requests analysis of an unexplained service symptom.
Step by step
How the process runs
- 01
Assemble the permitted window
Read the authorized AWS log source through an available interface and the corresponding operational dataset in Snowflake.
- 02
Prepare comparable evidence
Rules normalize timestamps and resource identifiers, remove restricted fields and record missing portions of the window.
- 03
Identify a candidate pattern
The selected model relates sequences and symptoms across the supplied events and proposes an incident hypothesis with cited examples.
- 04
Validate the hypothesis boundaries
Check that the cited events exist and fit the permitted resources and time window without treating correlation as proven causation.
- 05
Open the investigation
A separate ServiceNow action creates the permitted incident or review item with the evidence and explicit uncertainty attached.
Control
Human decision and exception path
Human decision
The named operations owner reviews uncertain incident proposals and authorizes any subsequent operational response. Creating an investigation record does not authorize remediation, access changes or a declaration that the proposed cause is established.
Exception path
- Incomplete logs or inconsistent clocks mark the analysis limited and request investigation of the missing evidence.
- Unsupported event relationships are withheld from the incident facts and retained only as reviewable hypotheses.
- Existing incident references are checked before creation, while any mandatory alerting continues independently.
Evidence
What gets audited
- Log-source references, Snowflake dataset and analyzed window.
- Permitted excerpts, normalization rules and coverage gaps.
- Model hypothesis, cited event sequences and validation results.
- ServiceNow response and operations-owner disposition.
Nexus runs on premises, in private or sovereign cloud, or air-gapped. Credentials stay in the vault, roles decide who can approve, and the execution record stays inside your deployment boundary.
Sovereignty and deploymentRelated
Patterns, connectors and next steps
- AWS-ServiceNow integration
Integration pattern · Cloud events become enriched incidents and approved changes.
- Amazon Web Services connector
61 pre-built actions
- Snowflake connector
35 pre-built actions
- OpenAI connector
25 pre-built actions
- ServiceNow connector
55 pre-built actions
- Infrastructure orchestration
Operations runbooks with approval and evidence.
- Infrastructure alert to incident and remediation
Another critical infrastructure use case.
FAQ
Questions about this use case
- Does Nexus replace any of these systems?
- No. Each system keeps its own records. Nexus runs the process between them and records each decision.
- How does the run start?
- A defined review window of operational logs becomes available or an operator requests analysis of an unexplained service symptom.
- What if a step is not covered by a pre-built action?
- Approved threshold monitoring stays in place. Log reads outside the pre-built AWS actions are configured through permitted APIs or Rules + Code for the sources in scope. The model step runs against the AI provider you choose, including Anthropic, Google Gemini or a model you host yourself. Anything outside a pre-built action runs through an API, protocol or database call, or as Rules + Code in Python, Bash, Go, Java, .NET, PHP, PowerShell or JavaScript/TypeScript, with the same approvals and audit.
- Does the model prove the root cause?
- No; it proposes a pattern for investigation and shows the events behind it, while causal conclusions require operational verification.
Use case review
Discuss this use case
Bring your version of the process. We will map the systems, approvals and evidence it needs.