_How records produced by GDC toolkits work, why they are trustworthy, and how to verify one yourself. Written for compliance officers, inspectors, and auditors. No familiarity with the underlying system is assumed._
A GDC toolkit produces records that are content-addressed, cryptographically sealed, tamper-evident, and independently verifiable. You do not have to trust the operator, the device, or the vendor. You verify the record itself, with standard cryptography, on your own equipment. A record that has been altered will fail verification, and the failure points to exactly which entry changed.
Each time an operator completes a step — logging a lot, recording a measurement, making a determination — the toolkit emits an evidence record. A record contains the data of that step plus two cryptographic fields:
Because each record embeds the fingerprint of its predecessor, the records form a chain. The chain is sealed by a single root hash (a Merkle root) computed over all of them. This is the same construction used in established audit and ledger systems.
A SHA-256 hash changes completely if even one character of the input changes. So:
its contents — verification fails at that record.
record's previous-hash link no longer matches — the break simply moves down the chain.
the root that was sealed and recorded at the time of filing.
There is no way to change a past entry without changing the root, and the root is fixed at the moment the chain is sealed. Tampering is not prevented — it is made evident.
The toolkits are deterministic: the same inputs always produce the same record and the same hashes, on any device, every time. This matters for an auditor because it means a record is not a claim that has to be taken on faith — it is a computation you can re-run. Given the same inputs, you will compute the same hashes the operator did. If your independently computed root matches the filed root, the record set is intact.
You need only a standard SHA-256 tool (built into common command-line environments and every major programming language). No GDC software is required.
1. Obtain the record set. The operator exports the chain as a file (each record with its data, content hash, and previous-hash link, plus the sealed root). 2. Check each content hash. For each record, compute SHA-256 over its canonical contents and confirm it equals the stored content hash. 3. Check the links. Confirm each record's previous-hash field equals the prior record's content hash. The first record links to a defined genesis value. 4. Check the root. Recompute the Merkle root over the record hashes and confirm it equals the sealed root that was filed.
If all four checks pass, the record set has not been altered since it was sealed. If any check fails, the position of the failure identifies the affected record.
Beyond the chain, each record set is validated against formal invariants before it is considered complete. An auditor can request these results:
missing-but-required fields, no malformed numbers.
record set cannot "lose" evidence; the sequence is monotone by construction.
pH reading within 0–14). Out-of-range values are flagged.
hash. A record set that cannot be reproduced is rejected.
These are checks on the record set, not assertions by the vendor. They either hold or they don't, and the result is part of what you can verify.
It establishes that a record set is internally consistent, has not been altered since sealing, was produced by a deterministic process, and satisfies its declared constraints. It establishes integrity and provenance.
It does not establish that the original measurement was taken honestly or correctly — no record system can certify the physical act of measurement. What it does is remove every opportunity to quietly revise the record afterward. The integrity of the entry is guaranteed from the moment of sealing forward; the integrity of the measurement remains, as always, a matter of inspection and operator accountability.
The toolkits are designed for operators who work offline, on modest devices, often far from connectivity — and for the regulators who must nonetheless trust their records. By making each record verify itself with standard cryptography, the system removes the need to trust the device, the network, or the vendor. The record stands on its own. That is the intent: compliance evidence that an auditor can check directly, that an operator cannot silently alter, and that no third party has to vouch for.
_Questions an auditor may reasonably ask — the export format, the canonicalization rule used before hashing, and the genesis value — are documented with each deployed toolkit and can be provided on request. The hashing is standard SHA-256 (FIPS 180-4); no proprietary cryptography is used._