UN OCHA FTS · source contract

Methodology & coverage

This workspace reorganises public Financial Tracking Service records into an inspectable donor → recipient agency → destination ledger. It preserves uncertainty and provenance; it does not turn reported flows into a claim about money ultimately spent.

Inspect the coverage ledger Explore reported flows

The completeness claim has a precise public boundary

The flow ledger covers every membership returned by /v1/public/fts/flow?year= for every supported boundary from 1992 through 2100. This captures future-dated public flows and explicit checked-zero years. Pagination follows the source-provided next link and reconciles the final row count to the FTS expected count before any year is published.

The reference layer also retrieves and validates:

  • /v2/public/location and every documented recursive location detail;
  • /v1/public/organization;
  • /v2/public/plan and every plan detail requested with content=entities;
  • /v1/public/global-cluster.

“Complete” therefore means complete within those public FTS funding and reference endpoints. It excludes private, administrative and unrelated non-funding API surfaces.

Boundaries and statuses describe source records

Incoming
A reported flow crosses into the selected year or entity boundary.
Outgoing
A reported flow crosses out of the selected boundary.
Internal
Source and destination remain within the selected boundary.
Status
Paid, commitment, pledge and other labels are reported by FTS. They do not all mean final expenditure or delivery.

Boundary, status, contribution type, flow type and object behaviour are source-owned values and source-owned values remain open. New non-empty FTS labels are retained rather than forced into a finite MarketImpact list.

One amount, explicit dimension states

FTS may attach more than one organisation, location, plan or sector to a flow. Every ordered source link is retained, but canonical totals count each flow version once, without multiplying the monetary amount.

Multiple
Several reported objects exist for that dimension; none is selected arbitrarily.
Unspecified
No object was supplied for that dimension in the reported flow.
Unresolved
A supplied identity could not be linked to the current canonical reference register.

These buckets remain visible in comparisons and filters. They are evidence states, not organisations or countries.

Current views do not erase revisions

A flow ID can have several versions and can appear in more than one usage-year boundary. Versions, parent/child links, objects, reports and raw payloads remain linked by enforced keys. The flow master points to the latest known version.

Explorer, directory and detail totals use the declared uniqueFlowsLatestRevision basis: within the selected year or year range, each stable flow ID contributes once at its latest qualifying revision. Year-membership rows remain visible in provenance, but they do not multiply cross-year totals. Official FTS boundary aggregates remain separately labelled and are not recomputed under this rule.

Year views use the exact immutable membership set from the latest completed import run for that year. Earlier completed and retried run memberships remain available for audit; a failed run cannot replace a healthy current snapshot.

The coverage API and ledger use these evidence fields:

Source expected
The total membership count declared by FTS for that year.
Source fetched
The membership rows actually received and decoded across every source page.
Stored memberships
The immutable import-run membership rows tied to that year's selected completed run.
Expected − stored
Zero is exact equality; positive is missing storage and negative is unexpected excess.
Checksum
A deterministic SHA-256 fingerprint of the decoded source evidence for that year.
Latest completion
The commit time of the selected completed import run, not merely its start time.
Latest check
The most recent source revalidation attempt, tracked separately from the latest successful import.
Reference snapshot
Complete only when every current catalog detail is cached and the atomic reference graph has been published.
Oldest detail fetch
The oldest source fetch represented in the currently published detail graph.
Compare source and stored counts by year →

Typed fields remain connected to source evidence

Raw source payloads are retained for flow versions, objects, reports and memberships alongside useful typed fields. Unknown future fields therefore remain available even before a new interface exposes them.

Flow explorerFilter and inspect exact rows Recipient agenciesFollow receiving roles and counterparties CountriesTrace canonical destinations and exceptions PlansCompare requirements and reported plan-linked flows

Update cadence and publication gates

  • The daily current-year refresh uses the same validated importer as the historical operator backfill.
  • A daily rolling sweep revalidates four non-current or future boundaries in oldest-check order, keeping the complete 1992–2100 range inside a 35-day freshness SLA.
  • Reference collections refresh daily in bounded 32-document slices, keeping an unchanged full rotation inside 45 days; changed catalog owners are refreshed first. A durable operator sync can rebuild the full public reference graph.
  • The historical and future 1992–2100 boundary probe runs once after release and resumes only after a diagnosed failure. Each year publishes in its own transaction.
  • A year is labelled complete only when source expected, source fetched and immutable stored current-run memberships match exactly.

Source: UN OCHA Financial Tracking Service. MarketImpact reorganises and labels the public evidence; it does not alter source records.