Source contracts
A source contract declares which ontology fields a given provider is allowed to emit. Where a
plugin's mapping spec says how a provider's data maps to
the ontology, a source contract bounds what it may assert. Together they make multi-source
behaviour predictable and auditable. The contracts live in src/source_contracts/.
Why contracts exist
When several providers contribute to one entity, you need to reason about who can say what. Source contracts make that explicit:
- They constrain a provider to its legitimate fields (a web-scraping OSINT source shouldn't be treated as authoritative for a registry number).
- They underpin the multi-source disagreement and missing-data enforcement of ADR-017: if a source is contracted to provide a field and doesn't, that absence is itself meaningful.
- They make Atlas's aggregator posture safe: a third-party data or list vendor — including one whose platform competes with Atlas — can be ingested purely as a bounded source that asserts only the fields its contract permits (a sanctions/PEP list vendor screens; it does not get to set a registry number). See aggregator vs provider.
Relationship to mapping specs and the registry
At boot the TranslationRegistry combines plugin mapping specs, source contracts, and the active ontology into the index that governs how incoming provider data becomes claims.
API surface
The source-contracts router exposes the definitions and adapters:
| Endpoint | Purpose |
|---|---|
GET /definitions | List source-field definitions |
update /definitions/… | Adjust which fields a source may emit |
GET /adapters | List source adapters |
These are configuration surfaces typically managed by compliance engineers; routine analysts do not touch them.
Related reference data
Source contracts work alongside the reference-data registry
(ADR-008a, src/reference_data/), which holds
versioned datasets (compliance lists, thresholds) that rules and matrices consult. See
Reference → Reference data.