Diversity ID (Diamond Code)
References
Section titled “References”Linear issues:
- TEP-470: Spec: Diversity ID (uniqueId) feature — engineering spec, source of truth for behaviour
- TEP-471: API: ContributeUser field, generation, contributor mutations and comms — API implementation
- TEP-472: Client: display Diamond Code on survey thank-you and profile (CDN only) — client display surfaces
- TEP-473: Client: accept Diamond Code in contributor add, edit and upload flows (CDN only) — client input surfaces
- D2D-8: Design: diversity ID — original product / customer messaging
Source decisions:
- Simone @ CDN’s three-problem framing (per D2D-8 comment thread) — email instability, agent-email substitution, and contributor anonymity / control
- The validation-rules matrix agreed in TEP-470 — governs which identifier wins when a row carries both, and which combinations are rejected
- CDN-only tenant scope — every UI surface is gated to the CDN tenant; no other tenant sees a Diamond Code anywhere
Overview
Section titled “Overview”What it is
Section titled “What it is”The Diamond Code (a.k.a. Diversity ID) is a stable, opaque, 10-character, human-friendly code stored as uniqueId on each ContributeUser. CDN contributors can give it to a production company instead of their email when they’re being added to a project. The code never changes — it is generated once on a contributor’s first survey submission and stays the same for the life of the account.
Tenant scope
Section titled “Tenant scope”All UI surfaces — both contributor-facing display and production-company-facing input — are enabled for CDN only. Other tenants see no Diamond Code anywhere: no thank-you screen surfacing, no profile field, no Add Contributor input, no Excel column, no in-row edit. This is the single most important constraint for anyone reading this doc; every behaviour below is scoped to CDN.
Why it exists
Section titled “Why it exists”The Diamond Code addresses three problems Simone @ CDN raised in the original design discussion (D2D-8):
- Email instability — contributors’ emails change a lot as they move between projects, agents and creative strands. An opaque code is a stable identifier that survives those changes.
- Agent-email substitution — agents currently hand their own email to production companies in place of their client’s. The code lets the contributor provide a project-level identifier without exposing their personal email, removing the agent’s incentive to substitute.
- Anonymity and control — contributors want to feel they have more anonymity and more control over their data. The code is the lever for that: shareable, revocable in practice (by simply not sharing it again), and decoupled from any other personal identifier.
How a contributor uses it
Section titled “How a contributor uses it”- The code is generated automatically the first time the contributor submits any survey — there is no opt-in, no separate enrolment step, and no setting to toggle.
- It is surfaced on the survey thank-you screen after every submission, not just the first — so a contributor who didn’t note it down the first time still sees it later.
- It is surfaced on the profile MeTab with a copy button, so a contributor can retrieve it any time without re-doing a survey.
- Contributors share it with a production company as an alternative to email when they’re being added to a project.
- The code is stable — re-submitting the survey never regenerates it, and there is no way for the contributor to request a new one.
How a production company uses it
Section titled “How a production company uses it”Production companies encounter the Diamond Code in three places, all on the CDN tenant:
- Add Contributor (single-row modal) — a “Diamond Code” field next to email. Exactly one of email or Diamond Code must be provided. Agents (rows with
isAgent = true) cannot use a Diamond Code. - Excel bulk upload — a recognised “Diamond Code” column, matched by keyword on the column-mapping step. Each row needs at least one of email or Diamond Code; if both are provided the API silently prefers email.
- In-row edit on the project contributors table — same rules as the Add modal: exactly one of email or Diamond Code, and not allowed for agent rows.
Validation matrix
Section titled “Validation matrix”The combinations below govern what the system does for each row, in both bulk upload and single-row flows:
| Combination on row | Bulk upload | Single-row (Add / edit) |
|---|---|---|
email only | Use email | Use email |
uniqueId only | Use uniqueId | Use uniqueId |
Both email and uniqueId | Use email; ignore uniqueId. No error. | Reject with a row-level error |
| Neither | Reject with a row-level error | Reject with a row-level error |
isAgent: true AND uniqueId set | Reject with a row-level error | Reject with a row-level error |
uniqueId does not resolve to an existing contributor | Reject with a row-level error | Reject with a row-level error |
The asymmetry between bulk upload and single-row is deliberate: Excel uploads are sloppy in practice, so silently preferring email avoids hostile upload failures over a soft conflict; single-row UIs have a user actively in front of the form and can be expected to choose one identifier.
Behaviour notes worth surfacing for support
Section titled “Behaviour notes worth surfacing for support”- A typo’d Diamond Code on upload fails immediately at mutation time, not at project approval — the production company gets feedback the moment they upload, so they can ask the contributor to re-share the correct code before they walk away from the screen.
- Changing a row’s identifier (email or Diamond Code) on an existing contributor row breaks the link to the previously-resolved contributor. The next invite re-runs identity matching from scratch, against the new identifier.
- Re-uploading the same Diamond Code on a later upload updates the existing row rather than creating a duplicate — the code is the identity key, so the same code on two uploads is treated as the same contributor.
- The Diamond Code lookup is mutation-time (a synchronous existence check) — distinct from the email-based linking that happens at project approval. This is why a wrong code fails immediately but a stale email might only surface as a problem later in the project lifecycle.
What’s not supported
Section titled “What’s not supported”These cases are explicit non-goals — support can give a definitive “no” without escalating:
- Agent rows cannot use a Diamond Code — agents are represented as their own contributor type and must be added by email.
- Merging contributor records across email and uniqueId for the same person — if a contributor is added once by email and once by Diamond Code, the system treats them as two separate identities. There is no merge tool.
- Bulk admin tools to manage Diamond Codes — there is no admin UI to view, search or filter contributors by code.
- Regenerating or revoking a code — codes are permanent once generated. A contributor cannot request a new one, and there is no admin override.
- Backfill of codes for existing contributors who haven’t re-engaged with the survey — codes are generated lazily on next survey submission. A contributor who has never submitted a survey since the feature shipped has no code yet; they will get one the next time they touch the survey.