Skip to main content
Profiles are the contracts that govern every resource stored under a data source. They define which properties exist, how values are validated, and which contained structures travel with each record. Each ingested resource must reference a profile key, making profiles essential for data quality and interoperability.
If the data should be queryable on its own, model it as a separate collection linked via relationships. Use contained components for embedded structures that only exist within a parent record and are never queried independently.

​
Anatomy of a profile

A profile describes its type, properties, optional contained components, and any validation rules. The example below highlights common patterns.
  • properties — List each attribute and its data type. Use validation rules to enforce required fields, ranges, enums, or vocabulary bindings.
  • contained — Declare embedded components with their properties and cardinality.
  • description — Document the business meaning so stewards understand how the schema should evolve.

​
Designing robust profiles

  • Validate early — Use rules and vocabularies to fail fast when data violates expectations. This keeps ingestion clean and downstream reconciliation easier.
  • Plan for evolution — Introduce new optional properties before deprecating old ones. Coordinate schema updates with upstream producers to prevent ingestion failures.
  • Document relationships — Capture how profiles connect using relationship definitions so downstream consumers understand the graph.

​
Keep exploring

Data sources

Understand how profiles attach to the systems that publish data.

Relationships

Learn how profiles connect to form the registry graph.

MDM partitions

See how unified views consume profile-defined schemas downstream.