REST API
Query released public-record surfaces across healthcare, procurement, sanctions, and enforcement, with source and capture context where the underlying collection provides it.
Open REST API→The capabilities
Eight capabilities, one graph
MCP server
A Model Context Protocol server an AI agent can call directly, with the same released public-record surface structured for tool use.
Open MCP server→FHIR R4 API
Five provider resource types — Practitioner, Organization, Location, PractitionerRole, and HealthcareService — with the available provenance metadata supplied by each response.
Open FHIR R4 API→Bulk export
A machine-readable manifest lists the files currently published in a tested download format. It currently includes a gzip CSV for the CMS Provider of Services facility directory.
Open Bulk export→Attestation & audit pack
Stored snapshot-attestation metadata where a concrete snapshot id exists. Provenance facts do not currently link deterministically to that signature ledger.
Open Attestation & audit pack→Reconciliation
Supported source-versus-source diffs show where two federal records disagree on the same entity and include snapshot references when the compared records supply them.
Open Reconciliation→Entity graph
Providers, organizations, and facilities linked across NPI, CCN, PECOS-ID, and other identifiers where the source supplies a matchable key; ambiguous links remain qualified.
Open Entity graph→Snapshots
Source-specific retained versions after tracking began. Closed rows currently exist for UK sanctions, procurement awards, OFAC, UN sanctions, and a small set of provenance claims; other sources may have no replayable prior row.
Open Snapshots→How it fits together
One pipeline, from federal record to callable fact
The capabilities above are stages of a single pipeline. Facts admitted through the field-provenance path retain their source-row relationship; other response shapes expose only the source and observation fields available to that surface.
- Ingest — public records are observed on a per-source cadence; source-file SHA-256 values are recorded where present.
- Reconcile — records with matchable identifiers can be linked across NPI, CCN, PECOS-ID, and chain identifiers.
- Attest — snapshot-level records can carry an Ed25519 signature. This ledger is separate from claim-level provenance and its historical chain coverage is not universal.
- Serve — REST, MCP, FHIR R4, and supported exports expose available provenance; as-of reads depend on retained history for the named source.
Platform FAQ
Common questions
- What does the Fonteum platform actually expose?
- One public-records graph spanning healthcare, federal procurement, sanctions and watchlists, federal enforcement, and global open-data company registers. The active production registry is not a claim that every family has loaded, complete, fresh, or displayable records. Released capabilities include a REST API, an MCP server for AI agents, an HL7 FHIR R4 interface, and manifest-listed bulk downloads.
- What fields can the provenance schema carry?
- The schema defines up to 14 provenance fields, including source, dates, method, coverage, license, and integrity references. Fields can be null or absent by source and surface. As of July 12, no provenance fact had a deterministic link to a signed snapshot.
- How do point-in-time snapshots and bitemporal reads work?
- As-of reads can return a retained version only after Fonteum began tracking that source. Production closed-row history currently exists for UK sanctions, procurement awards, OFAC, UN sanctions, and a small provenance-claim set; EU sanctions had none on July 12.
- Can an AI agent call the platform directly?
- Yes. The MCP server lets an agent resolve supported entities, screen against exclusion and sanctions lists, and retrieve source context without a human in the loop. The same public product is also described through machine-readable discovery documents.
- Is the platform data free to read?
- Public pages and designated public-data routes can be read without a paywall. Availability, authentication, rate limits, and export support are route-specific and should be checked against the current API response and documentation.
- What proves the data has not been altered after the fact?
- Internal Ed25519 signatures can be checked for the attestation rows that carry them. Attestation and chain coverage can change independently of the fact ledger. The July 12 production audit found no deterministic claim-to-attestation or claim-to-witness-signature links.
BUILD ON THE PLATFORM
Resolve, screen, and inspect available attestations on public federal data.
Start against the REST API or drop the MCP server into an agent. Request access for higher limits, supported bulk exports, and available snapshot-attestation artifacts.