How a chain is built
Every property identity starts from a genesis hash derived from its public token (KPD-XXXXX-XXXXX-XXXXX). Each entry after that hashes its own fields together with the previous entry's hash, using SHA-256. That chaining is what makes the record tamper-evident: changing a single field in a single past entry would change that entry's hash, and every entry's hash after it - there's no way to edit history without the break being visible to anyone who recomputes the chain.
What this proves
- The record has not been altered or reordered since it was entered.
- History cannot be fabricated retroactively - inserting a "past" entry after the fact breaks the chain, since every later entry's hash already commits to what came before it.
- Entries are attributed and timestamped.
What this does not prove
Chain integrity says nothing about whether the work described actually happened as described. Most entries are self-reported by whoever controls the record at the time. That's why every entry carries a provenance tag - third-party attested entries (a licensed trade completing work) and document-backed entries (a linked, digest-verified certificate) carry materially stronger evidentiary weight than self-reported ones. An insurer or buyer should weigh provenance and any linked documents, not treat chain verification alone as fully verified evidence.
Checking it yourself
Every public Logbook page has a machine-readable counterpart at /logbook/[shareToken]/verify, returning the full entry list plus the algorithm and genesis recipe needed to recompute the chain independently - you're not required to trust that endpoint's own ok field.