# Faultprint v16 Closure Verification Prompt for Claude

I am giving you a zip file called:

FAULTPRINT_EXTERNAL_VALIDATION_PACKET_V16_HANDOFF_001.zip

This zip is not a fresh product pitch. It is a closure packet after your prior Faultprint v14 External Validation Report 002.

Your job is to verify whether the fixes applied in v15/v16 actually closed the issues you identified.

## What I Want You To Do

Review the v16 packet and answer this question:

Did the v15/v16 fixes correctly resolve the issues from External Validation Report 002, or are there still blockers before this baseline can be used for client-facing draft reports?

## Start Here

Inside the zip, read these first:

1. README_START_HERE.md
2. FAULTPRINT_V15_EXTERNAL_VALIDATION_002_SUMMARY_001.md
3. FAULTPRINT_V16_BOUNDARY_CLEANUP_SUMMARY_001.md
4. FAULTPRINT_V16_FULL_BASELINE_CONSISTENCY_AUDIT_001.md
5. FAULTPRINT_EXTERNAL_VERIFICATION_PACKET_V16_SAMPLE_AUGMENTED_001.csv

Use the full tables only if needed:

- FAULTPRINT_OPERATING_POSTMORTEM_CROSSWALK_016.csv
- FAULTPRINT_CLIENT_OUTPUT_ELIGIBILITY_014.csv

## Specific Things To Verify

Check whether these fixes actually landed:

1. Null/absence rows
   - Are held null/absence rows now low_resemblance?
   - Do they avoid client-facing output?
   - Do they use a null/absence claim template rather than a resemblance claim?

2. OCL-0010 Lemonade
   - Was it downgraded from client_ready to client_ready_with_caveat?
   - Is the stale 2016-era source now explicitly marked as a freshness limitation?
   - Is the row still overclaiming despite the caveat?

3. OCL-0047 Liberty Mutual RightTrack
   - Was it moved from client_ready to hold_internal?
   - Is the reason clear: source anchor not confirmed in served HTML / needs rendered-DOM or static re-anchor?

4. Provenance rows
   - Were OCL-0424 ElevenLabs and OCL-0256 Adobe relabeled from AI Authority Acceleration to Evidence-Container Illusion?
   - Is that label now defensible?

5. OCL-0146 SNAP
   - Was it downgraded from moderate_resemblance to low_resemblance?
   - Does the allowed claim now match the lower band?

6. Boundary fixes
   - Are OCL-0656 and OCL-0494 now written as does-not-prove boundaries?
   - Are OCL-0378 and OCL-0591 also cleaned up in v16?

7. OCL-0577 Verizon
   - Does the packet clearly show that the Verizon PDF was directly verified?
   - Is it reasonable for this row to remain client_ready after that verification?

8. Source-check traceability
   - Does the augmented v16 sample now include raw per-row source-check verdicts, risk flags, and scores?
   - Does that solve the traceability gap you identified?

## What Not To Do

Do not rerun the entire original validation from scratch unless you see a reason.
Do not make findings about the named institutions themselves.
Do not give recommendations to the institutions.
Do not praise the system generally.
Focus on whether the closure is real, incomplete, or introducing new problems.

## Output Format

Return a concise validation closure report with these sections:

1. Closure Verdict
   - Choose one:
     - closure_accepted
     - closure_accepted_with_minor_items
     - closure_incomplete
     - closure_failed

2. Issue-by-Issue Closure Table

Use this table:

| prior_issue | expected_fix | closure_status | remaining_problem_if_any | required_next_action |
|---|---|---|---|---|

3. Remaining Blockers Before Client-Facing Draft Use

List only true blockers. If none, say none.

4. Remaining Non-Blocking Calibration Items

List items that should be improved later but do not block controlled draft use.

5. Bottom Line

Answer plainly:

Can v16 be treated as the current hardened baseline for controlled client-facing draft generation, assuming human source review remains required before final external delivery?