# Evidence-Finding-Path Methodology in reverse-skill: A Complete Guide to Audit-Ready Traceability

> Master the Evidence-Finding-Path methodology in reverse-skill for audit-ready traceability. Learn how to chain evidence to conclusions and exploitation narratives for cryptographically verifiable engagements. Get the complete g...

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

---

**The Evidence-Finding-Path (EFP) methodology is a strict, markdown-based traceability framework that chains immutable raw observations (Evidence) to analytical conclusions (Finding) and finally to exploitation narratives (Path), ensuring every claim in reverse-skill engagements can be cryptographically verified and reproduced.**

The **Evidence-Finding-Path methodology** is the core architectural pattern used throughout the *reverse-skill* repository for maintaining audit-ready traceability in security assessments and capture-the-flag (CTF) solutions. Developed by zhaoxuya520, this three-layer framework transforms ad-hoc notes into a structured, machine-validated chain of custody for all analytical work. The canonical contract is defined in [`skills/ops/evidence-finding-path.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/evidence-finding-path.md), with enforcement handled by PowerShell and Python validation scripts.

## The Three Layers of EFP Traceability

The methodology operates through three strictly defined markdown layers, each serving a distinct purpose in the evidence chain.

### Evidence Layer: Immutable Raw Observations

The **Evidence** layer captures ground-truth data from the target environment. Every evidence record is designed to be cryptographically verifiable and reproducible.

Key fields defined in [`evidence-finding-path.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/evidence-finding-path.md) lines 6-24:

| Field | Purpose |
|-------|---------|
| `title` | Human-readable description of the observation |
| `observed_at` | Timestamp of capture |
| `source_type` | Origin category (command, screenshot, file, log) |
| `source_ref` | Pointer to original system artifact |
| `content_hash` | SHA-256 hash for integrity verification |
| `artifact_path` | Local storage location of raw data |
| `repro_command` | Exact command to recreate the observation |
| `raw_excerpt` | Short verbatim sample |
| `linked_workitem` | Connection to ticket or case tracker |
| `supersedes` | Previous evidence this replaces |

The `content_hash` and `artifact_path` fields provide **cryptographic proof** that evidence has not been tampered with after collection.

### Finding Layer: Structured Analytical Conclusions

The **Finding** layer transforms raw evidence into security-relevant conclusions. As defined in [`evidence-finding-path.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/evidence-finding-path.md) lines 43-60, every finding must explicitly declare its evidentiary foundation through the `evidence_ids` field.

Required fields include:
- `severity` and `category` for risk triage
- `status` (proposed | validated | disputed | retracted)
- `evidence_ids` array linking to supporting Evidence records
- `location` pinpointing the vulnerable code or configuration
- `confidence` level (low | medium | high | certain)
- `repro_steps` for independent verification
- `optional_attack` mapping to MITRE ATT&CK techniques

This explicit dependency graph—**Finding → Evidence**—ensures no conclusion stands without documented support.

### Path Layer: Narrative Attack Chains

The **Path** layer weaves multiple findings into coherent exploitation narratives or solution walkthroughs. Defined in [`evidence-finding-path.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/evidence-finding-path.md) lines 64-84, paths support multiple narrative types through the `path_type` field: `attack`, `defense`, `ctf-solution`, or `root-cause`.

Each step in a path's `steps` array explicitly references:
- `evidence`: The raw observation grounding this step
- `finding`: The analytical conclusion (may be `none` for transitional steps)

This creates a **directed acyclic graph** connecting high-level narratives back to source-level data.

## Automated Enforcement of EFP Contracts

The *reverse-skill* repository implements multiple validation mechanisms to enforce methodology compliance.

### Validation Script: verify-routing-coherence.ps1

The PowerShell script `skills/scripts/verify-routing-coherence.ps1` performs structural validation across case files. According to source analysis lines 82-86, it asserts:
- Every `Finding` lists at least one valid `Evidence` ID
- Each `Path` step references existing `Evidence` or `Finding` entries
- Required markdown frontmatter fields are present

### Python Reviewer: review_case.py

The [`skills/case-review/scripts/review_case.py`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/case-review/scripts/review_case.py) script provides deeper integrity checks (source lines 38-41):
- Validates `content_hash` values against actual artifacts
- Verifies cross-reference existence and reciprocity
- Flags field inconsistencies across the case graph

These automated checks eliminate manual audit preparation overhead.

## Practical Implementation: Creating EFP Records

### Adding Evidence with append-evidence.ps1

The CLI helper streamlines evidence creation while enforcing the contract:

```powershell
powershell -File skills/scripts/append-evidence.ps1 -CaseRoot work/MyCase `
  -Id E-001 -Title "Suspicious Process Execution" `
  -ReproCommand "ps -ef | grep malicious.exe" -Severity high -Status observed

```

