Validation methodology
Every entry in the ledger is one dated, attributed event tied to a specific claim and tool identity — never an unattributed checkmark. A claim's current status is derived fresh from its event history each time the ledger is rendered.
Validation levels
A generic pass is insufficient. Each event records which of these independent dimensions were actually checked:
| Procedure | The described steps were actually followed in the tool. |
|---|---|
| Parameters | The specific settings/values used were recorded, not just the operation. |
| State | Measured before/after image state (statistics) confirmed the change. |
| Artifact | A retained output file was inspected, not just an on-screen preview. |
| Behavior | The result's behavior (e.g. non-regression) was checked against expectations. |
| Equivalence | The result was compared against a reference for how closely it matches. |
| Acceptance | The result was judged against an explicit acceptance criterion. |
Status meanings
| Jeff-validated | The most recent event for this claim passed, and the claim has not changed since. |
|---|---|
| Partially validated | The most recent event passed with qualifications, or corrected the claim rather than fully confirming it. |
| Stale — needs re-validation | The claim's text has changed since it was last validated; the old event no longer applies. |
| Failed validation | The most recent event recorded a failure. |
| Not yet validated | No conclusive validation event is on record for this claim. |
Why not a boolean
A single "validated: true" flag hides how validated something is, by whom, when, and against which version of the claim. This ledger instead keeps every event and derives the current status from the latest one — including detecting when the underlying claim has since changed (marked stale) rather than silently keeping an old stamp current.