JGoyd/docs/PHASE-8_VALIDATION_LOOP.md

Phase 8 — Validation Loop

Run this checklist on every component before merging it into the public repo. Any "No"/"Yes"/"No" answer pattern on the three Core questions sends the component back for rework.

Core questions (apply to every artifact)

1. Can a skeptic verify this WITHOUT trusting me? YES required.
2. Does this rely only on self-assertion? NO required.
3. Is there a third-party-controlled anchor? YES required.

Component-level checklists

A — /canonical/index.md (profile page)

• One canonical PGP fingerprint, not two
• Fingerprint is fetchable from at least three independent keyservers
• identity-attestation.txt.asc exists and verifies
• If two fingerprints were in circulation, key-cross-attestation.txt.asc exists
• Every CVE in Section 1 has a precise role; none say "discoverer" without vendor backing
• Every Track-A entry in Section 2 carries the standing disclaimer
• Section 3 ("What I am NOT claiming") is present and explicit
• No claim of intelligence/government affiliation

B — Each /evidence/<case>/ folder

• README.md states role precisely
• Track-A folders include the non-adjudication disclaimer
• At least one third-party-controlled URL is in External Anchors
• proof-<case>.headers.eml exists (or PENDING flag is honest)
• proof-<case>.headers.eml.asc PGP signature exists
• proof-<case>.headers.eml.ots OpenTimestamps proof exists
• proof-<case>.redacted.eml is separately signed if published
• dkim-verification-guide.md exists with the correct sender domain
• No exploit payload in any redacted body
• No third-party PII in any redacted body
• No authentication tokens in any URL in the redacted body
• Case ID / reference number is visible in body and matches the README

C — /ledger/running-ledger.txt

• Every entry has a Status value
• Every entry with VERIFIED has a third-party-controlled External Anchor URL
• Every entry with UNVERIFIED is honestly flagged
• running-ledger.txt.asc exists, is non-empty, and verifies under the canonical key
• running-ledger.txt.ots exists and points to a confirmed Bitcoin block (after ots upgrade)
• No hash collisions or duplications between rows (the Slovakia/Lithuania row bug must be fixed)

D — Each PoC repo in /poc/

• No live byte-level exploit primitive
• Crash reproducer (if any) tagged with affected build and patched build
• README disclaims weaponization
• Vendor patch references included

E — Each analysis doc in /analysis/

• Explicitly labeled "forensic reconstruction" or "analytical observation"
• Distinguishes observation from conclusion
• Avoids attribution language unless evidence supports it
• Cites primary sources where possible

Failure modes that trigger rework

• A skeptic can only verify via "Joseph said so" → rework.
• The only external link is to another JGoyd repo → rework.
• An email artifact is published with redactions inside the DKIM-signed body but DKIM fails verification → split into original.sha256 + headers.eml + redacted.eml per Phase 3.
• A claim of "original discovery" without a vendor acknowledgement → rewrite as "reporter" or "enrichment-contributor" or "chain-analyst".
• A Track-A claim that conflates agency receipt with adjudication → add the standing disclaimer.

Self-attack drill (run before each public push)

Pretend to be:

• a skeptical infosec researcher reading the profile page for the first time. Can they reproduce every CVSS-reassessment claim from the NVD CVE-History API in <5 minutes? If no, rework the verification steps.
• a journalist with no security background. Can they ask three concrete yes/no questions of named third parties (NVD, CISA, the prosecutor's office, etc.) to corroborate the most important claim? If no, rework the verification steps.
• an opposing lawyer. Which sentence on the page would they screenshot to argue overreach? Remove or qualify that sentence.