This writes [`work/MyCase/evidence/E-001.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/work/MyCase/evidence/E-001.md) with all required fields populated per the EFP contract.

### Defining a Finding with Evidence Backlinks

```markdown

### F-001

- title: Privilege Escalation via CVE-2024-XXXX
- severity: critical
- category: vuln
- status: validated
- evidence_ids: [E-001, E-002]
- location: /tmp/exploit.c:45
- impact: Root-level code execution
- confidence: high
- repro_steps:
  1. Compile exploit.c
  2. Run ./exploit
- remediation: Apply vendor patch
- optional_attack: T1068

```

The `evidence_ids: [E-001, E-002]` array creates the mandatory traceability link.

### Constructing an Auditable Path

```markdown

### P-001

- title: Full Attack Path for CVE-2024-XXXX
- path_type: attack
- start: Initial foothold on low-privileged account
- goal: Obtain SYSTEM privileges
- steps:
  1. action: Initial reconnaissance — evidence: E-001 — finding: F-001
  2. action: Credential harvesting — evidence: E-003 — finding: F-005
  3. action: Privilege escalation — evidence: E-004 — finding: F-001
- residual_risks: None

```

Each step's dual references ensure the narrative can be decomposed into verifiable components.

## Integration with Reporting and Identity

The EFP methodology integrates with broader *reverse-skill* workflows through additional contracts.

### Report Generation

The `docs-generator` module embeds complete Evidence-Finding-Path chains into final deliverables. The reference specification in [`security-report-templates.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/security-report-templates.md) (source line 98) mandates that executive summaries must be expandable into full EFP traces for auditor review.

### Case Identity Binding

[`skills/ops/IDENTITY.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/IDENTITY.md) defines how EFP records attach to case identities, ensuring that evidence collected across multiple analysts or sessions maintains coherent provenance.

## Key Files in the EFP Implementation

| File | Role |
|------|------|
| [`skills/ops/evidence-finding-path.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/evidence-finding-path.md) | Canonical contract specification |
| `skills/scripts/append-evidence.ps1` | Evidence creation CLI |
| `skills/scripts/verify-routing-coherence.ps1` | Structural validation |
| [`skills/case-review/scripts/review_case.py`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/case-review/scripts/review_case.py) | Integrity and hash verification |
| [`docs-generator/references/security-report-templates.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/docs-generator/references/security-report-templates.md) | Report integration spec |
| [`skills/ops/IDENTITY.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/IDENTITY.md) | Case identity binding rules |

## Summary

The **Evidence-Finding-Path methodology** in *reverse-skill* provides:

- **Cryptographic immutability** through `content_hash` and `artifact_path` in Evidence records
- **Explicit dependency graphs** via mandatory `evidence_ids` in Findings and dual references in Path steps
- **Automated validation** through `verify-routing-coherence.ps1` and [`review_case.py`](https://github.com/zhaoxuya520/reverse-skill/blob/main/review_case.py)
- **Reproducible observations** via required `repro_command` fields
- **Audit-ready reporting** through integration with `docs-generator` templates

This three-layer framework transforms individual analyst notes into a defensible, machine-verifiable chain of custody suitable for security assessments, incident response, and competitive CTF documentation.

## Frequently Asked Questions

### What makes EFP different from standard note-taking?

Standard note-taking lacks mandatory cross-references and cryptographic verification. The **Evidence-Finding-Path methodology** enforces that every Finding cites specific Evidence IDs and every Path step declares both evidence and finding sources. Automated validation scripts reject records missing these links, eliminating the drift between notes and verifiable data that plagues conventional approaches.

### How does EFP ensure evidence integrity?

Each Evidence record includes a `content_hash` field (typically SHA-256) and an `artifact_path` pointing to the original captured data. The [`review_case.py`](https://github.com/zhaoxuya520/reverse-skill/blob/main/review_case.py) script verifies that stored hashes match current file contents, detecting any post-collection modification. This provides cryptographic proof of evidence state at time of capture.

### Can EFP paths reference multiple finding types simultaneously?

Yes. Path steps use separate `evidence` and `finding` fields, allowing steps to reference Evidence directly when no formal Finding exists yet, or to reference Findings without Evidence for transitional narrative moments (using `none`). The `verify-routing-coherence.ps1` script validates that referenced IDs exist in the case, regardless of combination.

### Is the EFP methodology suitable for non-security contexts?

The `path_type` field supports `ctf-solution` and `root-cause` types beyond `attack` and `defense`, indicating broader applicability. The core pattern—immutable observations → cited conclusions → linked narratives—transfers to any domain requiring audit trail from raw data to final recommendations.