# How the Evidence Finding Path Methodology Works in reverse-skill

> Explore the Evidence Finding Path methodology in reverse-skill. Link observations to conclusions and workflows for traceable, reproducible security claims. Learn how it works today.

- Repository: [ZhaoXu/reverse-skill](https://github.com/zhaoxuya520/reverse-skill)
- Tags: how-to-guide
- Published: 2026-08-06

---

**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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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:

```markdown

### 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
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:

```markdown

### 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:

```markdown

### 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:

```markdown

## Evidence Chain

{{ evidence_table }}

## Findings

{{ findings_list }}

## Attack Path

{{ path_section }}

```

## Key Implementation Files

- **[`skills/ops/evidence-finding-path.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/docs-generator/references/security-report-templates.md)**: Report templates that enforce inclusion of the Evidence chain in final outputs.
- **[`skills/ops/timeline-workitem.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/timeline-workitem.md)**: Workflow definitions that validate Findings against Evidence before promotion.
- **[`skills/SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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.