Appropriate use
Use when behaviour differs by Wi-Fi, Ethernet, VLAN, VPN, proxy, region, DNS, or endpoint reachability.
Scope and intent
A controlled workflow specification
This page defines the behaviour, controls, evidence, and outputs required from the skill. It does not claim that a language model can enforce security or correctness by wording alone.
Non-goals
Do not use for unauthorised scanning, packet interception outside approved scope, bypassing enterprise controls, or exposing internal network details in public reports.
- 8
- versioned workflow phases
- 4
- explicit approval gates
- 6
- defined result states
- 9
- versioned output artifacts
Material changes to the source, environment, identity, approved actions, or expected behaviour invalidate dependent approvals and require revalidation.
Workflow
The 8 phases
Each phase has explicit inputs and outputs. Approval gates are hard stops bound to exact versions and hashes.
Phase 1: Scope and authorisation preflight Gate 1 · approve network scope
Confirm device, environment, interfaces, network owner, approved endpoints, capture method, privacy boundary, and prohibited tests.
device · interface · network · endpoint allowlist · consent
Phase 2: Application failure signature
Record the exact user-visible symptom, application logs, timing, active interface, IP family, last-known-good path, and recovery behaviour.
symptom · trigger · duration · interface · recovery
Phase 3: Path inventory
Collect interface state, IP, gateway, DNS, proxy, VPN, certificate chain, required domains, redirects, private-network access, and service dependencies.
local path · name resolution · proxy · TLS · remote origins
Phase 4: Comparison plan Gate 2 · approve diagnostics
Design safe comparisons across Wi-Fi, Ethernet, hotspot, alternate DNS, proxy bypass when authorised, known-good device, and known-good application content.
single-variable comparisons · stop conditions · no scanning
Phase 5: Diagnostic execution
Run bounded DNS, TCP, TLS, HTTP, WebSocket, redirect, and application-level checks. Record timestamps and redact internal addresses where required.
resolution · connect · handshake · request · response · application result
Phase 6: Isolation analysis
Determine whether the signal follows interface, DNS, proxy, certificate, firewall, route, endpoint, application config, device, or remains unknown.
correlation · counterexample · confidence · affected scope
Phase 7: Finding and guidance review Gate 3 · confirm conclusion
Prepare a classification, evidence-backed explanation, safe customer or IT request, workaround when verified, and escalation owner.
application · network · proxy · TLS · DNS · firewall · third party
Phase 8: Publish redacted report Gate 4 · publish
Separate internal diagnostic detail from customer-safe wording, preserve restricted captures, and remove temporary configuration changes.
internal report · external summary · cleanup · retention
Approval contract
Every gate approves an exact decision object
An approval cannot be reused after its environment, source, action plan, or approved document changes.
| Gate | Decision | Required binding |
|---|---|---|
| 1 | Gate 1 · approve network scope | Approval stores approver, role, timestamp, context hash, approved document hash, expiry, and invalidation state. |
| 2 | Gate 2 · approve diagnostics | Approval stores approver, role, timestamp, context hash, approved document hash, expiry, and invalidation state. |
| 3 | Gate 3 · confirm conclusion | Approval stores approver, role, timestamp, context hash, approved document hash, expiry, and invalidation state. |
| 4 | Gate 4 · publish | Approval stores approver, role, timestamp, context hash, approved document hash, expiry, and invalidation state. |
Result model
Defined states prevent vague conclusions
Attempt outcomes remain separate from these workflow results. Errors, cancellations, and invalid context are never silently converted into a pass.
APPLICATION
Network path is healthy enough and the failure follows application behaviour or configuration.
DNS
Name resolution is missing, wrong, delayed, or inconsistent for required endpoints.
PROXY OR FIREWALL
An intermediary blocks, rewrites, terminates, or filters required traffic.
TLS
Certificate validation, handshake, protocol, SNI, or interception causes the failure.
ROUTING OR INTERFACE
The active interface, gateway, route, VLAN, IP family, or switching state causes the issue.
UNKNOWN
Available comparisons cannot isolate the failing layer.
Evidence contract
Evidence must directly support the claim
Evidence has provenance, capture context, privacy classification, retention, and integrity metadata. A convenient artifact is not automatically sufficient proof.
| Claim | Primary evidence | Required validation |
|---|---|---|
| Interface state | OS or device network status | Active interface, IP, gateway, and time are recorded. |
| DNS | Bounded resolution results | Resolver, answer, TTL, and failure type are captured. |
| TLS | Handshake and certificate metadata | Secrets and private keys are never captured. |
| HTTP | Redacted request and response | Redirect chain and contacted origins are verified against allowlist. |
| Comparison | Same-device or same-network matrix | Variables changed between paths are explicit. |
| Application | Runtime log and user-visible result | Transport success is not assumed to equal application success. |
Trust and safety
Controls that must be enforced outside the prompt
These controls belong in the runtime, connector permissions, sandbox, renderer, storage layer, and review process.
Runtime control
No scanning
Only approved hosts, ports, methods, and request counts are allowed.
Runtime control
Network secret protection
Internal IPs, proxy credentials, certificates, and captures follow restricted handling.
Runtime control
Per-request allowlist
Redirects, iframes, WebSockets, and downloads are checked, not only the initial URL.
Runtime control
Configuration rollback
Temporary DNS, proxy, VPN, or interface changes are restored and recorded.
Runtime control
Time synchronisation
Clock state is captured because TLS and log correlation depend on it.
Runtime control
Customer-safe reporting
External summaries request concrete IT checks without publishing sensitive topology.
Decision policy
Ordered outcomes, not averaged pass counts
The first applicable high-severity outcome takes precedence. A manual override is recorded separately and never rewrites the calculated result.
SECURITY OR PRIVACY STOP
The requested diagnostic would exceed authorisation or expose restricted data.
NETWORK OWNER ACTION
Evidence points to DNS, proxy, firewall, TLS, routing, or interface ownership.
APPLICATION OWNER ACTION
The network path is sufficient and product behaviour remains incorrect.
MORE ISOLATION
The leading layer is uncertain and another controlled comparison is required.
PATH HEALTHY
Required endpoints and application flow succeed across the approved path.
Known limitations
Uncertainty and coverage limits remain visible
The workflow documents what it cannot prove and what further evidence would change confidence.
- Limit 1. Successful ping does not prove DNS, TLS, HTTP, WebSocket, or application health.
- Limit 2. Enterprise proxies may intentionally hide their behaviour.
- Limit 3. Packet capture may be unavailable or prohibited.
- Limit 4. Mobile hotspot success narrows the issue but does not identify the exact enterprise control.
- Limit 5. IPv4 and IPv6 can follow different paths.
- Limit 6. Network conditions change over time and results need timestamps.
Outputs
Versioned records for review and continuation
Human summaries are generated from validated structured records. They are not maintained as separate, drifting sources of truth.
network-context.jsonVersioned output produced by the workflow.
endpoint-allowlist.yamlVersioned output produced by the workflow.
path-inventory.mdVersioned output produced by the workflow.
comparison-plan.mdVersioned output produced by the workflow.
diagnostic-ledger.jsonlVersioned output produced by the workflow.
restricted-captures/Versioned output produced by the workflow.
isolation-analysis.mdVersioned output produced by the workflow.
customer-summary.mdVersioned output produced by the workflow.
network-report.htmlVersioned output produced by the workflow.
artifacts/qa/network-qa/<run-id>/ ├── network-context.json ├── endpoint-allowlist.yaml ├── path-inventory.md ├── comparison-plan.md ├── diagnostic-ledger.jsonl ├── restricted-captures/ ├── isolation-analysis.md ├── customer-summary.md └── network-report.html
Example
Example request and controlled output
Input
Investigate why an SCOS device works on Wi-Fi but fails on Ethernet VLAN. Check DNS, TLS, redirects, CloudFront, and Google endpoints without scanning the network.
Output excerpt
Network conclusion: NETWORK OWNER ACTION Isolation: - Wi-Fi: DNS, TLS, and application requests succeed. - Ethernet VLAN: DNS succeeds, TCP connects, but TLS sessions are closed during handshake for required CloudFront and Google origins. - Same device, build, content, and time. Classification: Proxy, firewall, or TLS interception on the Ethernet path. Customer-safe request: Ask network IT to review TLS inspection and allow the documented required domains for the affected VLAN.
Production readiness
Required before operational use
The written skill is only one layer. The repository, runtime, connectors, evidence storage, and publication path must implement these requirements.
- Required. Tool, filesystem, repository, command, secret, and network permissions are enforced outside the model.
- Required. Every source, environment, build, plan, and approval has a version or content hash.
- Required. Untrusted values are escaped, length-bounded, path-safe, and separated from executable instructions.
- Required. Attempt outcomes, scenario verdicts, workflow decisions, and publication status remain separate.
- Required. Raw evidence, publishable evidence, access control, retention, redaction, and deletion are defined.
- Required. Concurrent runs use unique IDs, locks, idempotency keys, and conflict-aware updates.
- Required. Material changes invalidate dependent approvals and outcomes.
- Required. The repository validator passes before the skill is considered production-ready.
In one line
/network-qa
Investigates connectivity failures across interfaces, DNS, proxy, TLS, firewall, redirects, private-network rules, endpoints, and application behaviour while protecting network and customer secrets.