Every clause cites a section, and every citation is checked

Why an uncited policy is a document rather than a control

A privacy policy has two audiences and they want different things. A reader wants to know what happens to their data. An auditor wants to know which obligation each paragraph discharges — and a policy that reads beautifully but cannot be mapped to the Act is, from that second point of view, an essay.

The practical consequence shows up when the law moves. When a Rule is amended, the question is which of your thirty-odd documents contain a clause that depended on the old wording. If every clause carries the section it was written against, that is a query. If it does not, it is a manual re-read of everything you have ever published.

What the model is given before it writes a word

Three things, in this order. A structured quick-reference to the Act — sections one to forty-four and Rules one to twenty-two, as bullets rather than full text, because the full text would consume the budget the document needs. Your organisation context: legal name, corporate identity number, entity type, registered state and address, operating cities, website, and the named data protection and grievance officers with their contact details. And the answers from the policy-input questionnaire that describe what your business actually does with data.

The organisation profile has a minimum set below which generation is not useful: legal name, identity number, registered state, and a data protection officer with a contact address. A policy that names no entity and gives no contact fails the notice obligation it was written to satisfy.

There is also a guard against the demonstration data. The seeded sample organisation used for demos is recognised and ignored, so a tenant who never completed their profile gets an incomplete document rather than a confident policy about a fictional healthcare company.

What comes back, per section

The model does not return prose. It returns a structure, and each section within it carries four things beyond the text itself: a stable section identifier so translations and later edits stay aligned, a one-sentence rationale for why the section says what it says, the list of questionnaire answer keys the content was derived from, and the regulation citations.

The answer-key list is the one people underestimate. It is what lets you answer "where did this retention period come from" with a reference to the question somebody in your organisation answered, rather than a shrug. When the answer changes, you know which clauses were built on it.

The citation whitelist, and what it throws out

Every citation the model produces is checked against a list of permitted forms after generation, not trusted on the way out. A reference is accepted if it is a section of the Act between one and forty-four, in any of the recognised written forms, or a Rule between one and twenty-two, or one of a small set of named external standards and instruments that a DPDP policy legitimately cites.

Anything outside that list is flagged rather than published. That catches the specific failure mode these models have: a citation that is perfectly formatted, plausibly numbered and does not exist. A reader cannot tell the difference between a real section reference and an invented one without looking it up, which is exactly why the check has to be mechanical.

• Accepted: sections §1 to §44 of the Act, written as §n, DPDP §n, DPDP Act 2023 §n or Section n.
• Accepted: Rules 1 to 22, written as Rule n, DPDP Rule n or DPDP Rules 2025 Rule n.
• Accepted: a short list of external instruments a DPDP policy genuinely references — the information security and privacy management standards, the Information Technology Act and its security practices rules, and the constitutional privacy position.
• Rejected: anything else, including §45, a GDPR article, or a Rule number the Rules do not go up to.

The rule against inventing your cookie list

The second hallucination class is more dangerous than a bad citation, because it is harder to spot. Asked to write a cookie section, a model will happily produce a plausible list of analytics providers, advertising pixels and software development kits — none of which it has any way of knowing you use.

That list is not merely wrong. Published, it is a statement to your data principals about processing that may not happen, and an admission about processing you may not have consent for. So the generator is explicitly barred from naming cookies, trackers, pixels or SDKs it has not been told about, and writes a bracketed placeholder instead.

A placeholder in a draft is an obvious piece of work to finish. An invented vendor list in a published policy is a finding. The scanner is the honest way to fill those placeholders, because it reports the trackers actually firing on your site rather than the ones somebody remembers adding.

The shape every document takes

Documents are not free-form. Each opens with an introduction and a scope section, carries a policy-specific middle band, and closes with definitions, a policy overview and a roles-and-responsibilities section. The result runs to roughly eight sections and eight to fifteen pages.

Two constraints inside that are worth knowing because they are what stop a generated document reading like generated text. Each section has to carry two or three subheadings rather than being a wall, and sits in a word band wide enough to say something and narrow enough not to ramble. And the definitions section has to be a three-column table — term, definition, and the regulatory reference the definition comes from — which is a small formatting rule that quietly forces every defined term to be traceable.

Each policy type also has a required-sections list that overrides whatever the model thought the document should contain. A missing required section is a deterministic high-severity finding rather than a matter of judgement.

Gap analysis reads what you already have

Separately from generation, an existing document — including one you wrote years ago and uploaded — can be analysed against the Act. Findings come back with a severity, a category, a short title, a summary, the provision it relates to, and a suggested rewrite of the offending passage.

The categories are the ones that actually recur: notice, consent, purpose, retention, security, breach, rights, grievance, processor, transfer, accountability, children, government access, accuracy, transparency and lawful basis. Findings are capped and sorted by severity, because a report with two hundred items is a report nobody works through.

There is a drift check alongside it that compares a published document against the current state of your configuration — which is how a retention clause that was accurate when it was signed off gets flagged once somebody changes the underlying retention rule.

What this does not replace

It does not replace counsel. The citation check verifies that a reference is to a provision that exists; it cannot verify that the provision supports the sentence it is attached to. That is a reading of the law, and reading the law is a lawyer's job.

It does not decide your lawful basis. Whether a particular processing activity runs on consent or on a legitimate use under §7 is a decision about your business, and the generator writes up the decision rather than making it.

And a generated policy is a draft until somebody signs it. Approval takes a typed attestation name, an effective date and a review interval, and records the approver and the address the attestation came from — because a policy nobody approved is a document, and the whole point of the exercise was to stop producing documents.