How it works
Six steps, from an event happening to someone checking the record.
An event happens
A tenant pays rent. A repair closes with a photo. A household recertifies its income. An applicant is screened. Each is an event a compliance file must account for, and today each lives in a spreadsheet someone has to take on trust.
It gets an ID that is computed, not assigned
The event's identity (where, which day, what kind of record, which one in sequence) is hashed into a SHA-256 ID. The same event always produces the same ID, so a duplicate entry is detectable on sight.
An entry is sealed
The event becomes one entry: small, tied to the one person or system that recorded it, and hashed over its full contents.
It joins the ledger
Each entry joins its recorder's chain carrying the hash of the entry before it. There is no update and no delete. The only thing the ledger can do is add.
Change anything and the check fails
Change one field in one sealed entry and its hash changes. The next entry now points at a hash the record can no longer produce, so every entry after it fails the check. Try it in the diagram below.
Anyone you authorize can check it
Checking means recomputing the hashes from the first entry to the last. It covers the whole history instead of a sample, and it does not depend on trusting us.
Break the chain yourself
Four entries, sealed with real SHA-256 in your browser. Change one and watch its hash change, and every entry after it fail the check. Then restore it and watch the chain pass again.
Sealing chain…