Discloser Profiles
Discloser Profiles is CDP’s internal service for keeping a consistent view of organisations and places. It helps teams answer basic but important questions: who is this discloser, where are they, what boundary represents them, which other entities are they connected to, and which groups or lists do they belong in?
The source repository is /Users/andrew/Documents/GitHub/cdp-discloser-profille-service.
General Context
| Area | Summary |
|---|---|
| Source repo | CDPworldwide/cdp-discloser-profille-service |
| Current role | Internal data service for discloser identity, geography, boundaries, lists, and relationships. |
| Live service | https://discloser-profile-service-pbybuiwoxq-uc.a.run.app/docs |
| Main inputs | CDP CRM records, Overture Maps geography, GERS identifiers, country data, and boundary geometry. |
| Main users | CDP product and data teams that need a reliable way to identify and group disclosers. |
Why It Exists
CDP works with many kinds of disclosers: companies, cities, regions, public authorities, and other organisations. Those records need to be connected to real-world geography and kept consistent across products. Without a shared profile layer, each product can end up using slightly different names, identifiers, boundaries, or hierarchy assumptions.
Discloser Profiles is the shared layer that makes those records easier to trust and reuse.
What It Helps With
| Need | How Discloser Profiles helps |
|---|---|
| Identifying a discloser | Connects CDP records to stable organisation and place identifiers. |
| Showing location context | Links records to countries, regions, cities, and other geographic areas. |
| Using boundaries | Provides boundary data where available, so maps and analysis can use a consistent shape. |
| Building lists | Supports managed groups of entities for reporting, review, or product workflows. |
| Understanding relationships | Tracks parent-child links, such as regions containing cities or CDP-specific hierarchy relationships. |
| Checking coverage | Makes it easier to see where profile, identifier, or boundary data is missing. |
Current Coverage
The source service currently documents 52 countries ingested from CRM workbooks, 7,357 Overture geography records, 6,788 CRM entity records, and 6,865 records with available geometry. Profile records can exist even when boundary geometry is still missing, so coverage should be treated as an ongoing data quality area rather than a finished product state.
Disclosure Interoperability
Discloser Profiles could also become the identity anchor for a broader disclosure-interoperability layer: connecting discloser identity, uploaded evidence, reusable datapoints, standards mappings, and AI-assisted suggested responses.
This is documented as separate project pages so the sidebar can expose the setup clearly:
| Page | What it covers |
|---|---|
| Interoperability opportunity | Strategic rationale, product thesis, why this matters for CDP, and how Discloser Profiles fits. |
| Datapoint model | Suggested governed datapoint shape, profile responsibilities, review states, and reuse boundaries. |
| Suggestion service | Expected retrieval behavior, guardrails, relationship to Briink, and how mapped datapoints should support draft responses. |
| Prototype and questions | Narrow first prototype scope, unresolved ownership questions, and possible Baker Street work package. |
Important Boundaries
- The service is best understood as an internal data backbone, not a public product experience.
- CRM account keys, geographic identifiers, and boundary records are related but not interchangeable.
- A profile record does not always mean a usable boundary is available.
- Hierarchy data can come from spatial relationships or CDP-specific relationships, so products need to be clear about which source they rely on.
- The current source repository name is still
cdp-discloser-profille-service, including the existing spelling. - Discloser Profiles should not be treated as a compliance engine by itself; standards alignment, suggested responses, and formal disclosure claims need expert validation and human review.
- A mapped datapoint should not be reused across entities, reporting years, subsidiaries, or jurisdictions unless the profile, boundary, source, and permission context supports that reuse.
Open Questions
- Which CDP products should treat Discloser Profiles as the canonical source for organisation and place identity?
- What refresh process should govern CRM updates, geographic data updates, and boundary coverage?
- Which hierarchy source should each product prefer when CDP relationships and spatial relationships differ?
- Should the user-facing language be “Discloser Profiles”, “Discloser Profile Service”, or something simpler?
- Should Discloser Profiles become the identity anchor for reusable disclosure datapoints, or should datapoints live in a separate service that only references profile IDs?
- What minimum profile coverage is required before a datapoint can safely be suggested for reuse?
- Which CDP, Briink, or internal suggestion-service components should own extraction, retrieval, review state, and response drafting?