**Focus:** Validate the per-unit knowledge artifact for the post-exploitation stage. Units here are impact assessments — knowledge artifacts that translate technical access into business risk for the report. Validation rules check substance, evidence trail, internal consistency, and decision-register accountability. NOT executable verify-commands or DAG validity (workflow engine / build-stage concerns).

**Anti-patterns (RFC 2119):**
- The agent **MUST NOT** read or interpret unit frontmatter for any mechanical purpose. workflow engine territory per architecture §1.1.
- The agent **MUST NOT** validate against frontmatter schema, `depends_on:` resolution, status-field shape, or any other FM-driven check — those are workflow engine responsibilities.
- The agent **MUST NOT** advance a unit whose body is a placeholder, contains TODO markers, or has empty sections.
- The agent **MUST NOT** reject for stylistic preferences. Substantive gaps only.
- The agent **MUST** name a specific failed criterion in any rejection.
- The agent **MUST NOT** invent rules not in this mandate. Stage scope is the contract.

## What you check (BODY ONLY)

### 1. Access chain documented end-to-end
The unit body MUST trace the access from the initial exploitation foothold through every lateral / escalation step to the final access level. Each step MUST cite the evidence that proves it (command output, screenshot, log entry). Gaps in the chain — a step that says "from here, root was reachable" without showing how — are rejects.

### 2. Impact translated to business terms
Technical access claims MUST be paired with a business-impact statement — what data is exposed (with sensitivity classification), what regulatory regime is implicated, what blast radius the access enables. Pure technical impact without business translation is a reject; that's the impact-assessor's primary deliverable.

### 3. Demonstrated vs. theoretical clearly marked
Every impact claim MUST distinguish demonstrated impact (the access chain proved it) from theoretical impact (the access chain would enable it if pursued, but the operator did not). Theoretical claims MUST be labeled and MUST cite the access state from which they would proceed. Reject if demonstrated and theoretical are mixed without labels.

### 4. Severity rating tied to rubric
The impact severity MUST cite the engagement's chosen rubric (CVSS environmental, DREAD, or the engagement-specific rubric) and MUST show the inputs used to derive the score. A bare severity number with no derivation is a reject.

### 5. Decision-register consistency
The unit must not propose an impact rating or remediation hint that contradicts a recorded Decision (e.g., a data-classification stance the engagement already committed to). Cite the Decision ID in any rejection.

### 6. Cleanup confirmed
The body MUST confirm that any artifact left during post-exploitation analysis (test files, temporary sessions, observation tooling) has been removed and the removal has been observation-confirmed. Open artifacts are a reject — they're a real risk left on the target.
