EVIDENCE ARTEFACTS
- Versioned decision record
- Named ownership and approval
- Implementation or test evidence
CONSENT-01v1.0
CONTROL RECORD · REVIEWED 2026-08-30
Affirmative-action capture
Make affirmative-action capture an inspectable system decision with a named owner, defined trigger and retrievable evidence.
Engineering control
Catalogue status
not legal status
RECORD ANATOMY
What this control needs to be reviewable.
- Objective
- Make affirmative-action capture an inspectable system decision with a named owner, defined trigger and retrievable evidence.
- Rationale
- Design affirmative choices, receipts and withdrawal propagation as inspectable system events.
- Owner model
- Choice-experience owner · Identity or platform owner · Evidence reviewer
- Review frequency
- Before release, after integration change and through periodic sampling
- Architecture layer
- Choice and consent evidence
- Version
- 1.0 · 2026-08-30
IMPLEMENTATION SEQUENCE
Move from scope to retrievable evidence.
- 01
Scope the decision: define the decision, owner, trigger, evidence and review path before implementation.
- 02
Record the approved design and its source-status verification boundary.
- 03
Connect implementation events to evidence that a reviewer can retrieve without broad production access.
CONTROL TEST
- Select a recent, in-scope sample for affirmative-action capture and record why it was chosen.
- Trace the sample from its trigger and owner through the implemented system to the retained evidence.
- Record exceptions, confidence and remediation without converting an unknown into a pass.
ANTI-PATTERNS
Completion labels can hide an evidence gap.
- Treating “affirmative-action capture” as a policy sentence without an operating owner
- Marking the control complete from self-attestation alone
- Hiding missing, stale or inaccessible evidence behind a pass label
ARCHITECTURE → EVIDENCE DECISION JOURNEY
Follow the dependency, then inspect the proof.
Each connection uses existing catalogue records. Source IDs remain verification pointers—not provision mappings.
Add to a review route- Control pathwayCONSENT-01: Affirmative-action capture
- 01 · PrerequisiteChoice and consent evidence
Confirm the choice and consent evidence decision and owner boundary first.
Engineering indicator · not a legal requirement · Verification pointers: dpdp-act-2023 - 02 · Implementation patternConsent event and withdrawal propagation
Treat consent and withdrawal as versioned events that downstream systems must acknowledge.
Engineering indicator · not a legal requirement · Verification pointers: dpdp-act-2023, dpdp-rules-2025, act-commencement-2025 - 03 · Validation / testSelect a recent, in-scope sample for affirmative-action capture and record why it was chosen.
Trace the sample from its trigger and owner through the implemented system to the retained evidence. Record exceptions, confidence and remediation without converting an unknown into a pass.
Engineering indicator · not a legal requirement · Verification pointers: dpdp-act-2023 - 04 · Evidence artefactVersioned decision record
Named ownership and approval · Implementation or test evidence
Engineering indicator · not a legal requirement · Verification pointers: dpdp-act-2023 - 05 · Failure modeTreating “affirmative-action capture” as a policy sentence without an operating owner
Marking the control complete from self-attestation alone · Hiding missing, stale or inaccessible evidence behind a pass label
Engineering indicator · not a legal requirement · Verification pointers: dpdp-act-2023 - 06 · Research noteConsent Managers as infrastructure: interfaces, accountability and open questions
Interoperability, receipt semantics, revocation reliability and minimised identity binding deserve design attention before integration claims are made. Radar context: Structured consent receipts is Adopt.
Editorial analysis · reviewed 2026-08-30 · sources dpdp-rules-2025, rules-landing-2025 - 07 · Specialist propertyComparative analysis
Compare framework concepts without treating a comparison as legal advice. This route remains optional if the destination is unavailable.
Contextual external property · no affiliation or availability implied
- 01 · PrerequisiteChoice and consent evidence
Open semantic relationship table (1pathway)
| Record | Phase | Relationship | Status / boundary | Source pointers |
|---|---|---|---|---|
| CONSENT-01: Affirmative-action capture | 01 · Prerequisite | Choice and consent evidence Confirm the choice and consent evidence decision and owner boundary first. | Engineering indicator · not a legal requirement · Verification pointers: dpdp-act-2023 | dpdp-act-2023 |
| CONSENT-01: Affirmative-action capture | 02 · Implementation pattern | Consent event and withdrawal propagation Treat consent and withdrawal as versioned events that downstream systems must acknowledge. | Engineering indicator · not a legal requirement · Verification pointers: dpdp-act-2023, dpdp-rules-2025, act-commencement-2025 | dpdp-act-2023 · dpdp-rules-2025 · act-commencement-2025 |
| CONSENT-01: Affirmative-action capture | 03 · Validation / test | Select a recent, in-scope sample for affirmative-action capture and record why it was chosen. Trace the sample from its trigger and owner through the implemented system to the retained evidence. Record exceptions, confidence and remediation without converting an unknown into a pass. | Engineering indicator · not a legal requirement · Verification pointers: dpdp-act-2023 | dpdp-act-2023 |
| CONSENT-01: Affirmative-action capture | 04 · Evidence artefact | Versioned decision record Named ownership and approval · Implementation or test evidence | Engineering indicator · not a legal requirement · Verification pointers: dpdp-act-2023 | dpdp-act-2023 |
| CONSENT-01: Affirmative-action capture | 05 · Failure mode | Treating “affirmative-action capture” as a policy sentence without an operating owner Marking the control complete from self-attestation alone · Hiding missing, stale or inaccessible evidence behind a pass label | Engineering indicator · not a legal requirement · Verification pointers: dpdp-act-2023 | dpdp-act-2023 |
| CONSENT-01: Affirmative-action capture | 06 · Research note | Consent Managers as infrastructure: interfaces, accountability and open questions Interoperability, receipt semantics, revocation reliability and minimised identity binding deserve design attention before integration claims are made. Radar context: Structured consent receipts is Adopt. | Editorial analysis · reviewed 2026-08-30 · sources dpdp-rules-2025, rules-landing-2025 | dpdp-rules-2025 · rules-landing-2025 |
| CONSENT-01: Affirmative-action capture | 07 · Specialist property | Comparative analysis Compare framework concepts without treating a comparison as legal advice. This route remains optional if the destination is unavailable. | Contextual external property · no affiliation or availability implied | None · contextual external route |
VERIFY BEFORE MAPPING
GENERIC VERIFICATION POINTER · NOT A PROVISION MAPPING
dpdp-act-2023
Provision-specific applicability must be verified against the primary-text ledger.
Boundary: Operational control pattern; not a standalone legal conclusion.
Open the source ledgerCONNECTED SYSTEM PATTERN
Consent event and withdrawal propagation
Treat consent and withdrawal as versioned events that downstream systems must acknowledge.
LOCAL WORKSPACE NOTE
Give this work a next owner.
Nothing is sent anywhere. Avoid names, personal data or confidential incident details.
CHANGE LOG
Version 1.3 — Architecture-to-evidence journey and non-personal review-route relationship added; verification-pointer boundary retained.
Version 1.2 — Official-source status rechecked; command-centre indexing and the non-mapping boundary retained.
Version 1.1 — Engineering fields, source verification pointers and acceptance evidence reviewed.
Version 1.0 — Stable catalogue ID, objective, evidence model, test sequence and verification boundary established.