The checksum: a change fingerprint, not a tamper seal

Every Thing's coreMetaData carries a checksum: a SHA-256 hash over the record's @type, elementId, most recent modified.timeStamp, and live value, concatenated as strings. This page defines what that fingerprint is for, what it is not for, and where to look when you need more than it offers.

What the checksum is

The checksum is a lightweight change fingerprint. Two copies of a record with matching checksums are the same revision. A changed checksum means the record was modified, deprecated, or revived since you last saw it.

That's useful precisely where HTTP can't help you: records that live outside a request context. Exports sitting on disk. Records replicated into your own database. Snapshots cited in an audit workpaper six months ago. Compare the stored checksum against the live one and you know whether your copy is stale, without diffing the records field by field.

Computing it is one line in any language: SHA-256 over the concatenation, e.g. "Group" + "12" + "2021-07-28T18:53:23.000000Z" + "true". Booleans are hashed as the strings "true" and "false".

What the checksum is not

It is not tamper-evidence. The hash covers four bookkeeping fields, not the record's content, and it's computed from values that travel in the same response with no key or signature involved. Anyone who alters a record can recompute a valid checksum in the same line of code you'd use to verify one. Treat a checksum mismatch as "my copy is out of date," never as proof of integrity, and treat a checksum match as nothing more than "same revision."

For conditional requests, use ETags

If what you want is "only send me this if it changed" or "only apply my update if nobody else got there first," don't build it on the checksum. HTTP solved this: ETag response headers with If-None-Match for cache validation, and If-Match with 412 Precondition Failed for optimistic concurrency. APIs serving GRCSchema data are expected to support conditional requests, and consumers should prefer them over any body-level comparison whenever a live API is on the other end.

Roadmap: signed proofs for sold and published mappings

What the checksum honestly can't do (prove a record hasn't been altered) has a current standard: W3C Verifiable Credential Data Integrity proofs, which canonicalize a JSON-LD document, hash it, and sign it (e.g. the eddsa-rdfc-2022 cryptosuite, a W3C Recommendation). A consumer can verify a signed record offline, without trusting the channel it arrived through.

That is the documented direction for content that gets sold or formally published: mapping exports, vocabulary releases, anything an auditor might rely on. It is roadmap, not receipt. No GRCSchema surface ships Data Integrity proofs today, and this page will say so plainly until one does. When that proposal is ready it will arrive here, in Proposed Properties, on its own page.