Capstone Project

The capstone is the clearest proof that you can apply the Exploit Paths method end to end.

Its purpose is not to reward passive completion of the course. Its purpose is to produce one structured artifact that shows you can interpret a grounded public case, map it into primitives and roles, construct candidate routes, identify constraints, and define how validation would confirm what survives.

The result should read like disciplined exploit-path analysis, not like a dramatic exploit story.

Before starting the capstone, complete Modules 1 through 8 and review Appendix A.

The capstone assumes you can already work with the unit shift, primitive families, path roles, outcome classes, the validation loop, grounded case comparison, AI-assistance boundaries, and the industrialization lens.

Use this sequence:

1. select one grounded public CVE or case
2. identify the visible weakness and likely CWE
3. map the case into one or more primitive families
4. assign the strongest path role or roles
5. identify the strongest plausible outcome class
6. describe the conditions and constraints that matter most
7. construct one or more candidate exploit paths
8. define a validation plan for the strongest path
9. explain what is supported, what is still conditional, and why
10. package the result into a report plus one supporting visual

If you need a starting pool of grounded material, use the case library.

Your capstone should include:

• Exploit path report: a structured writeup of the selected case using the course vocabulary.
• Exploit path diagram: a simple visual showing the route, transitions, and strongest outcome.
• Validation plan: a proof-oriented plan aligned with Appendix A.
• Evidence summary: notes on what public material, environmental assumptions, or validation observations support the current conclusion.
• Optional AI-assisted analysis: if used, document where AI helped and what required human correction or judgment.

Strong capstones should show:

• Conceptual accuracy: primitive family, path role, and outcome class are used correctly.
• Analytical depth: the route is reasoned through as a path, not just a labeled bug.
• Technical validity: the writeup respects constraints, conditions, and known public facts.
• Methodological rigor: the validation plan is structured and disciplined.
• Clarity and structure: the artifact is easy to review and reuse.
• Reproducibility: another reader can understand how the conclusion was reached.

Use a structure like this:

# Exploit Paths Capstone Report

## 1. Overview
- CVE or case:
- Target system:
- Research objective:

## 2. Vulnerability Summary
- Description:
- Associated CWE:

## 3. Exploit Path Model
- Primitive families:
- Path roles:
- Outcome classes:

## 4. Preconditions and Constraints
- Required configurations:
- Environmental dependencies:

## 5. Candidate Paths
- Path 1:
- Path 2 (optional):

## 6. Validation Plan
- Methodology:
- Environment:
- What would confirm the route:

## 7. Evidence Summary
- Public sources:
- Observations:
- Remaining uncertainties:

## 8. Current Conclusion
- Best-supported route:
- Validation status:
- Why this route survives:

## 9. Optional AI Assistance
- Where AI helped:
- What required human correction:

## 10. Diagram
- Link or embed:

Treat the capstone as a reusable artifact, not as a disposable assignment.

Useful destinations include a portfolio writeup, an internal team reference artifact, a GitHub repository or research note, or a basis for later AI-harness comparison and automation experiments.

The strongest capstone is one that makes the method legible to another reader, not just one that proves you finished the course.