> For the complete documentation index, see [llms.txt](https://standards.spdci.org/standards/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://standards.spdci.org/standards/dci/profiling-dci-standards.md). # Profiling DCI Standards DCI standards are designed to be modular and adaptable, allowing countries, organizations, and solution providers to tailor implementations to their specific needs while maintaining interoperability. DCI provides a **profiling mechanism** that allows implementers to specialize existing DCI standards for specific contexts, such as countries, programmes, sectors, or implementation scenarios. A profile does not change the semantic meaning of the underlying DCI standard. Instead, it defines additional constraints, implementation rules, and usage guidance while remaining compatible with the core standard. *** ## When to Create a Profile A **profile** should be created when an implementation follows an existing DCI standard but needs to: * Make optional fields mandatory. * Restrict allowed values. * Define supported API operations. * Specify implementation-specific validation rules. * Define a subset of the standard for a specific use case. * Provide additional implementation guidance. Examples include: * Country-specific Social Registry profile. * Humanitarian Registry profile. * Employment Programme profile. * National CRVS implementation profile. A profile should always reuse the existing DCI semantic model and only introduce constraints or specialization needed for the implementation context. *** ## Profiling Data Models DCI data standards are based on **JSON-LD**, enabling semantic interoperability and controlled specialization. A data profile may: * Define mandatory and optional properties. * Restrict property cardinality. * Limit accepted code values. * Specify validation constraints. * Provide usage guidance for specific implementation scenarios. The underlying DCI JSON-LD model remains unchanged, allowing different implementations to exchange information using a shared semantic foundation. *** ## Profiling APIs API profiles allow implementers to specialize DCI APIs according to implementation requirements while preserving interoperability. An API profile may define: * Supported API operations. * Required parameters or headers. * Authentication and authorization requirements. * Validation rules. * Implementation-specific workflows. * Usage constraints for specific programmes or countries. API profiles should continue following DCI API principles, including versioning, security, and message structure. *** ## Handling Additional Requirements When implementation needs go beyond the current DCI standards, implementers should first evaluate whether the requirement can be addressed through a profile. An issue can be raised to be discussed with DCI team If a requirement introduces completely new concepts or functionality not covered by existing DCI standards, it should be discussed with the DCI community to determine whether it should become: * a future enhancement to an existing standard, * a new DCI standard, * or a separate implementation-specific solution. Avoid creating independent profiles that duplicate or conflict with existing DCI concepts, as this can reduce interoperability. *** ## GitHub Repository Structure Profiles are maintained alongside the core standards within the DCI GitHub repositories. **Data profiles** [`schemas/profiles/`](https://github.com/spdci/schemas/tree/main/profiles) Contain implementation-specific JSON-LD profiles and related documentation for specialized data models. **API profiles** [`api-standards/profiles/`](https://github.com/spdci/api-standards/tree/draft/profiles) Contain specialized OpenAPI specifications, documentation, and implementation guidance for API profiles. *** ## Best Practices When creating profiles: * Reuse existing DCI data objects and API definitions. * Avoid redefining existing concepts. * Maintain compatibility with the core DCI standards. * Contribute reusable profiles back to the DCI community through GitHub. Following these principles allows implementers to address local requirements while preserving interoperability across social protection digital ecosystems. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://standards.spdci.org/standards/dci/profiling-dci-standards.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.