Source and observation metadata, with the gaps stated.
Fonteum's platform snapshot records facts. A direct table count on July 12 returned rows. Of those, carried a valid-shaped SHA-256 from their provenance-source row and 14 did not. The ledger had 71 provenance-source records, 68 of which bore claims. Deterministic fact-to-attestation and fact-to-witness-signature linkage was zero.
What the source mark can contain
A provenance-aware response can expose the named source, observation date, source-file digest, limitation, and a snapshot id when those fields exist. Availability varies by source and surface. Clients must inspect the returned object rather than assume every field is present.
{
"provenance": {
"source": "CMS NPPES NPI Registry",
"observed_at": "2026-07-12T09:53:02Z",
"content_sha256": "<64-character source-file digest when present>",
"snapshot_id": "<present only when the response supplies one>"
},
"claim_signature_linked": false
}What it does not mean
- A source-file hash is not a signature on a fact.
- An internal snapshot attestation does not establish claim-level linkage.
- A source record does not establish that a provider is licensed, qualified, or in good standing.
- As-of reads cover only retained history after Fonteum began tracking the named source.
- None of the 162 stored OpenTimestamps proof records passed the July 12 independent mainnet audit.
Inspect a supplied snapshot id
When a response includes a concrete snapshot id,https://fonteum.com/verify/<id>can display the stored snapshot metadata. Its output applies to that snapshot object, not automatically to every field or fact that names the same source.