Legal source method

OpenDPDP treats legal content as versioned operational configuration. A proposition is publishable only when a reviewer can identify the instrument, authority, provision, publication date, effective date, direct URL, access date, status and uncertainty.

Source hierarchy

1. Gazette of India, India Code and the issuing ministry or regulator;
2. official consolidated instruments, circulars, FAQs and technical directions;
3. courts and tribunals for a decision’s actual holding and current procedural status;
4. official standards documentation for technical contracts;
5. secondary commentary only for discovery, interpretation or competing views.

A search result, conference slide, vendor blog or AI answer is never the authority for a legal proposition.

Status vocabulary

Label	Meaning
DPDP — binding	enacted/notified legal text; pair it with commencement status
DPDP — in force	the cited provision has commenced and has not been superseded
DPDP — not yet effective	enacted/notified but scheduled for a future commencement
Sector regulation	applies only if the entity/activity falls within the regulator’s scope
Contractual	arises from agreement, scheme participation or customer instruction
Recommended control	risk/control practice, not represented as law
Design choice	deliberate product or architecture decision
Assumption	conservative input to be replaced with evidence
Open legal question	disputed, dependent or not verified

“Binding” and “in force” are not synonyms. An enacted provision may await commencement; an official policy may govern programme participation without being a generally applicable statute.

Research record

Each source has a stable SRC-* ID in src/data/source-register.yaml. Each obligation/status has a LEG-* ID in src/data/legal-status.yaml. A status record carries:

• exact provision and dates;
• affected entities and operative obligation;
• mapped CTRL-* product controls;
• evidence artefacts;
• direct URL and access date;
• confidence and notes.

The control map is many-to-many. One breach event may touch DPDP, CERT-In, RBI, SEBI, a customer contract and an insurer’s procedure; the system must preserve each legal test rather than replace them with one generic “72-hour” clock.

Change procedure

1. Capture the primary instrument and checksum outside the production application.
2. Compare the amended/corrected text with the current source.
3. Create or update the source and legal-status records.
4. Identify every mapped control, sector pack, template, API default and test.
5. Record an interpretation note and unresolved questions.
6. Obtain legal reviewer approval.
7. publish a signed legal configuration version with an activation date;
8. require customer acceptance where configuration or process changes materially.

No customer workflow changes merely because a crawler found a page.

Confidence

• High — direct official instrument, exact provision and effective date verified.
• Medium — official source verified, but applicability, amendments or implementation sequence needs entity-specific review.
• Low — source or operative effect is incomplete; do not use for automatic configuration.

Staleness

DPDP core status is reviewed at least monthly until 13 May 2027 and after any MeitY/Board publication. Sector content uses a 90-day maximum by default and faster monitoring where a regulator is actively changing a framework. A stale page remains visible with a warning; it is never silently presented as current.

Interpretation guardrails

• Do not import GDPR “legitimate interests”; use consent or an exact section 7 specified legitimate use.
• Do not invent a general portability right.
• Do not treat all processors as directly equivalent to Data Fiduciaries.
• Do not turn an erasure request into immediate destruction where another law requires retention.
• Do not treat voluntary Aadhaar approval as mandatory identity verification.
• Do not call ordinary consent tooling a registered Consent Manager.