Evidence-backed hypothesis trees

A tree can organize alternative mechanisms and their prerequisites. It is an analysis representation, not an execution plan or a mandated pentest lifecycle. Root nodes name the security question; children identify necessary conditions, competing explanations or concrete observations. Link every observed node to its source and keep proposed tests distinct from results.

Modeling constraints

Use identifiers stable enough to retain provenance when an assumption changes. A child is relevant only when it can change the parent conclusion. Avoid invented services, ports or account privileges. Record contradicted nodes and why they were refuted rather than deleting the evidence. A closed/filtered observation at one time may invalidate a current path, not every possible path or future state. Keep uncertain, refuted, supported and untested claims distinct.

Distilling evidence

For a network scan retain endpoint, protocol, version source, timing and filtering limits. For HTTP retain route, method, identity, input, status, relevant content and comparison control. For source review retain revision, location and caller-to-sink conditions. Summaries should remove repetitive payload bytes, not evidence qualifiers. A 403 does not prove a real protected file exists, and a shell-like prompt does not prove access without an attributed execution observable.

Comparing branches

Choose discriminating questions by information gain, available evidence and task constraints. Similar endpoint names do not establish a shared root cause; a credible cause can motivate bounded variant analysis. Never derive authorization from a branch's rank. The runtime's objective graph remains authoritative for execution; workflow stage order, readiness, dispatch and reporting do not belong in this tree.