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:b5f3b055-abb5-4dbe-8a6b-745b2fa49455
claim_key:facility.09002f.star_rating.2026q2
metric:star_rating
value:3 rating_1_5
valid_from:2026-06-04T16:50:27.482+00:00
valid_to:— (current)
recorded_at:2026-06-04T16:50:31.286726+00:00
Source
name:CMS Hospital General Information 2026-04-28
publisher:Centers for Medicare & Medicaid Services
The claim above has valid_from = 2026-06-04 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=facility.09002f.star_rating.2026q2&as_of=2026-06-04