The published spec
How tamper evidence works
“Tamper-evident” is the load-bearing claim of this product, so it cannot be a marketing word. This page is the mechanism in full: what is stored, how each record is chained to the one before it, and how anyone handed a Telure document can check it without trusting us. Everything below is a description of the software as built.
The ledger is append-only
Every durable record in Telure lands in one ledger of entries. The application has no code path that updates or deletes an entry, at any permission level, Telure’s own support included. The database enforces the same rule independently: triggers on the entry table reject every UPDATE and DELETE outright, so even a stray query or a compromised application credential cannot rewrite history. Attachments follow the same discipline: they can never be deleted, and their content and attribution are frozen the moment they are written.
Corrections exist, because honest records need them. A correction is a new AMENDMENT entry that references the original by its id, carries its own author, timestamp, and required reason, and takes its own place at the end of the chain. The original is never touched. Anyone reading the record, in the product or in an export, sees both: what was first written, and what was later said about it.
Every entry is chained to the one before it
Each entry carries a per-facility sequence number that only counts up, and a SHA-256 hash computed over the entry’s own content plus the hash of the entry before it. The recipe is exactly this:
hash = SHA256(
prevHash | gymId | seq | type | createdAt | createdById | payload
)The seven fields are joined with the | character and hashed with SHA-256. createdAt enters the hash in ISO-8601 form. The prevHash of a facility’s first entry is the literal string GENESIS.
- prevHash
- The hash of the previous entry for this facility. For the very first entry, the literal string GENESIS.
- gymId
- The facility the entry belongs to. Each facility has its own chain.
- seq
- The per-facility sequence number: 1, 2, 3, with no gaps and no reuse, enforced by a uniqueness constraint.
- type
- What kind of entry this is: CHECK, INSPECTION, INCIDENT, AMENDMENT, and so on.
- createdAt
- The server-side timestamp at the moment of the write, in ISO-8601 form. Never supplied by the client.
- createdById
- The individual the entry is attributed to. Never a shared account.
- payload
- The content of the entry, exactly as stored: results, notes, attachment digests.
The chain, drawn
Entry 1 CHECK
prev: GENESIS
hash: a3f1c2…
Entry 2 INSPECTION
prev: a3f1c2…
hash: 9c07e4…
Entry 3 AMENDMENT
prev: 9c07e4…
hash: 5db8a1…
Each entry’s hash is the next entry’s prev. Alter anything in Entry 1 after the fact (a word of its payload, its timestamp, its author) and its hash is no longer a3f1c2…, so Entry 2’s stored prev no longer matches, and neither does any hash after it. Inserting or removing an entry breaks the sequence numbers and the chain in the same way.
What this buys is simple: the entire history of a facility can be re-verified by recomputation. Start at GENESIS, recompute each hash from the stored fields, and compare against what is stored. Any alteration, insertion, or removal of a historical entry shows up as a mismatch at the exact sequence number where it happened. Telure runs this verification every time an export is generated and prints the result on the document’s cover.
Time belongs to the server
The timestamp that enters the hash is written by the server at the moment of the write. It is never supplied by the device, so a record cannot be backdated by adjusting a phone’s clock. When work is captured offline, the client-claimed capture time is stored alongside, clearly labeled as what it is, and shown next to the server time in the record and in exports. It is displayed, never substituted: the authoritative time is always the server’s, and the gap between the two is visible rather than hidden.
Attribution, at the moment of the tap
Every item in a check names the individual who answered it, captured when that item was tapped, not when the form was submitted. One signature never covers a whole checklist. The record also stores how that person proved who they were: a personal signed-in session, or a PIN entered at a shared station. Both are recorded and both print on exports, because the strength of the attribution is part of what a record is worth, and the record should state it rather than imply a stronger one.
Exports carry the proof with them
A PDF is trivially editable, so a Telure export never asks for trust in the file alone. The moment an export is generated, it is registered: a document ID is printed on its cover, and the SHA-256 digest of the exact bytes of the file is recorded under that ID in a registry that rejects updates and deletes for every role, Telure’s included.
Anyone handed the PDF, an underwriter, a broker, counsel, can verify it independently at floorkept.com/verify, no account needed. Drop the file on the page and it is hashed in the browser, never uploaded; or compute the digest yourself and paste it with the document ID. A match confirms Telure produced that exact file and it has not been altered since. A single changed byte fails the match.
The sample is a real export from our fictional demo facility, registered like any other. Drop it on the verify page and watch it pass, then change one character with any PDF editor and watch it fail.
What this proves, and what it does not
Tamper evidence proves
- That a record has not been altered, reordered, or removed since the moment it was written.
- That each record was written at the server time it states, attributed to the named individual, by the stated authentication method.
- That an exported document is the exact file the system generated, byte for byte.
Tamper evidence does not prove
- That the person who wrote a record observed truthfully, or observed at all.
- That the work described was done competently, or that anything is safe.
- That a facility complies with any standard or regulation.
The design still changes what a false record costs. Without tamper evidence, the easy lie is retroactive: a log edited into shape after an incident, in private, with time to make it consistent. Telure removes that option. Here, fabrication has to happen in real time, under a named identity, at a server timestamp, entry by entry, before anyone knows which records will ever be examined. That is a far harder lie to construct and a far harder one to maintain. And where work simply was not done, the record shows a gap: exports report periods with no recorded activity explicitly rather than smoothing them over.
Telure records what qualified staff observed and when. It does not perform inspections, certify equipment, or determine that anything is safe. If you underwrite movement facilities, the insurers page covers what a Telure record gives you in practice.