Investigation Method · Controlled Funnel

Deep investigation by default is how you waste everyone's time

Three Pass System

I treat ticket work like a controlled funnel. Most tickets collapse in the first two passes — the ones that don't are the ones that actually needed full treatment. Going deep immediately wastes time, increases change risk, and often solves the wrong problem. Start fast. Escalate only what survives.

// pass one

Basic Pass

Confirm the symptom is real. Kill the noise. Box the incident. The objective is not to be clever — it's to be correct quickly without creating risk by changing things you don't understand yet.

~80% of tickets end here

// pass two

Mid Pass

Reduce ambiguity. Not proving root cause yet — aligning multiple perspectives on a shared timeline and narrowing the hypothesis list to the smallest set that fits observed behavior.

~18% of tickets end here

// pass three

Deep Pass

Reserved for high-impact, recurring, or politically sensitive issues. The standard becomes mechanism — not correlation. Stop exploring broadly. Start proving narrowly.

~2% reach this level

Pass one · basic pass — fast truth

Objective

Confirm and Scope

Kill Noise First

// what I verify immediately

→Is it current? Confirm timestamps and whether telemetry is stale, delayed, or duplicated

→Is it real outside the originating console? Validate with at least one independent signal

→What's the blast radius? One device vs many, one site vs global, one workflow vs multiple

→What's the failure mode? Down vs degraded, constant vs intermittent, user-facing vs backend

// obvious checks that prevent wasted work

→Resource saturation: disk, memory, CPU spikes, storage I/O queues, scheduled task overlap

→Service state: stopped services, failed startups, cert issues, DNS, auth and trust failures

→Known windows: backups, patching, scans, automation jobs, and scheduled reboots

→Workflow validation: confirm access path, identity, device, and step where failure occurs

exit criteria

Boxed problem statement exists · Scope and time window recorded with FKG + FKB · If a change is required: low-risk, reversible, clear verification. Otherwise → Mid Pass.

Pass two · mid pass — turn symptoms into a story

Objective

Correlate and Pattern

Reduce Ambiguity

// cross-correlation discipline

→At least two independent sources: RMM, EDR events, OS logs, SIEM, backup console, network monitoring

→Align everything to time. If tools disagree, the disagreement is the lead

→Treat "resolved" in one platform as tentative until a second source confirms it

// pattern and dependency checks

→Timing fingerprints: scan windows, patch cycles, policy syncs, automation runs, time-of-day clustering

→Recurrence: same endpoint, same job, same error signature, same dependency failure

→Dependency map: DNS/auth, VSS, storage paths, certs, firewall rules, service accounts

exit criteria

Hypothesis list short enough to test without guesswork · Each hypothesis has required proof artifacts and falsifying conditions · If remediation is safe and verifiable, proceed. Otherwise → Deep Pass.

Pass three · deep pass — forensic mode

Objective

Isolate and Prove

Mechanism Required

// isolation and testing rules

→One variable at a time whenever possible. Stacked changes destroy attribution

→Reproduce safely when possible. If not, use elimination + multi-source corroboration — and label confidence honestly

→Every hypothesis becomes a test: expected result, failure condition, and captured evidence

// chain-of-causality documentation

→Action: what changed or occurred (policy update, quarantine, patch install)

→Mechanism: how that action produced impact (file lock, blocked process, permission change)

→Proof: artifacts that confirm the chain — logs, timestamps, screenshots, repeatability

exit criteria

Root cause is proven by mechanism — not just correlated. Chain of Action → Mechanism → Observable Effect → Proof is fully documented and defensible under review.