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 | Every validation dimension has explicit applicability, every applicable check passed with evidence, and the event matches the current claim revision. |
|---|---|
| Partially validated | Some dimensions passed, but another was inconclusive or applicability is incomplete; this is not universal validation. |
| 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 applicable passing check is current, or revision/applicability evaluation could not be completed. |
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.