| 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. |
| External ID | string | Identifiers assigned by external systems (CRM, case management, etc.). Multiple allowed because a record may carry identifiers from several systems. |
| Consent record type | string (consent-record-type) | Whether this record is an internal storage record or an externally-issued consent receipt. Internal records are the controller's working state; receipts are artefacts delivered to the data subject. |
| 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. |
| Collection session reference | string | Opaque correlation key for records produced in the same intake session. A 'CollectionSession' concept is planned in ADR-013 and will formalize this; in v1 adopters use a free-form session id (e.g., a field-visit id). |
| Parties |
| Data subject | concept:Party includes Person, Group, Household, Family, Farm | The natural person (or occasionally group) whose personal data is being processed under this record. Party is the abstract supertype covering Person and Group. Farm is excluded: farms are not natural persons or legal beneficiaries under any data protection law. When 'data_subject' is a Group, 'delegation_type' must not be 'self'. |
| 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. |
| Recipients | concept:Organization | Organizations that receive the data or its derivatives. Includes processors, joint controllers, and independent controllers. See the parallel property 'recipient_role' for the role of each recipient. |
| Recipient role | string (recipient-role) | The role each recipient plays: processor, joint-controller, independent-controller, or sub-processor. Known limitation: v1 uses positional alignment with 'recipients' (the Nth recipient_role value corresponds to the Nth recipient). A future ADR will reify per-link roles. Adopters that cannot guarantee positional alignment should use only one recipient and one role per record, or represent the relationship externally. |
| Allowed recipient categories | string (organization-type) | Categories of organizations permitted to receive the data, as described to the data subject in the notice. Complements 'recipients', which names specific organizations. Use when specific recipient organizations are not pre-identified at the time of consent. |
| Indicated by | concept:Agent includes Person, Organization, SoftwareAgent | The agent (usually a Person, sometimes a SoftwareAgent) who indicated the consent act. For self-consent, the same Person as 'data_subject'. For delegated consent, a legal guardian, parent, or representative. See 'delegation_type' to describe the delegation basis. |
| Delegation type | string (delegation-type) | The basis under which 'indicated_by' acts on behalf of 'data_subject'. The value 'self' indicates no delegation: the data subject indicated their own consent. All other values indicate that a third party acted on the data subject's behalf. |
| Witnessed by | concept:Person | Persons who witnessed the data subject's indication of consent. Field-critical for verbal consent ('collection_medium = verbal') and for biometric-as-signature ('consent_expression = opt-in-biometric') and witnessed signatures ('consent_expression = opt-in-witnessed'); adopters should populate this field even when the data-entry UI does not require it. |
| Processing |
| 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'. |
| Legal basis | string (legal-basis) | The legal basis under GDPR Art 6(1) (or equivalent law) authorizing the processing. Cardinality multiple because a single record may rely on more than one basis; normative usage on a ConsentRecord is one basis. On a PrivacyNotice, multiple bases may coexist if the notice covers multiple processing operations. Field-critical: populate even if your UI does not require it. |
| 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. |
| Legal basis reference | string | Jurisdiction-specific legal reference (e.g., a national act, article, or case citation) supporting `legal_basis`. Free-form string; use per-jurisdiction norms. Example: 'Ley 1581 de 2012, Art 6(a)' in Colombia. |
| Joint controller arrangement | string | Reference to the joint-controllership arrangement between the parties listed in `controllers` (GDPR Art 26). Typically a URI to a published arrangement; a local identifier is acceptable if URI is not applicable. Populated when cardinality of `controllers` is greater than one. |
| Notice |
| Privacy notice | concept:PrivacyNotice | The PrivacyNotice record that was presented to the data subject at the time of consent. Anchors the record to a specific notice version. |
| Notice version | string | Denormalized snapshot of the PrivacyNotice `version` at the time of consent. Pinned by design: if the PrivacyNotice is later corrected or reversioned, this value MUST NOT be updated. Enables demonstrating which notice text the data subject actually saw (GDPR Art 7(1) demonstrability). |
| Notice presentation language | string (language) | The ISO 639-3 language code in which the notice was presented to the data subject at the time of consent. Field-critical: populate even if the UI does not require it. When the notice is available in multiple languages (see PrivacyNotice `available_languages`), this records which one the data subject actually saw. For witnessed verbal consent, this records the language of the verbal delivery. |
| Validity and jurisdiction |
| 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. |
| Signed date | date | The day the data subject indicated consent. For paper workflows, the day the paper form was signed; for witnessed verbal, the day of the verbal indication; for digital, the day of the click-through. MUST NOT be confused with created_at (the digitisation timestamp, which may be days or weeks later in paper-first programs) or effective_date (when the record becomes operative). Field-critical: populate even if the UI only captures created_at. |
| 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. |
| Collection evidence |
| Collection medium | string (collection-medium) | The medium through which consent was collected: paper, electronic, verbal, or mixed. Paper is the dominant medium in humanitarian and rural social-protection programs; electronic systems that ignore paper workflows exclude real practice. Field-critical: populate even if the system defaults to assuming electronic. |
| Consent expression | string (consent-expression) | The form in which consent was expressed: explicit opt-in, signed opt-in, witnessed opt-in, biometric opt-in, opt-out, or implied. IMPORTANT cross-reference: opt-in-biometric refers to the capture method (for example, fingerprint as signature), not to the data category. Processing biometric data is expressed via personal_data_categories (a URI from dpv-pd or equivalent). |
| Evidence reference | string | References to the evidence artefact(s) backing this record. Values are typically URIs (for example, a signed object-store URL) but a local identifier is acceptable when a URI is not applicable. Artefact types include: PDF scans of signed paper forms, photographs of consent records, audio recordings of witnessed verbal consent, and signed digital documents. At least one evidence_ref is strongly recommended for collection_medium in {paper, verbal, mixed}. Field-critical: capture even when the artefact URI is only available after upload. |
| Verified by | concept:Person | Person who verified the consent record (for example, a case worker reviewing a scanned paper form, or an auditor confirming a sample of records). Distinct from witnessed_by (who observed the consent act) and from indicated_by (who expressed the consent). Optional but valuable for auditable workflows. |
| Verification date | date | Date of the verification act performed by verified_by. Typically after signed_date. |
| Status and withdrawal |
| Status | string (consent-status) | The current lifecycle state of the record: requested, given, renewed, refused, withdrawn, revoked, expired, invalidated, or unknown. Transitions follow the state machine documented in docs/consent-lifecycle.md. given triggers the immutability of terms-fields (data_subject, controllers, recipients, purposes, etc.); see the per-property immutable_after_status annotation. |
| Withdrawal channel | string (withdrawal-channel) | The channel through which the data subject withdrew consent: web, mobile, api, paper, verbal, in-person-office, community-worker, or other. Recorded when status transitions to withdrawn. Field-critical: adopters should record the channel even when the withdrawal arrives through a non-digital path. |
| Withdrawal URI | uri | URI exposed to the data subject for self-service withdrawal of consent. Required by GDPR Art 7(3) ('it shall be as easy to withdraw as to give consent'). Populated on the ConsentRecord when the controller offers a self-service endpoint. |
| Withdrawal reason | string | Free-form reason for withdrawal, if disclosed by the data subject. The data subject is not required to give a reason; this field exists for when they do, for the controller's service-improvement purposes. |
| Refusal reason | string | Free-form reason for refusal when the data subject declined to consent (status = refused). Distinct from withdrawal_reason, which applies after consent was initially given and later withdrawn. |
| Retention |
| 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. |