Provenance, from ledger line to finding

• Rule id and rule version, so a finding remains attributable after a rule changes.
• The records involved, by identifier, resolvable back to the stored ledger.
• Attributes compared, each marked as matching, diverging, partial or contextual, with both values.
• A chain of custody: when the records were posted, when the rule was evaluated, when the finding was created.
• Source references: file, sheet, row and the columns the values were read from.
• The recommended action, and whatever the accountant recorded during review.

Every dataset receives a SHA-256 digest over a canonical serialisation of its normalised records, in import order. The scheme is published so a third party can reproduce it:

VLDTION-DATASET-V1

"VLDTION-DATASET-V1" US <record count> RS
for each record, in import order:
  documentDate US postingDate US documentType US documentNumber US
  accountCode US counterpartyId US net US vat US vatRate US
  allocationNumber US journalId  RS

US = U+001F, RS = U+001E
amounts written with two decimals, rates with four

• File name, size and import time are excluded: the same ledger exported twice, or renamed, is the same dataset.
• Any change to a normalised value changes the digest.
• The digest appears on the Overview, in Evidence, and in every export.

• Evidence report, a self-contained HTML document with one section per finding, designed to print to PDF. It has no external references and opens anywhere.
• Evidence bundle, the same content as structured JSON (vldtion.evidence.v2, readable by a v1 reader), for archiving with the working papers.
• Findings register, one CSV row per finding. Values beginning with =, +, - or @ are neutralised so a spreadsheet cannot execute exported data.

Every export carries the application version, the dataset fingerprint and its scheme, the run identifier, the rule-set version, and the rule version behind each finding. Another accountant can therefore tell exactly which data and which rules produced what they are reading.