What a data source governs
- Provenance — Every record, relationship, and object references its originating source so you can audit lineage and route updates back to the right system of record.
- Synchronization flow — The source declares how data arrives (currently API push) and which environments or jobs publish into it.
- Processing boundary — Validation, ingestion pipelines, and access controls execute independently per source, allowing teams to tune quality gates without affecting other domains.
Configuration essentials
A data source definition consists of a unique key, metadata, and the profiles it owns. Keep keys stable because they appear in API paths, identifiers, and audit logs.key— URL-safe identifier referenced across registry APIs and partitions. Must follow this pattern:^[a-zA-Z0-9-][\w-]{0,61}$type— Categorizes how data is managed. Useregistryfor resources written directly to the Clinia registry.
The Clinia platform only supports
registry sources at this time.Operating data sources
- One source per schema — When upstream systems expose different schemas or lifecycle rules, create dedicated sources. This keeps validation strict and provenance clear.
- Coordinate schema changes — Version profiles before pushing breaking changes so ingestion never fails unexpectedly.
- Secure access — Tie API keys and IAM roles to specific sources to prevent accidental cross-domain writes.
- Monitor freshness — Track ingestion timestamps to surface sources that stopped publishing data.
Related references
- List the data sources API for the canonical schema and endpoints.
- Data ingestion overview to understand how sources feed the registry.
Keep exploring
Profiles
Learn how schemas define which properties each source can store.
Relationships
See how sources describe graph connections between their profiles.
Data model overview
Connect source configuration to the broader Clinia data model.