> ## Documentation Index > Fetch the complete documentation index at: https://docs.clinia.com/llms.txt > Use this file to discover all available pages before exploring further. # Data Sources > Understand how sources organize resources and relationships before they enter the registry Clinia data sources are the administrative boundary for everything you ingest into the registry. They capture where a record originates, which schemas it must respect, and how upstream systems are allowed to mutate it. Every workspace can declare multiple sources to mirror each operational system of record you need to consolidate. ## Source fundamentals Each source is both a contract and a container: * **Contract** — Sources reference the [profiles](/explanation/data-model/profiles-relationships) and relationship definitions that data must respect. They define which data types, validation rules, and vocabularies are allowed. * **Container** — Sources persist the raw resources and relationships exactly as they were ingested, including source-specific metadata needed for traceability. * **Processing boundary** — Pipelines, processors, and validation rules execute per source so that each system can keep autonomous data quality guardrails. Because all write APIs target a specific source, the registry always tracks provenance and can trace which upstream system produced a given record. ## Resources A resource is a record stored under a source that conforms to the profile defined by its collection. Resources include: * **Data** — Properties defined by the associated profile, including nested object and array structures. * **Meta** — System-managed attributes such as identifiers, timestamps, and ingestion receipts. * **Contained resources** — Optional embedded structures declared by the profile. They are versioned together with the parent resource and never queried independently. Resources are one of the units you search, filter, and surface to downstream applications through partitions. ## Relationships Relationships capture graph structure between resources: * **Definition** — A relationship definition declares allowed `from`/`to` resource types and the properties carried on each edge. * **Instances** — Each stored relationship references two resource identifiers, its key (the relationship type), optional data payload, and metadata. * **Traversal** — Partitions can traverse relationships so that related properties become available for querying without denormalizing data. Use relationships to express ownership, participation, service availability, or any link that drives navigational queries across datasets. ## Ingesting data into a source Decide how much coordination each integration requires, then pick the ingestion workflow that matches: * For batched workloads, use the [bulk resource and relationship APIs](/guides/managing-data/tasks#bulk-resources) so that operations run asynchronously and can retry individual failures. * When you need atomic guarantees across multiple operations, rely on [bundle requests](/guides/managing-data/tasks#bundle-operations). * For low-volume or highly targeted writes, the [single resource APIs](/api-reference/resources/create-a-resource-in-the-registry) and [relationship APIs](/api-reference/relationships/create-a-relationship-between-two-resources-in-the-registry) provide synchronous confirmations. Each ingestion option ultimately writes into the same source boundary, so you can mix strategies per integration without fragmenting your registry. Understand how to define your data models Learn how to ingest resources or relationships in bulk Learn how to group multiple writes in a single transaction