# How to Use the Evidence → Finding → Path Workflow in reverse‑skill

> Master the Evidence→Finding→Path workflow for reproducible reverse-engineering. Learn to capture observations, derive conclusions, and document your attack path.

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

---

**The Evidence → Finding → Path workflow is a structured, reproducible methodology for capturing immutable observations, deriving validated conclusions, and documenting the logical sequence that leads to successful reverse‑engineering or attack execution.**

The `reverse-skill` repository implements this workflow as its core knowledge‑base pattern. Whether you are analyzing malware, solving CTF challenges, or conducting penetration tests, this three‑stage chain ensures every conclusion is traceable to concrete data and every path can be independently reproduced. The contract governing this workflow is defined in [`skills/ops/evidence-finding-path.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/evidence-finding-path.md) in the zhaoxuya520/reverse‑skill repository.

## What Is the Evidence → Finding → Path Workflow

The workflow enforces a strict dependency chain: **Evidence** records what you saw, **Finding** explains what it means, and **Path** narrates how you used it. This separation prevents circular reasoning and enables automated validation. Each stage has mandatory fields, file naming conventions, and binding rules that the case‑review script enforces.

### Stage 1: Evidence (Immutable Observations)

Evidence files capture raw observations without interpretation. Every evidence item receives a unique identifier (`E-{nnn}`) and lives in `work/<case>/evidence/E-{nnn}.md`. The schema requires:

```markdown

### E-001

- title: Suspicious PowerShell Command
- observed_at: 2024-01-15T09:23:00Z
- source_type: command
- source_ref: powershell.exe:pid-4824
- content_hash: n/a
- artifact_path: n/a
- repro_command: |
    Get-Process | Where-Object {$_.CPU -gt 1000}
- raw_excerpt: |
    Handles  NPM(K)    PM(K)      WS(K)     CPU(s)     Id  SI ProcessName
    -------  ------    -----      -----     ------     --  -- -----------
    ...
- linked_workitem: WI-001
- supersedes: none

```

The `source_type` field accepts: `command`, `screenshot`, `file`, `log`, `memory`, `network`, or `manual`. When `content_hash` is populated, `artifact_path` must point to a file within the case root. The `repro_command` field ensures any team member can recreate the observation.

### Stage 2: Finding (Analytic Conclusions)

Findings synthesize one or more evidence items into actionable intelligence. Stored as `work/<case>/findings/F-{nnn}.md`, each finding must reference at least one evidence item via `evidence_ids`. The full schema includes:

```markdown

### F-001

- title: High CPU Consumption Indicates Crypto‑Miner
- severity: high
- category: vuln
- status: validated
- evidence_ids: [E-001, E-002]
- location: powershell.exe:line-12
- impact: Unauthorized resource consumption and potential lateral movement
- confidence: high
- repro_steps:
  1. Execute repro_command from E-001
  2. Observe CPU > 90% for 30 seconds
  3. Cross‑reference network traffic in E-002
- remediation: Isolate host and scan for persistent mechanisms
- optional_attack: T1496

```

Critical binding rules from [`evidence-finding-path.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/evidence-finding-path.md) (lines 25‑29): a `validated` status requires **confidence ≠ low** unless a residual‑risk note is added, and every finding must reference **at least one evidence item**. The `category` field distinguishes vulnerability analysis from reverse‑engineering (`reverse_algo`) or bypass techniques.

### Stage 3: Path (Structured Narrative)

Paths assemble evidence and findings into a coherent sequence. They serve three purposes: attack reconstruction, call‑flow documentation, or CTF solve walkthroughs. Path files follow `work/<case>/paths/P-{nnn}.md`:

```markdown

### P-001

- title: Cryptominer Initial Access to Execution
- path_type: attack
- start: Phishing email with malicious attachment
- goal: Establish persistent cryptominer process
- steps:
  1. action: Victim opens weaponized document — evidence: E-003 — finding: F-002
  2. action: Macro drops PowerShell payload — evidence: E-001 — finding: F-001
  3. action: PowerShell connects to C2 — evidence: E-002 — finding: none
- residual_risks: C2 infrastructure remains active; recommend sinkhole analysis

```

The `path_type` field accepts `attack`, `callflow`, or `solve`. Each step explicitly links to evidence and optionally to findings, creating an auditable chain from observation to outcome.

## How to Implement the Workflow

Implementation follows a four‑step process: initialize the case structure, populate evidence, derive findings, and assemble paths. The repository provides automation for verification and report generation.

### Step 1: Initialize Case Structure

Create the standard directory layout under `work/<case>/`:

