How the Evidence-Finding-Path Workflow Ensures Traceable Audit Trails in Reverse-Skill

The Evidence-Finding-Path workflow guarantees traceable audit trails by forcing every security conclusion into a cryptographically anchored chain: raw evidence receives SHA-256 hashes, findings must cite specific evidence IDs, and paths link the entire sequence, with automated verification failing the build if any link breaks.

The reverse-skill repository provides a structured framework for security analysis and reverse engineering investigations. Its Evidence-Finding-Path workflow creates immutable, cross-referenced records that survive hand-offs, merges, and external review by storing every artifact as hash-verified Markdown and enforcing provenance through mandatory reference fields.

Immutable Evidence Capture with SHA-256 Fixity

In skills/ops/evidence-finding-path.md, the contract defines Evidence blocks (prefixed E-{nnn}) as the foundation of the audit trail. Each evidence file captures raw observations—commands, screenshots, logs, or network dumps—along with three critical traceability fields:

• content_hash: A SHA-256 checksum of the artifact
• artifact_path: The relative location of the raw data
• repro_command: The exact command to reproduce the observation

When analysts capture evidence using the provided helper, the system automatically generates the hash:

powershell -File skills/scripts/append-evidence.ps1 `
  -CaseRoot work/<case> `
  -Id E-001 -Title "Suspicious PowerShell Execution" `
  -ReproCommand "powershell -EncodedCommand ..." `
  -Severity info -Status observed

This creates work/<case>/evidence/E-001.md with an embedded SHA-256 of any associated artifact. The hash acts as a fixity seal; any alteration to the underlying file changes the digest and breaks the verification chain.

Mandatory Provenance Chains in Findings

The workflow enforces that no conclusion exists without backing evidence. In the contract defined at line 26 of skills/ops/evidence-finding-path.md, every Finding block (prefixed F-{nnn}) must contain a non-empty evidence_ids array. This mandatory field explicitly lists which Evidence records support the conclusion.

By requiring evidence_ids ≠ ∅, the system guarantees that every security claim or reverse-engineering conclusion maps directly to at least one immutable Evidence record. This creates a directed provenance graph where findings cannot float untethered from raw data.

Path Reconstruction for End-to-End Traceability

Paths (prefixed P-{nnn}) represent the highest-level narrative, describing attack flows, call sequences, or solve steps. Each Path block links individual steps to specific Evidence and Finding entries using YAML frontmatter references:

steps:
  - evidence: E-001
    finding: F-002
  - evidence: E-003
    finding: F-004

This structure forms a traversable directed graph that auditors can walk backwards from a final conclusion to the original raw evidence. The explicit "evidence → finding" mapping at each step ensures that even complex multi-stage analyses maintain clear lineage.

Automated Verification and Build Failure

Before any report generation, the read-only verification script skills/case-review/scripts/review_case.py validates the entire chain. Invoked via:

python3 skills/case-review/scripts/review_case.py work/<case> \
  --verify-hashes --strict

The script performs three critical checks:

1. Scope validation: Confirms all F-* → E-* → P-* references resolve to existing files
2. Hash verification: Recomputes SHA-256 digests and compares them against stored content_hash values
3. Completeness audit: Ensures no Finding lacks referenced Evidence (enforcing line 26 of the contract)

If any link is broken, hash mismatched, or reference missing, the script exits with an error code and fails the build, preventing unverified chains from reaching stakeholders.

Tamper-Evident Report Generation

The final security report embeds the Evidence table, Findings list, and at least one Path directly from the Markdown contracts using skills/docs-generator/generate_report.py:

python3 skills/docs-generator/generate_report.py \
  --case work/<case> \
  --output reports/<case>-security-report.pdf

Because the generator pulls directly from the immutable source files rather than accepting manual input, any post-report alteration would require modifying the underlying Evidence, Finding, or Path files. Such modifications would immediately invalidate the SHA-256 hashes and fail subsequent verification, providing cryptographic tamper-evidence that extends from raw data through final documentation.

Summary

• SHA-256 anchoring: Every evidence artifact receives a cryptographic hash stored in its Markdown contract, ensuring any alteration is detectable
• Mandatory references: Findings must cite specific evidence IDs (enforced at line 26 of the contract), preventing unsubstantiated conclusions
• Graph structure: Paths link steps to both evidence and findings, creating a traversable chain from conclusion to raw data
• Automated verification: The review_case.py script fails builds when hashes mismatch or references break, acting as a gatekeeper
• Tamper-evident reporting: Generated reports pull directly from hashed source files, making any post-hoc modification detectable through verification failures

Frequently Asked Questions

What happens if an evidence file is modified after hashing?

The review_case.py verification script recomputes SHA-256 digests during the --verify-hashes check. If the recomputed hash does not match the content_hash stored in the Evidence Markdown file, the script exits with an error and fails the build, flagging the specific E-{nnn} entry that was tampered with.

Can a Finding be created without linking to Evidence?

No. According to line 26 of skills/ops/evidence-finding-path.md, the evidence_ids field in a Finding block must not be empty (evidence_ids ≠ ∅). The verification script enforces this constraint strictly; attempting to generate a report with an unlinked Finding will trigger a completeness audit failure.

How does the workflow ensure reproducibility across different machines?

Each Evidence block contains a repro_command field that stores the exact syntax used to generate the observation. Combined with the artifact_path and SHA-256 hash, analysts on different systems can re-execute the command and verify that the resulting data matches the stored digest, ensuring environment-agnostic reproducibility.

Is the audit trail preserved if the case folder is shared or version-controlled?

Yes. Because Evidence, Finding, and Path objects are plain Markdown files with embedded hashes, they integrate seamlessly with Git or other VCS systems. Hash verification detects any merge conflicts or accidental modifications, while the text-based format ensures diff tools can track changes to the audit logic itself.

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