Properties

Property Type Definition
Administrative
Record identifier string
A unique identifier for this record (e.g., a ULID, UUID, or program-assigned ID). Scoped to the record's namespace; not necessarily globally unique.
Identifiers concept:Identifier
Identifiers carried by this entity, such as national ID numbers, program IDs, or identifiers asserted by an identity document.
Name string
The full display name of the record. Depending on the concept, this is a person's or group's name, or the title of a program, instrument, scoring rule, or software product.
Version string
The version identifier of an artefact such as an instrument, software agent, scoring rule, or privacy notice (for example, a release date such as 2022-10-11 or a semantic version like 6.2).
Schema version uri
Identifies the version of the PublicSchema (or other) consent record schema this instance conforms to. Enables forward migration tooling. Typically a dereferenceable URI, for example 'https://publicschema.org/ConsentRecord/v1'.
Conforms to uri
URIs of standards or specifications this record conforms to (ISO/IEC TS 27560, Kantara Consent Receipt, W3C DPV, etc.). Purely declarative; no validation is performed against the cited standards at schema level.
Created at datetime
System-generated timestamp marking when this record was persisted. This is the digitisation timestamp, not the consent-giving date. Distinct from 'signed_date' (the day the data subject indicated consent) and 'effective_date' (when the record becomes operative). For paper-first workflows the three timestamps may all differ.
Controllers concept:Organization
Organizations determining the purposes and means of processing. Cardinality multiple covers joint controllership (two or more organizations jointly responsible under GDPR Art 26 or equivalent national provisions); the normative case is one controller. See 'recipient_role' to distinguish processors from controllers among recipients.
DPO contact string
Contact details (email, phone, postal) for the data protection officer or equivalent privacy-contact role of the controller(s). Free-form string; typically an email address or a postal block. Required by GDPR Arts 13/14 for notices issued in EU jurisdictions.
Complaint authority contact string
Contact details for the relevant data protection authority where the data subject can lodge a complaint (e.g., in EU jurisdictions, the national DPA). Required by GDPR Arts 13/14 for notices in EU jurisdictions.
Recipient categories string (organization-type)
Categories of recipients described to the data subject in the notice. PrivacyNotice-scoped: the notice describes categories; the ConsentRecord names specific recipients via 'recipients' and 'allowed_recipient_categories'.
Recipients described string
Free-prose description of recipients used in the notice, complementing the coded 'recipient_categories'. Enables the notice to describe a recipient that does not fit the coded vocabulary.
Processing purposes uri
Values are W3C DPV URIs, normatively subclasses of `dpv:Purpose` (e.g., `dpv:ServiceProvision`, `dpv:ResearchAndDevelopment`). Each URI identifies a purpose for which personal data is processed under this record. See `docs/dpv-vocabulary-reference.md` for a curated starter list.
Personal data categories uri
Values are W3C DPV URIs, normatively subclasses of `dpv:PersonalData` (from the DPV core; the DPV-PD extension defines finer taxa). Cross-reference: this is distinct from biometric capture method, which is `consent_expression = opt-in-biometric` on this record. Biometric data categories are values of this property (e.g., a URI for fingerprint, face image).
Processing operations uri
Values are W3C DPV URIs, normatively subclasses of `dpv:Processing` (e.g., `dpv:Collect`, `dpv:Store`, `dpv:Share`). Describes the operations being consented to. Cross-reference GDPR Art 4(2) for the definition of 'processing'.
Special category basis string (special-category-basis)
When `personal_data_categories` includes a special category (GDPR Art 9 / `dpv:SpecialCategoryPersonalData`), this property identifies the Art 9(2) basis that authorizes processing. Required when Art 9 data is in scope; omitted otherwise. Field-critical: populate even if your UI does not require it.
Supersedes concept:PrivacyNotice
PrivacyNotice-only. The prior notice version that this notice replaces. Enables tracing the notice evolution chain. A re-consent campaign is triggered by a substantive change (new purposes, new recipients, new data categories); a version bump without these changes does not require re-consent. See `docs/consent-lifecycle.md` for the distinction.
Available languages string (language)
PrivacyNotice-only. ISO 639-3 codes of all languages in which this notice is available. See `notice_presentation_language` on the ConsentRecord for which one was actually presented to a given data subject.
Transfer description string
PrivacyNotice-only. Prose description of international or third-country data transfers (GDPR Chapter V). Free-form; should name destination countries, adequacy decision status, and safeguards (standard contractual clauses, binding corporate rules, etc.) where applicable.
Automated decision description string
PrivacyNotice-only. Prose description of any automated decision-making, including profiling, that produces legal effects or similarly significant effects on the data subject (GDPR Art 22). Include the logic involved, the significance, and the envisaged consequences. Empty when no such processing occurs.
Rights description string
PrivacyNotice-only. Prose description of the data subject's rights (access, rectification, erasure, objection, portability, restriction of processing, withdrawal of consent). Typically a paragraph covering the full rights bundle under the relevant jurisdiction.
Source of data string
PrivacyNotice-only. Prose description of the source(s) from which personal data is obtained when not collected directly from the data subject (GDPR Art 14). Example: 'A government beneficiary registry maintained by the Ministry of Social Protection.'
Effective date date
The date on which this record or notice becomes operative. On a ConsentRecord, it may be later than signed_date (the day the data subject indicated consent) and later than created_at (the digitisation timestamp); for paper workflows, signed_date is the day of the paper signature and effective_date is typically the same day but may be delayed by program logic. On a PrivacyNotice, it is the date from which this notice version applies; records collected before this date reference the superseded version via supersedes_ref.
Expiry date date The date on which this record or document expires or becomes invalid.
Jurisdiction string (country)
ISO 3166-1 alpha-2 country code of the jurisdiction whose data protection law governs this record. Cardinality single: multi-jurisdictional records are the rare case; a follow-on ADR will lift cardinality if adopters hit it. Under joint controllership, this is the lead controller's primary establishment jurisdiction.
Withdrawal description string
PrivacyNotice-only. Prose description of how the data subject can withdraw consent. Should reference withdrawal_uri if available, and describe any paper or verbal channels. Required by GDPR Art 7(3).
Retention description string
PrivacyNotice-only. Prose description of the retention period for personal data (GDPR Art 13(2)(a)). Use when the period cannot be expressed as a fixed number of days (for example, 'for the duration of program enrollment plus six years after program exit').
Storage duration (days) integer
Planned storage duration for the personal data covered by this record, expressed in days. Drives retention logic in downstream systems. Zero means: do not persist after processing. Null (unpopulated) means: duration is described in prose in the PrivacyNotice retention_description rather than coded.

Evidence

Present in 2 of 6 mapped delivery systems.

PrivacyNotice as a first-class artefact is less widespread than ConsentRecord. ISO/IEC 29184 specifies notice structure; W3C DPV models it as dpv:PrivacyNotice. Most delivery systems handle notice text as prose in program documentation rather than as a structured record. This concept exists so adopters can version notices alongside records, trace re-consent triggers, and generate jurisdiction-aware notice text from structured inputs.

Standard Equivalent Match
W3C DPV v2 Privacy Notice exact
W3C DPV 2.0 defines dpv:PrivacyNotice as a notice of privacy practices. When legal_basis includes consent, the notice is also a dpv:ConsentNotice (same class, narrower role).
dpv:ConsentNotice is the consent-focused specialisation of dpv:PrivacyNotice. Our PrivacyNotice is the supertype; records with legal_basis = consent are anchored against notices that also satisfy the ConsentNotice specialisation.

Referenced by this concept