```bash
mkdir -p work/MyCase/{evidence,findings,paths}

```

### Step 2: Create Evidence Entries

Use the PowerShell helper for rapid evidence capture:

```powershell
powershell -File skills/scripts/append-evidence.ps1 `
  -CaseRoot work/MyCase `
  -Id E-001 `
  -Title "Suspicious PowerShell Command" `
  -ReproCommand "Get-Process | Where-Object {$_.CPU -gt 1000}" `
  -Severity info `
  -Status observed

```

The script enforces field validation and generates the markdown file directly. For manual creation, copy the template from [`skills/ops/evidence-finding-path.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/evidence-finding-path.md) (lines 12‑20).

### Step 3: Derive and Link Findings

Create [`work/MyCase/findings/F-001.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/work/MyCase/findings/F-001.md) referencing your evidence:

```markdown

### F-001

- title: Anomalous Process Behavior Detected
- severity: medium
- category: other
- status: candidate
- evidence_ids: [E-001]
- location: n/a
- impact: Requires further investigation
- confidence: medium
- repro_steps:
  1. See E-001 repro_command
- remediation: n/a
- optional_attack:

```

Promote to `validated` only when confidence is `high` or `medium` with documented residual risks.

### Step 4: Assemble and Verify Paths

Construct your path narrative, then run the verification script:

```bash
python3 skills/case-review/scripts/review_case.py work/MyCase --verify-hashes --strict

```

This script performs three critical validations (lines 37‑41):

1. **Hash integrity**: Recalculates SHA‑256 for all artifacts and compares against `content_hash`
2. **Link integrity**: Confirms every `evidence_ids` entry points to an existing evidence file
3. **Status rules**: Enforces that `validated` findings have `confidence` ≥ `medium` or explicit risk acceptance

Verification failures block report generation, ensuring quality gates are met.

## Report Integration and Automation

The `docs-generator` subsystem consumes Evidence tables, Findings lists, and at least one Path to produce final security reports (lines 88‑96). The generator respects the same binding rules, producing documents where every claim links to underlying evidence. Report templates are documented in [`docs-generator/references/security-report-templates.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/docs-generator/references/security-report-templates.md).

## Key File Reference

| Purpose | Path |
|--------|------|
| Workflow contract and schemas | [`skills/ops/evidence-finding-path.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/evidence-finding-path.md) |
| Evidence creation helper | `skills/scripts/append-evidence.ps1` |
| Case verification script | [`skills/case-review/scripts/review_case.py`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/case-review/scripts/review_case.py) |
| Report template documentation | [`docs-generator/references/security-report-templates.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/docs-generator/references/security-report-templates.md) |
| Example CTF evidence/finding/path | [`examples/ctf-demo/evidence/E-001.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/examples/ctf-demo/evidence/E-001.md), [`F-001.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/F-001.md), [`P-001.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/P-001.md) |

## Summary

- **Evidence** files (`E-{nnn}.md`) store immutable observations with mandatory `repro_command` and optional `content_hash`
- **Finding** files (`F-{nnn}.md`) require at least one `evidence_ids` entry and enforce status/confidence binding rules
- **Path** files (`P-{nnn}.md`) link evidence and findings into `attack`, `callflow`, or `solve` narratives
- The [`review_case.py`](https://github.com/zhaoxuya520/reverse-skill/blob/main/review_case.py) script validates hashes, links, and business rules with `--verify-hashes --strict`
- The `docs-generator` pipeline automatically transforms compliant cases into security reports

## Frequently Asked Questions

### How do I update evidence without breaking the chain?

Use the `supersedes` field to deprecated obsolete evidence. Create `E-002` with `supersedes: E-001`, then update dependent findings to reference the new evidence. The verification script warns on orphaned `supersedes` references but permits the chain to remain auditable.

### Can a finding reference evidence from another case?

No. The `evidence_ids` field uses relative references resolved against `work/<case>/evidence/`. Cross‑case linking would break portability and hash verification. Copy relevant evidence files or reference external cases in the `linked_workitem` field instead.

### What happens if verification fails with `--strict`?

The script exits non‑zero and emits a JSON error report. Common failures include: missing evidence files referenced in findings, hash mismatches on artifacts, or `validated` findings with `low` confidence without residual‑risk documentation. Fix the underlying files and re‑run until clean.

### Which `path_type` should I use for malware analysis?

Use `callflow` when documenting execution flow through decompiled functions. Use `attack` when reconstructing the adversary's operational sequence. Use `solve` exclusively for CTF or challenge walkthroughs where the goal is a flag rather than security impact assessment.