Every claim links back to its government source file — verify the SHA-256 hash yourself
Bitemporal history & attestation chain
Every fact Fonteum publishes traces to a specific government file with a known SHA-256. The chain below shows how: a claim records when the source asserted it (valid-time) and when we recorded it (system-time). Anyone can re-download the source file and confirm the hash — no login required.
How the chain works
1
Claim — A fact about a facility or provider (e.g. star rating at CCN 460057). Has valid_from, valid_to, and recorded_at columns (bitemporal).
2
Source — The exact government CSV fetched at a specific date. Fonteum stores the SHA-256 of the raw file so you can re-download and confirm it.
3
Snapshot + witness — An aggregate snapshot of the ingest is signed with an Ed25519 key (methodology: in-toto-witness/v1). The signed payload contains the SHA-256 of the snapshot contents.
Bitemporal columns
Column
Axis
Meaning
valid_from
Valid-time start
When the source asserted this fact became true
valid_to
Valid-time end
When the fact stopped being true; null = still current
recorded_at
System-time
When Fonteum first wrote this row to the database
Backfill note: valid_from ← asserted_at; recorded_at ← created_at. No valid-time was fabricated.
Worked example — real claim
Claim
id:e717a8b9-8bd9-4a5e-b30f-475f6c690a62
claim_key:provider.1518918770.years_active.202602
metric:years_active
value:19 years
valid_from:2026-06-10T08:06:24.368249+00:00
valid_to:— (current)
recorded_at:2026-06-10T08:06:24.368249+00:00
Source
name:NPPES NPI Registry (individuals) 202602
publisher:Centers for Medicare & Medicaid Services
retrieved:
Check any claim
Paste a provenance_claims UUID to see its attestation chain.
Methodology
Witness signature algorithm
Ed25519 (Node.js crypto module)
Canonical payload format
{"methodology_version":"...","sha256":"...","signed_at":"...","snapshot_id":...} — Keys always sorted alphabetically for determinism.
Methodology version pinned
in-toto-witness/v1
Source hash
SHA-256 of the raw downloaded file, stored in provenance_sources.content_sha256
The claim above has valid_from = 2026-06-10 and valid_to = null (current). When CMS releases updated data and a new claim supersedes this one, valid_to will be set and the diff will show the change.
# Point-in-time query
GET /api/attest/pit?claim_key=provider.1518918770.years_active.202602&as_of=2026-06-10