How the Evidence Finding Path Methodology Works in reverse-skill

The Evidence Finding Path methodology is a structured audit framework that links immutable observations (Evidence) to validated conclusions (Findings) and reconstructible workflows (Paths), ensuring every security claim in the reverse-skill framework is traceable, reproducible, and tamper-evident.

The reverse-skill repository implements this rigorous documentation standard to enforce auditability in security assessments and reverse-engineering workflows. This three-tier system, defined in skills/ops/evidence-finding-path.md, ensures that every conclusion is backed by verifiable data and every action follows a logical, reconstructible chain. By mandating specific formats for Evidence, Findings, and Paths across all skill workflows, the framework eliminates ambiguity and supports compliance with industry standards like MITRE ATT&CK.

The Three Pillars of the Evidence Finding Path Methodology

Evidence: Immutable Observations

Evidence forms the foundation of the methodology by capturing self-contained, immutable observations such as command outputs, screenshots, or log files. According to the source specification in skills/ops/evidence-finding-path.md (lines 6-24), each Evidence entry must be a Markdown block containing a reproducible command (repro_command) or a clear statement that the observation is offline only, plus a content hash for any files.

Every Finding requires at least one Evidence entry, creating a hard dependency that prevents unsubstantiated claims. Analysts typically generate these entries using the PowerShell helper script skills/scripts/append-evidence.ps1, which automatically creates the required Markdown skeleton and validates the format.

Finding: Validated Conclusions

Findings represent concrete security or reverse-engineering conclusions derived from one or more Evidence entries. As specified in skills/ops/evidence-finding-path.md (lines 34-53), a Finding must reference non-empty evidence_ids and include metadata describing severity, category, impact, and remediation steps.

The methodology enforces strict validation rules: when status=validated, the confidence level cannot be low unless residual risk is explicitly noted. This ensures that validated conclusions meet a minimum quality threshold before being promoted in the workflow timeline.

Path: Traceable Narratives

Paths assemble the step-by-step logical flow that leads from initial observations to final outcomes, whether describing an attack chain, call flow, or CTF solution. Defined in lines 55-76 of the evidence specification, each Path step may link to an Evidence (E-xxx) and/or a Finding (F-xxx).

A critical requirement states that any terminal Finding claiming "privilege/data obtained" must be backed by validated Evidence. This ensures that the final conclusion of any Path rests on proven, documented facts rather than assumptions.

Workflow Integration and Enforcement

SKILL.md Requirements

All skill workflows in the repository require that final reports include the complete Evidence chain. The docs-generator templates, specifically referenced in docs-generator/references/security-report-templates.md (lines 7-18), automatically pull Evidence tables, Findings lists, and Path sections into standardized security reports.

Timeline Validation

The timeline/workitems system validates that each Finding is backed by Evidence before promotion to subsequent workflow stages. This gate prevents incomplete or unsubstantiated items from advancing through the analysis pipeline.

Field Journal Integration

Field-journal entries automatically extract the most critical Evidence, Finding, and Path snippets for concise, anonymized documentation, ensuring that knowledge capture remains consistent across different operational contexts.

Practical Code Examples

Creating an Evidence Entry

The following Markdown structure represents a valid Evidence entry for a SAM hash dump:

### E-001

- title: Dumped SAM hash
- observed_at: 2026-08-06T14:22:00Z
- source_type: command
- source_ref: `C:\\Tools\\samdump2.exe`
- content_hash: d41d8cd98f00b204e9800998ecf8427e
- repro_command: |
    samdump2.exe -p SYSTEM -s SAM > sam_hashes.txt
- raw_excerpt: |
    [脱敏] NTLM hash: aad3b435b51404eeaad3b435b51404ee
- linked_workitem: WI-101
- supersedes: none

Create this entry using the CLI helper:

powershell -File skills/scripts/append-evidence.ps1 `
  -CaseRoot work/MyCase `
  -Id E-001 `
  -Title "Dumped SAM hash" `
  -ReproCommand "samdump2.exe -p SYSTEM -s SAM > sam_hashes.txt" `
  -Severity info `
  -Status observed

