What Is a Path (P-{nnn}) in reverse-skill’s Evidence Chain?

A Path (P-{nnn}) in reverse-skill is a structured Markdown artifact that defines the procedural sequence linking Evidence and Findings to a specific security objective, requiring six mandatory fields including title, path_type, start, goal, steps, and residual_risks.

The reverse-skill repository implements a rigorous Evidence Chain methodology for security research, reverse engineering, and CTF documentation. At the core of this system sits the Path, identified by the pattern P-{nnn}, which functions as the logical connective tissue between raw observations (Evidence) and derived conclusions (Findings).

The Four Components of the Evidence Chain

The Evidence Chain in reverse-skill consists of four interlinked artifacts: Evidence (E-{nnn}), Finding (F-{nnn}), Path (P-{nnn}), and Report. While Evidence captures raw observations and Findings represent analyzed conclusions, the Path provides the traceable blueprint that sequences these elements into a coherent narrative. The specification mandates that at least one Path must appear in every generated security report to satisfy reporting requirements defined in docs-generator/references/security-report-templates.md.

Anatomy of a Path (P-{nnn})

The formal specification for Path structure resides in skills/ops/evidence-finding-path.md between lines 64-85. This document establishes the deterministic schema that all Path instances must follow.

Required Fields and Structure

Every Path declaration must include six specific fields:

• title: A concise, human-readable identifier describing the path's objective.
• path_type: One of three enumerated values—attack, callflow, or solve—indicating whether the path describes a penetration testing sequence, reverse-engineering call flow, or CTF solution.
• start: The initial state or entry point (e.g., external network, function address, or challenge statement).
• goal: The terminal objective (e.g., privileged access, extracted data, or solved challenge).
• steps: An ordered list documenting the progression of actions with optional Evidence and Finding references.
• residual_risks: Documentation of remaining threats or mitigation gaps after path completion.

Step Syntax and Validation Rules

The steps field follows a strict format defined in the specification. Each step must declare an action and may optionally reference Evidence and Findings using the syntax:

action: [description] — evidence: E-xxx — finding: F-xxx | none

According to lines 86-87 of skills/ops/evidence-finding-path.md, critical validation constraints apply: any terminal Finding that claims "privilege/data obtained" must be backed by validated Evidence referenced within that Path. This constraint ensures empirical grounding for all procedural conclusions.

Path Types: attack, callflow, and solve

The path_type field categorizes the operational context into three distinct categories:

• attack: Documents penetration testing progressions from initial access to privilege escalation.
• callflow: Maps reverse-engineering workflows tracing program execution from entry points to target functions or data extraction points.
• solve: Records step-by-step solutions for Capture The Flag challenges or similar deterministic puzzles.

Practical Examples of Path Definitions

The reverse-skill specification provides concrete patterns for each path type. These Markdown blocks demonstrate valid Path structures that satisfy the schema requirements.

Attack Path Example

An attack path traces adversarial progression through a network:

### P-001

- title: Obtain Local Administrator
- path_type: attack
- start: External network → phishing email
- goal: Local Administrator on target host
- steps:
  1. action: Phishing email sent — evidence: E-010 — finding: F-005
  2. action: User clicks malicious link — evidence: E-011 — finding: F-006
  3. action: Execute payload → spawn shell — evidence: E-012 — finding: F-007
- residual_risks: User awareness training could mitigate initial phishing step

Call-Flow Path Example

Reverse-engineering workflows use the callflow type to document binary analysis:

### P-042

- title: Extract Encryption Key from Malware
- path_type: callflow
- start: Main entry point (`main()`)
- goal: Retrieve static encryption key
- steps:
  1. action: Resolve `DecryptInit` address — evidence: E-055 — finding: F-022
  2. action: Hook `DecryptInit` to capture key — evidence: E-056 — finding: F-023
- residual_risks: Obfuscation may hide alternate key derivation paths

CTF Solve Path Example

Capture The Flag solutions follow the solve pattern for deterministic challenges:

### P-099

- title: Solve WebAuth Bypass Challenge
- path_type: solve
- start: Vulnerable login page
- goal: Access admin dashboard
- steps:
  1. action: Enumerate hidden parameters — evidence: E-120 — finding: F-045
  2. action: Craft payload bypassing auth check — evidence: E-121 — finding: F-046
- residual_risks: None (challenge is deterministic)

Source Files and Implementation Details

The Path implementation spans two critical files in the reverse-skill repository. The primary specification in skills/ops/evidence-finding-path.md defines the complete schema, field requirements, and validation rules at lines 64-87. The secondary reference in docs-generator/references/security-report-templates.md establishes the reporting constraint that every security document must include at least one Path instance to maintain Evidence Chain integrity.

Summary

• A Path (P-{nnn}) in reverse-skill is a structured Markdown artifact comprising six required fields: title, path_type, start, goal, steps, and residual_risks.
• The specification at skills/ops/evidence-finding-path.md (lines 64-87) mandates that terminal Findings claiming privilege or data access must reference validated Evidence.
• Three path types exist: attack for penetration testing, callflow for reverse engineering, and solve for CTF challenges.
• Every generated security report must contain at least one Path to satisfy the reporting template requirements.

Frequently Asked Questions

What does the P-{nnn} identifier represent in reverse-skill?

The P-{nnn} identifier denotes a unique Path instance within the Evidence Chain, where the numeric suffix functions as a sequential reference number. This naming convention aligns with Evidence (E-{nnn}) and Finding (F-{nnn}) identifiers to create a traceable linkage system between observations, procedural steps, and conclusions.

How do Paths link Evidence and Findings in the chain?

Paths serve as the procedural bridge between raw observations and derived conclusions. Within the steps field, each action explicitly references specific Evidence (E-{nnn}) through the evidence: keyword and Findings (F-{nnn}) through the finding: keyword, creating a verifiable audit trail from initial observation to terminal objective.

What are the mandatory fields for a valid Path definition?

According to lines 64-85 of skills/ops/evidence-finding-path.md, a valid Path requires exactly six fields: title (descriptive name), path_type (attack/callflow/solve), start (initial state), goal (terminal objective), steps (ordered action list), and residual_risks (remaining threats). Omitting any field invalidates the Path structure and breaks the Evidence Chain.

Can a Path exist without associated Evidence?

No. The validation rules at lines 86-87 of the specification explicitly require that any terminal Finding claiming "privilege/data obtained" must be backed by validated Evidence referenced within the Path's steps. While intermediate steps may use "none" for evidence references, critical security claims require empirical backing to maintain chain integrity.

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