Defining a Finding

This Finding references the previous Evidence to document a privilege escalation:

### F-001

- title: Privilege Escalation – Local Administrator
- severity: high
- category: vuln
- status: validated
- evidence_ids: [E-001]
- location: C:\Windows\System32\sam.dll
- impact: Full admin rights on the host
- confidence: high
- repro_steps:
  1. Run the command from E‑001
  2. Use the extracted hash with pass‑the‑hash
- remediation: Apply strict ACLs and patch CVE‑2025‑XXXX
- optional_attack: T1078

Constructing a Path

The Path ties multiple Evidence and Finding entries into a coherent attack narrative:

### P-001

- title: Lateral Movement Path
- path_type: attack
- start: Initial foothold on victim machine
- goal: Domain Administrator on the target DC
- steps:
  1. action: Dump SAM – evidence: E-001 – finding: F-001 | none
  2. action: Pass‑the‑hash to remote service – evidence: E-002 – finding: F-002 | none
- residual_risks: None

Report Generation

The documentation generator automatically includes these components using template variables:

## Evidence Chain

{{ evidence_table }}

## Findings

{{ findings_list }}

## Attack Path

{{ path_section }}

Key Implementation Files

• skills/ops/evidence-finding-path.md: Formal definition of the Evidence → Finding → Path contract and validation rules.
• skills/scripts/append-evidence.ps1: CLI helper that creates correctly formatted Evidence files with required metadata.
• docs-generator/references/security-report-templates.md: Report templates that enforce inclusion of the Evidence chain in final outputs.
• skills/ops/timeline-workitem.md: Workflow definitions that validate Findings against Evidence before promotion.
• skills/SKILL.md: Master specification requiring all skill-specific reports to contain the Evidence → Finding → Path chain.

Summary

• The Evidence Finding Path methodology creates an immutable audit trail by requiring every Finding to reference concrete Evidence entries.
• Evidence entries must include reproducible commands or offline declarations, plus content hashes for file integrity verification.
• Findings cannot achieve "validated" status with low confidence unless residual risk is explicitly documented.
• Paths construct the logical narrative linking observations to conclusions, with terminal findings requiring validated Evidence backing.
• The methodology is enforced through automated validation in the timeline/workitems system and required inclusion in docs-generator report templates.
• PowerShell automation via append-evidence.ps1 ensures consistent formatting and reduces manual errors in Evidence documentation.

Frequently Asked Questions

What makes Evidence "immutable" in the reverse-skill framework?

Evidence achieves immutability through content hashing and strict formatting requirements defined in skills/ops/evidence-finding-path.md. Once created, an Evidence entry references specific file hashes (like content_hash: d41d8cd98f00b204e9800998ecf8427e) and includes exact repro_command values that allow independent verification. The supersedes field allows obsolescence tracking without modification, preserving the original observation for audit purposes.

How does the Evidence Finding Path methodology prevent false positives?

The methodology prevents false positives through a dependency chain enforced by the timeline/workitems system. Every Finding must reference at least one Evidence entry via evidence_ids, and the validation logic prohibits "validated" status when confidence is marked low unless residual risk is explicitly noted. This ensures that conclusions promoted through the workflow rest on documented, reproducible observations rather than speculation.

Can a Path exist without associated Findings?

Yes, according to the specification in lines 55-76 of skills/ops/evidence-finding-path.md, Path steps may link to Evidence (E-xxx) and/or Findings (F-xxx). However, any terminal step claiming successful "privilege/data obtained" must be backed by a validated Finding that references Evidence. Intermediary steps in a Path may reference only Evidence when describing observable actions that haven't yet yielded a specific security conclusion.

How is this methodology enforced across different reverse-skill modules?

Enforcement occurs at multiple levels: all SKILL.md files require the final report to include the Evidence chain, the docs-generator templates automatically validate the presence of Evidence tables and Path sections, and the timeline/workitems system blocks promotion of Findings lacking Evidence references. Additionally, the skills/scripts/append-evidence.ps1 helper standardizes Evidence creation across different operational contexts, ensuring consistency regardless of the specific skill module being executed.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}