dpia-generator

KO | EN

gitlite — search

#svg #data-science #react #java #http #go #kotlin #android #ai-agent #kubernetes

(★ 9)

DPIA Generator: Claude Skill that drafts GDPR Article 35 DPIAs for review. Not legal advice

File Explorer

ZIP Download

- - test.yml
- eval-prompts.md
- open-datasets-integration-plan.md
- - australia-privacy.md
  - brazil-lgpd.md
  - canada-quebec.md
  - china-pipl.md
  - india-dpdp.md
  - indonesia-pdp.md
  - kenya-dpa.md
  - malaysia-pdpa.md
  - screening-catalog.md
  - singapore-pdpa.md
  - south-korea-pipa.md
  - switzerland-fadp.md
  - uk-gdpr.md
  - us-california.md
  - us-colorado.md
  - us-other-states.md
  - vietnam-pdpl.md
- authorities.md
- legal-framework.md
- notice-profile.md
- output-template.md
- published-dpias.md
- risk-matrix.md
- build_dpia.js
- run_regression.js
- - art36-conditional-mismatch.json
  - art36-conditional.json
  - art36-missing.json
  - art36-negative.json
  - art36-positive.json
  - bad-calendar-date.json
  - bad-date.json
  - block-null-entry.json
  - blocks-not-array.json
  - bullet-null-item.json
  - compliancemap-bad-section.json
  - conclusion-gate.json
  - conclusions-contradiction-regime.json
  - conclusions-missing-regime.json
  - escaping.json
  - footnote-three-regimes.json
  - header-suppressed.json
  - headertext-null.json
  - jurisdictions-proto.json
  - jurisdictions-unknown.json
  - kenya-derivable.json
  - manifest-not-object.json
  - matrix-no-source.json
  - matrix-proto-source.json
  - mitigated-rating-orphan.json
  - narrative-contradiction.json
  - narrative-no-false-positive.json
  - non-gdpr-regime.json
  - nonderivable-missing-conclusion.json
  - notice-check-bad-verdict.json
  - notice-check-missing-action.json
  - notice-check-null-row.json
  - notice-check-stale.json
  - notice-check.json
  - outputdir-escape.json
  - para-missing-text.json
  - rating-gate.json
  - register-null-row.json
  - regulator-conclusions-explicit.json
  - regulator-table-missing-conclusion.json
  - reviewer-posture-attorney.json
  - reviewer-posture-dpo.json
  - status-custom.json
  - status-mismatch.json
  - status-vocabulary.json
  - table-null-row.json
  - traversal-dotdot.json
  - traversal.json
  - unknown-block.json
.gitignore
LICENSE
package-lock.json
package.json
README.md
SKILL.md

# Use via CDN

jsDelivr

jsDelivr serves any public GitHub repository as a CDN with zero setup. Pick a version and a file to get a ready-to-paste link and snippet.

Version

File

Link

Example

# Project Badges

tests Visit

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

A Claude Skill that drafts a Data Protection Impact Assessment under Article 35 GDPR (and its analogs in other covered jurisdictions) for a client's privacy register.

Given a description of a new or modified processing activity, the Skill gathers what is missing, maps the applicable regimes, and screens each regime's own trigger. Coverage is EU/UK GDPR plus one module per further jurisdiction in `references/jurisdictions/` — currently the US states, Quebec, Brazil, China, India, Switzerland, Singapore, Malaysia, Indonesia, Vietnam, Australia, South Korea, and Kenya; that directory is the authoritative list. The analysis is anchored in real published DPIAs and regulator guidance (ICO, CNIL, EDPB, CPPA, ANPD, and peers), and risks are scored on a 3×3 likelihood × severity matrix. The deliverable is a reasoned Word document: cover page, executive summary, necessity/proportionality analysis, controls inventory, residual ratings, mitigations, per-regime regulator-engagement flags (Article 36 prior consultation and its analogs), and a Jurisdictional Divergence section wherever a covered regime changes the answer. Regimes without a module are named as not covered rather than silently absorbed.

# Important

Every output from this Skill is a draft for human review — by counsel where one is in the loop, by the Data Protection Officer otherwise — not legal advice, not a legal conclusion, not a substitute for a lawyer. This Skill may make review faster; it does not replace it.

This Skill does not represent the creator's legal positions: it is a tool. Where a Skill includes a checklist item, a suggested framework, a risk flag, or a characterization of case law or regulatory guidance, that is an aid to the reviewing attorney's own analysis, not a statement of the author's view of the law. The law in many of these areas is unsettled and evolving. The attorney using the Skill — not the Skill, and not the author — is responsible for the legal positions taken in their work product.

## What it does

- **Intake first (Article 35(7)).** The Skill does not draft until it has a workable processing description — system and purpose, categories of personal data and data subjects, recipients and sub-processors, retention, cross-border transfers, automated decision-making, AI/ML involvement (including vendor-side training), and jurisdictional scope. Missing material facts are named as open questions rather than invented.
- **Triggering screen (Article 35(1)/(3)).** A fast screen against the statutory triggers and the WP29 nine-criteria framework states explicitly whether the DPIA is mandatory or a voluntary accountability artifact.
- **Reconciles with prior work.** Before writing, it checks for a prior DPIA on the same processing, vendor, or data flow and reconciles conclusions in the cover note — with a severity-floor rule so a prior High residual rating cannot silently drop to Low without a documented reason.
- **Notice profile — provide once, reuse every run.** "Index our privacy notice" extracts the controller's published notice into a portable YAML profile the user keeps (verbatim commitments with pinpoints, provenance, a check-by date) — indexed category-complete against a fixed commitment-type vocabulary aligned with the OPP-115 annotation scheme, with silence recorded as data so re-indexing an unchanged notice reproduces the profile; a load-bearing vendor's DPA or policy can be indexed the same way, pinned to a version date. Later DPIA runs load the profile to pre-fill intake, ground the Art. 13/14 transparency analysis, and drive the §1.10 policy-drift check — rendered by the builder with colour-coded verdicts, where a drift or conflict row with no committed resolution fails the build rather than shipping as a bare red cell.
- **Anchors in a real analog.** It pulls a published DPIA or DPA decision close to the functional classification of the processing and weaves its reasoning in, marking any departures — a defensibility step, not optional.
- **Sources are tagged.** Every citation carries a source-attribution tag (e.g., `[regulator site]` vs. `verify`) so the reviewing attorney can check the higher-fabrication-risk citations first.
- **Risk analysis.** Inherent and residual risk are scored on a 3×3 likelihood × severity matrix (severity from the data subject's perspective, likelihood from threat-actor capability and asset vulnerability), with a controls inventory and the inherent → residual transition shown.
- **The matrix is computed, not asserted.** The bundled builder derives every rating from the published matrix and plots both grids from the same source, so the register table, the matrices, and the Article 36 flag cannot disagree. Where a stated rating contradicts the derived one, the build hard-fails rather than emitting a document — a mis-stated residual rating is the defect most likely to survive review into a filed DPIA.
- **Consequential-step gates.** The Skill flags Article 36 prior consultation when residual risk warrants it, checks whether the document is leaving the privilege circle (offering privileged and sanitized versions), and confirms before producing a "ready-to-file" version — but does not file with any authority on the user's behalf.
- **Consultation duties are noted, not simulated.** Article 35(2) DPO advice and the Article 35(9) data-subject consultation are flagged where they apply, with a note wherever the Skill has substituted its own analysis and a recommendation to confirm.

## Requirements

- Runs inside the Claude Skills environment with `conversation_search`, `web_search`, and `web_fetch` available (prior-work reconciliation and live citation verification).
- `node` with the `docx` npm package for the Word deliverable; OOXML validation via the public `docx` skill where installed (see Testing).

## Usage

Invoke the Skill with any new-processing privacy question:

- "Run a DPIA on [system/vendor/feature]."
- "We're launching [X] — is this Article 35 / high risk?"
- "Assess the privacy risk of this data flow / cross-border transfer."
- "Index our privacy notice" — builds the reusable notice profile (no DPIA); attach the profile on later runs.

The Skill asks (in one message) only for the intake details it's missing, runs the screen and the prior-work check, pulls a reference analog, and returns the DPIA `.docx` with a chat summary covering the triggering conclusion, the analog used, the top residual risks, whether Article 36 consultation is recommended, open questions to resolve before finalizing, and any UK/EU divergence that changes the result.

## Outputs

- **`DPIA_<SystemName>_<date>.docx`** — the full DPIA draft: cover page (with triggering conclusion and any documented assumptions), executive summary, necessity/proportionality analysis, risk matrix, controls inventory, residual ratings and mitigations, Article 36 flag (required / not required / conditional on the Section 5 mitigations), and a defined review cadence. Produced with a posture-derived header — "PRIVILEGED & CONFIDENTIAL — ATTORNEY WORK PRODUCT" where a counsel is named as being in the review loop, "CONFIDENTIAL — DRAFT FOR DPO REVIEW" on DPO-led runs; a sanitized version is offered when the document is going outside the privilege circle. **Every output self-identifies as an AI-generated draft of this skill** — cover notice, footer, and file metadata, none of it removable by manifest — authored for human review and adoption, never presented as counsel's own work. The footer names the reviewing role from the document's posture: "for attorney review" where a counsel is named and the work-product header is on, "for DPO review" otherwise.

## Project structure

```
dpia-generator/
├── SKILL.md                          # Skill instructions and workflow
├── README.md
├── LICENSE
├── package.json                      # Pinned docx dependency; `npm test` runs the suite
├── package-lock.json
├── .gitignore
├── .github/
│   └── workflows/
│       └── test.yml                  # CI: runs the regression suite on every push and PR
├── docs/
│   ├── eval-prompts.md               # Graded skill-level eval prompts (workflow behaviors
│   │                                 #   the regression suite cannot test)
│   └── open-datasets-integration-plan.md   # Design record for the open-dataset workstreams
│                                     #   (1–3 executed as v4.3; 4–6 proposed)
├── references/
│   ├── legal-framework.md            # Art. 35/36 text, recitals, WP248rev01 nine criteria, mandatory lists
│   ├── risk-matrix.md                # 3×3 matrix, scoring rubrics, inherent → residual transition
│   ├── authorities.md                # Citation register: settled statutory cites vs. unverified guidance
│   ├── notice-profile.md             # Privacy-notice profile: portable YAML schema, indexing mode,
│   │                                 #   staleness rules, and what the profile feeds on DPIA runs
│   ├── published-dpias.md            # Curated catalog of real DPIAs, DPA decisions and regulator guides
│   ├── jurisdictions/                # One module per non-EU regime (trigger test, Art. 35(7)
│   │   └── uk-gdpr.md                #   crosswalk, regulator engagement, privilege posture)
│   └── output-template.md            # Section structure, table layouts, template → manifest mapping
├── scripts/
│   ├── build_dpia.js                 # Manifest-driven .docx assembler; owns the jurisdiction registry,
│   │                                 #   the matrix mapping, the high-residual mark, and the exit-3 gates
│   └── run_regression.js             # Regression suite over the builder
└── tests/fixtures/                   # One manifest per regression case
```

## Testing

```bash
npm install                             # installs the pinned docx package
node scripts/run_regression.js          # exit 0 if all pass; --keep to inspect the .docx files
```

Each case is a defect that shipped or a gate that exists to stop one, and each carries a one-line note saying which; the runner fails on a fixture with no case, so the fixture directory cannot silently drift from the suite. Run it after any change to the builder, to `references/risk-matrix.md`, or to the manifest schema — the matrix mapping and the Article 36 flag are the two things in this skill a reader cannot check by eye. The suite is mutation-tested: reintroducing the v1.1 Article 36 bug, or corrupting a single matrix cell, turns it red.

The builder validates its own OOXML output via the public docx skill's `validate.py` where that skill is installed (`/mnt/skills/public/docx`). The validator is a Python script requiring the `defusedxml` and `lxml` packages; if it is absent or cannot run, the builder skips validation with a warning on stderr rather than failing the build — when that warning names a missing Python dependency, `pip install defusedxml lxml` and a re-run turns the skip into a real validation. `--no-validate` disables the validation step entirely.

## Maintenance — keeping the regime modules honest

The skill's coverage is only as good as its most stale module. Four standing rules:

1. **Volatility banners are contracts.** Modules carrying an explicit banner — Brazil
   (ANPD RIPD regulation pending), Malaysia (JPDP DPIA guideline in consultation),
   Indonesia (UU PDP implementing regulation pending), Vietnam (2025 Law's implementing
   decrees rolling) — must be **re-searched on every run that touches them**, and rebuilt
   from the final instrument when it lands, never patched by prose. Australia's tranche-two
   reforms and the UAE's executive regulations are the same class, tracked in their module
   and the screening catalog respectively.
2. **Dates are check-by dates.** Every sourcing banner records when its corroboration pass
   ran (currently 2026-08-04). A banner more than ~6 months old should be treated as a
   prompt to re-verify before reliance, not as a fact.
3. **`tech-law-radar` feeds the queue.** The sibling skill's periodic sweeps are the
   designed intake for new instruments (a final Malaysian guideline, an SDF designation
   wave in India, a CPPA enforcement action interpreting § 7152). Radar findings that touch
   a covered regime become module updates; findings that touch a screening-catalog regime
   are promotion candidates.
4. **Promotion has one path.** Screening entry → full module via the standard build: fetch
   (or search-corroborate, honestly tagged) the primary sources, write the module skeleton,
   add the registry code, add a fixture if the regime introduces new gate behavior, bump
   the version. Kenya (v3.8) is the worked example.

The first session run from an environment whose fetch tool can reach official portals
should also execute the `[official publication]` upgrade pass recorded in
`references/authorities.md` — the corroborated middle tier is deliberate, not final.

Skill-level eval prompts (the workflow behaviors the regression suite cannot test) live in
`docs/eval-prompts.md`.

## Changelog

The `## Version` section of `SKILL.md` is canonical; this is the long-form record and does not contradict it.

- **v4.4.0** — 2026-09-12 currency-review pass across the reference layer, from a four-track audit (EU/UK/Swiss, US states, APAC, Americas/Africa) run against every dated claim in the modules; references and SKILL.md only, no builder change, suite unchanged at forty-nine cases. Corrections that were wrong at (or missed by) the 2026-08-11 pass: **Indonesia** — Government Regulation No. 33 of 2026 implementing the PDP Law was enacted 2026-07-16 (in force ~2027-01-16; DPIA triggers and content at Arts. 120–121, DPO consultation codified), so the module's "none of the nine implementing regulations enacted" banner was already false when recorded; the module is rebuilt around GR 33/2026 with a rebuild-from-gazette-text obligation still owed. **Colorado** — the §2 trigger list gains the SB 24-041 minors trigger (eff. 2025-10-01, applies regardless of the CPA's volume thresholds) and SB 25-276's addition of precise geolocation to sensitive data with opt-in consent for sensitive-data sales (eff. 2025-10-01); the 4 CCR 904-3 rules were amended October 2025 and the amended set is now the citable one; the SB 26-189 signing date is resolved to 2026-05-14. Newly landed or flipped in the window: **South Korea's** PIPA amendment is in force since 2026-09-11 (global-turnover fines, CEO liability, AI-training pseudonymized-data exemption; the raw-data-for-AI bill remains a bill); **China's** small-handler simplified-PIPIA regime (issued 2026-07-22, effective 2026-09-01, <100k individuals) joins the module's §2 screen, with GB/T 46068-2025 closing the certification-route "specs pending" claim and the large-handler draft provisions noted as watch-status; **Australia's** tranche-2 exposure draft (Privacy Amendment (Personal Data Protection) Bill 2026, released 2026-08-31) replaces "still no bill"; **Connecticut** re-screened — 35k threshold and a no-threshold prong for sale/sensitive-data processing from 2026-07-01, profiling impact assessments from 2026-08-01 — no longer a clean thin-pattern member; Maryland's 2026 amendment (inferred sensitive data; enforceable 2026-04-01), New Jersey's A5328 data-broker registration and expired proposed regs, Florida named as a deliberate roster exclusion, Kentucky's HB 692 ACR-data footnote. EU core: the GDPR Procedural Regulation (EU) 2025/2518 (applies 2027-04-02) and the EDPB's July 2026 draft Guidelines 02/2026 (anonymisation) and 03/2026 (web scraping for generative AI) join the register; the DPF entry gains the Microsoft intervention (2026-06-29) and expected-ruling window; the Art. 50 machine-readable-marking deadline (2026-12-02) and the Data Omnibus roll-forward (Art. 88c reportedly weakened in Council) are recorded; the ICO→Information Commission transition is marked imminent (autumn 2026, Arnold CEO) with SI 2026/386 added; ICO ADM final guidance dated to Winter 2026. Switzerland gains the Swiss–US DPF route (eff. 2024-09-15) and the FDPIC's 2025-05-08 AI statement. Americas/Africa: EU–Brazil adequacy corrected to adopted 2026-01-26 with the Brazilian leg identified (Resolução CD/ANPD nº 32/2026), the ANPD high-risk tomada de subsídios (closes 2026-09-28) and PL 2338's post-election postponement added; Quebec's C-36 penalty framing fixed (AMPs to the greater of $10M/3%, offences $25M/5% — percentage-of-revenue ceilings) with the CAI's participation in the OPC OpenAI finding noted; Kenya's transfers section re-anchored on the ODPC's 2026 Cross-Border Transfer Guidance Note (with annexed Standard Clauses, interpreting Reg. 40) and EU adequacy moved to a per-run check (September 2026 target, no decision adopted); the SURF Copilot catalog entry now warns against citing the December 2024 residual posture without checking the published update DPIA; the UAE screening entry's issuance sourcing upgraded. Token trims in SKILL.md: the Version section reduced to the current release plus this pointer (the trimmed v4.2–v4.3.3 summaries live here, below), and the Reference Files section condensed to one-liners — no rule was removed, only restated shorter.

- **v4.3.3** — Fail-cleanly hardening found by a full repo review that drove three common cross-border use cases through the builder end to end: an EU/UK→US SaaS adoption (DPF transfer, notice-drift rows, conditional Art. 36 derived = declared), a four-regime HR centralization (EU/UK/Brazil/Quebec — LGPD RIPD and Law 25 conclusions in the computed engagement table, attorney posture), and a China PIPL standard-contract export run in the two-document posture (producible `PIPIA_`-prefixed CAC record with no privilege header beside the privileged EU spine with an unconditional Art. 36). Every gate behaved as documented when probed with deliberate errors (overstated and understated consultation conclusions exit 3, mis-stated rating exit 3, narrative contradiction warned), OOXML validation passed, `npm audit` was clean, and each build took ~250 ms.

The review's four findings are all of one class — inputs that crashed with a stack trace or rendered debris instead of failing cleanly — and are fixed in the builder with a pinning fixture each: a manifest whose JSON parses to `null` (or a string, or an array) hit the required-field check with a TypeError; a null entry in `blocks` crashed on the first `.type` access (the v4.1.1 contract, latent on the blocks array itself since v1.1); a non-array `blocks` crashed `.forEach` (now enforced as required-and-array, which the schema already said); and a `para`/`heading` with no `text` shipped the literal word "undefined" in the document body — the v4.2.1 `"headerText": null` defect class on the two commonest block types — with the sibling case, a null bullet item rendering "null", failed the same way (a null signature cell now renders empty, matching `dataTable`'s existing contract). Suite: forty-nine cases.

- **v4.3.2** — US-state applicability hardening and CI least-privilege. References and the workflow file only — no builder change, suite unchanged at forty-four cases.

**Applicability-threshold screen.** The `us-state` module told the model to identify which states' thresholds the controller meets but gave it no threshold data; §1a of `us-other-states.md` now carries the screen: per-state consumer/revenue prongs (a 7× spread on the consumer-count prong), the Texas/Nebraska no-numeric-threshold model, Montana's lowered threshold (25k consumers effective 2025-10-01), a near-threshold applicability-likely rule, and the no-assessment outliers (Utah, Iowa) named as findings for the applicable-regimes table rather than left silent. A 2026-08-31 web-search cross-check pass resolved two roster questions against primary-source leads — Idaho has no comprehensive law, and Nebraska does impose an assessment duty (Neb. Rev. Stat. § 87-1116, the NDPA's assessment section) — and the module's sourcing note pins the rule the pass illustrated: third-party state rosters are leads, never sources. Everything added ships under the house `[web search — verify]` / `[model knowledge — verify]` discipline.

**Security pass.** The builder's existing hardening held under review — output-path allowlist and basename confinement, prototype-pollution guards on manifest-keyed lookups, XML escaping of untrusted vendor text, calendar-date round-trips, clean-failure row guards — with the regression suite green (44/44) and `npm audit` reporting zero vulnerabilities on the pinned dependency tree. The one gap closed: the CI workflow ran with the default GITHUB_TOKEN grant; it now declares `permissions: contents: read`, the least privilege the suite needs.

- **v4.3.1** — Hardening pass from the v4.3 test round. The release was tested by fresh-context runs that had never seen the changes: two independent Notice-Profile indexing runs on the same planted notice (which produced a byte-identical extraction surface — the category-complete rule doing exactly what it was built for — and both caught, reported, and refused an embedded prompt injection), one full multi-regime DPIA run consuming a v1.1 profile (exit 0, validated, conditional Art. 36 derived = declared), builder gate probes (escaping, drift-without-resolution exit 1, contradicted conclusion exit 3), and a security review (no findings). The fixes are what the fresh-context reviewers surfaced — references and workflow only, no builder change:

**Injection findings now survive into the profile.** Both indexing runs independently hit the same gap: an embedded instruction found in a notice was reported verbatim in the chat summary, as required — but the summary dies with the session, and the profile (the artifact future runs consume) had no field for it, so both runs improvised. Profile entries now carry an optional `flags` list; the untrusted-content rule requires the finding recorded there as well as in the summary; consuming DPIA runs surface `flags` in §1.10's narrative and Appendix B and never re-obey the flagged text. Eval 4 gains a checklist line for it.

**Smaller seams, each hit in testing:** the §1.10 **silence-row convention** is blessed (a silence finding's `commitment` cell carries a bracketed meta-statement — `"[Notice silent — no retention commitment; profile customers-2026-03]"` — outside the verbatim-quote rule, which governs quotes and a silence row quotes nothing); the **cover note** SKILL.md routes findings to now has a defined home in `output-template.md` (unnumbered section between cover page and executive summary, with its own manifest-mapping row) instead of being invented per run; the **`regulatorTable` trigger** is corrected from "beyond EU/UK" to "more than one declared regime" — EU + UK is two regulators (DPC, ICO) with no one-stop-shop between them, and the per-regulator split should render, not sit implicit; **profile conventions pinned** — canonical filename `privacy-notice-profile.yaml`, id = `<audience>-<fetched YYYY-MM>` (suffixed on same-month re-index), the repeatability invariant defined as the extraction surface rather than a byte-identical file, a classification tiebreaker for near-miss text ("we respond within one month" is a `rights` promise, not `retention`), and gap-reporting extended to sibling notices the notice itself references; **Step 6 fallbacks** for a missing outputs directory and absent `present_files` (state the substitution, never make it silently); and the README's Testing section notes that a validator skip naming missing Python deps is repairable with `pip install defusedxml lxml`.

**SKILL.md's Version section is trimmed** to the recent releases plus a headline summary — the full history lives here, in this Changelog, which was already the long-form record. The section had grown to roughly a third of SKILL.md and was pure token cost on every fresh-context run; the trim is the single largest de-bloat in the release and changes no behavior.

- **v4.3** — Open-data integrations: three of the six workstreams from `docs/open-datasets-integration-plan.md` land (EDPB registers, the OPP-115 schema with its JURIX 2020 GDPR crosswalk, and Open Terms Archive). References and workflow prose only — the builder, manifest schema and regression suite are untouched.

**EDPB registers become the catalog's decision index.** `published-dpias.md`'s Discovery Corpora and `authorities.md` gain the Art. 60 final one-stop-shop register, the Art. 65 binding decisions, the BCR approvals, and the European Commission's live adequacy list — each under the same live-check standing rule the DPF entry already modelled: consulted at the time the DPIA is written, never cited from the register file, with the underlying national decision (not the Secretariat's non-authoritative summary) as the citable object. GDPRhub is admitted as a finder and barred as a citation — wiki content never upgrades a source tag. The registers are also the shared ingestion surface for the sibling `bcr-registry` work; this repo carries the consumption rules, not the data.

**Notice indexing becomes category-complete.** The notice profile's commitment types were a sound vocabulary with no coverage guarantee: two indexings of the same notice could legitimately capture different commitment sets, and a commitment absent from the profile is invisible to the §1.10 drift check. The vocabulary is now crosswalked to the OPP-115 annotation scheme (Wilson et al., ACL 2016 — ten annotator-validated data-practice categories), which exposed three gaps now filled: `policy-change` (the notice's own promise about announcing changes — the meta-commitment the drift check itself relies on), `choice-control` (opt-outs beyond sale/share; absorbs Do Not Track), and `specific-audiences` (children's and region carve-outs within a notice). Indexing is now a pass over the whole vocabulary with per-type attribute discipline (what a complete quote set looks like), and silence is recorded as data in a `silent` list — "checked, no commitment of this kind" — so a re-index of an unchanged notice reproduces the profile, and §1.10 can distinguish a notice's silence from an unchecked type. Each type carries GDPR Article hooks informed by the JURIX 2020 OPP-115→GDPR mapping (Poplavska et al.), shipped `[web search — verify]` with a capture note until the paper is fetched and reconciled — the corpora themselves (research-only NLP training data) are not bundled and not needed; the schema is adopted with citation. A fourth eval (`docs/eval-prompts.md`) grades indexing repeatability across two fresh runs.

**Vendor terms get version-pinned.** Profile schema v1.1 (backward-compatible; v1 profiles unchanged) adds `role: vendor` entries so a load-bearing processor's DPA or privacy policy can be indexed once — verbatim quotes, pinpoints, and a required `version_date`, with an optional `ota_collection` locator where Open Terms Archive tracks the vendor. A new rule in `authorities.md` requires any DPIA that relies on vendor terms to cite them as of a named version date; Step 0.5 gains a vendor-terms diff on refresh runs (OTA history where tracked, re-fetch-and-compare otherwise), and "material change to a relied-on vendor's terms" joins the off-cycle review triggers — the most common real DPIA-review trigger, previously detectable only by re-reading the terms. Coverage caveat stated where the rules live: absence from OTA is absence of tracking, never evidence of no change; ODbL-licensed OTA data is consumed live, never bundled. Vendor commitments stay vendor representations under the Untrusted-Content Rule — the integration changes their checkability, not their weight.

- **v4.2.1** — Three builder defects and one documentation drift, found by a full repo review (all three defects empirically confirmed before fixing, each now pinned by a fixture). **`"headerText": null` rendered a literal "null" header**: `headerTextOf` checked only `!== undefined`, so a manifest carrying the schema's documented default literally — `"headerText": null` — shipped a document whose every page header (and cover banner, and file metadata) read "null"; null now means "use the posture-derived default", and only `""` suppresses the header. **The manifest `date` was regex-checked but not calendar-checked** — the defect class v4.1.1 fixed for `notice.date`, latent on the assessment date itself: "2026-13-99" passed the format check, shipped on the cover, and turned the notice-staleness arithmetic into a silent NaN no-op (a 19-month-old notice profile drew no warning). The fix is stricter than the v4.1.1 one: `isNaN` alone misses V8's rollover parsing ("2026-02-31" parses as March 3rd), so both dates now round-trip through ISO — parse, re-format, compare — and `notice.date` moved to the same shared check. **An orphan `mitigatedRating` produced a misleading gate failure**: stated without `mitigatedLikelihood`/`mitigatedSeverity`, it failed closed but as exit 3 — `stated mitigatedRating "Low" != derived "null" from (null x null)` — instructing the user to re-examine scores that were never stated; it is now a clean exit 1 naming the missing fields, matching the existing "together or not at all" check on the score pair. Documentation: the frontmatter description still promised "an attorney-work-product Word assessment", stale since v4.2 made the work-product posture derived rather than default — a DPO-led run deliberately ships without that framing; it now says "a Word privacy assessment draft" — a regime-neutral umbrella accurate for the DPIA, the Colorado data protection assessment, the RIPD, the PIPIA, and the Law 25 PIA alike — which also restores headroom under the 1024-character packaging cap (1013 of 1024). Suite: forty-four cases.

- **v4.2** — Posture derivation completed end-to-end: whether counsel is in the loop is now a fact the run collects once and every marking derives from. v4.1.2 made the footer's reviewer phrase follow the `counsel` field but left the header hard-defaulted to "ATTORNEY WORK PRODUCT" — so a DPO-led run shipped a "for DPO review" footer under a work-product banner, half-admitting no attorney was involved while claiming attorney work product. The header default now derives from the same signal: work-product header where the manifest names a `counsel`, "CONFIDENTIAL — DRAFT FOR DPO REVIEW" otherwise (a DPO-led DPIA is the statutory norm — Article 35 needs no lawyer — and a work-product label no attorney will stand behind creates no protection while reading as contrived to a regulator; the adopting counsel adding the framing later is the recoverable direction). Explicit `headerText` still overrides either default and `""` still omits the header for regulator-production postures. The workflow asks nothing new: Step 0 collects counsel as an ordinary cover-page fact ("if any is involved in the review"), counsel-not-named *is* the answer — never chased as a gap, never placeholder-filled, never a "do you have a lawyer?" gate — and Step 6 states the shipped posture as a correctable assumption ("no counsel was named, so this is framed as a DPO-reviewed confidential draft; say so if legal will review it and it will be reissued"). No topic-area verification flags accompany the posture: the entire document is AI-drafted analysis for the reviewer to verify, and it already says so globally (cover notice, footer, draft-until-adopted rule), with the particularized flags carrying the real confidence differences (per-citation source-attribution tags, Appendix B open questions). Singling out sections — the lawful basis, transfers, or any other — for extra warnings would imply the rest needs less review; and nothing in the GDPR reserves those determinations to counsel anyway (Art. 35(2) names the DPO as the DPIA's advisor, Art. 37(5) defines the role by expert knowledge of data protection law). Escalation of any point to counsel stays with the reviewer. Both reviewer-posture regression cases extended to pin the derived headers.

- **v4.1.2** — Audience-posture fix for the report's framing. The footer's reviewer phrase was hard-coded to "for attorney review" on every page of every document — wrong on a DPO-led run (the normal EU posture: Article 35 needs no lawyer anywhere in the process, and the cover already says "DRAFT FOR DPO REVIEW"), and inconsistent on the two-document producible record, where the builder deliberately sheds the privilege header via `"headerText": ""` and the footer then undid that honesty by telling the regulator the filing was an attorney draft. The phrase is now derived from the document's posture, not a manifest knob: "for attorney review" only where the manifest names a `counsel` **and** the work-product header is on; "for DPO review" otherwise. The generation-transparency half ("AI-generated draft (dpia-generator)") is unchanged and remains non-removable. Second fix in the same theme: the cover's "Counsel of Record: [to be completed]" line rendered unconditionally, implying a role many controllers do not staff and inviting someone to attribute the draft to a person before adoption — it now renders only where a counsel is actually named. Suite: forty-one cases (both postures pinned, plus the producible-record footer).

- **v4.1.1** — Hardening found by an adversarial test pass over the v4.1 surface. A null (or string, or array-where-object) entry in any block's `rows` crashed the builder with a TypeError stack trace instead of a clean exit 1 naming the row — the same defect class v3.4.1 fixed for prototype-chain lookups, latent on every rows-consuming block since v1.1 (`riskRegister`, `table`, `complianceMap`, `signature`) and inherited by the new `noticeCheck`. All five now guard row shape before member access. Two `noticeCheck` seams closed: a `notice.date` that matches the YYYY-MM-DD regex but is not a real calendar date ("2025-13-99") produced NaN arithmetic that silently disabled the staleness warning — now exit 1; and a consistent row's stated `action` (e.g. "monitor at next notice refresh") was silently dropped in favour of "—" — now rendered. XML-injection probes through every new field (commitments, actions, provenance, title) confirmed escaped by the renderer, with embedded instructions carried verbatim as data; staleness boundary pinned at 183/184 days; `npm audit` clean. Suite: thirty-nine cases.

- **v4.1** — The privacy notice becomes a provide-once input, and §1.10 reaches the gate philosophy.

The §1.10 Privacy Policy Consistency Check exists because policy drift — the feature ships, the notice doesn't change — is among the most common and least caught failure modes in DPIA practice. But the notice itself was a per-run input: unless the user pasted it into that session, the check degraded to an Appendix B open question. Two changes close that. **Notice-Profile Mode** ("index our privacy notice") extracts the published notice once into a portable `privacy-notice-profile.yaml` the user keeps, in the same durable-state pattern as `ropa-builder`'s registers: verbatim commitments with section pinpoints (a paraphrased commitment is a fabricated citation with extra steps), typed by category, keyed by audience where the controller runs separate customer/employee/candidate notices, with provenance and a check-by `fetched` date — client data, never skill content. On DPIA runs a new **Step 0.6** loads the profile (attached file, named folder, or `conversation_search`), applies a ~6-month staleness gate, matches by audience, and feeds intake pre-fill, the Art. 13/14 and Art. 6(4) analysis in Step 2, and §1.10. **The check itself is now computed**: a `noticeCheck` builder block renders the drift table from per-commitment verdicts (`consistent`/`drift`/`conflict`, colour-coded from the ratings palette) with the notice's provenance stated; a drift or conflict row with no committed resolution is a build failure (exit 1) — the resolution rule was prose a manifest could ignore, and is now a gate — the resolution footnote is builder-owned, and a notice indexed more than six months before the assessment date warns on stderr. Without a profile, behavior is unchanged: the check runs from a supplied notice or lands in Appendix B, and is never populated from memory. Suite: thirty-six cases.

- **v4.0.4** — Published-DPIA catalog expansion, no behavior change. Step 1's analog catalog previously leaned toward high-drama processing (facial recognition, biometrics, asylum casework) while the most common real request — "we are adopting SaaS vendor X" — had no completed-DPIA analog at all. The expansion closes that and several other gaps with sources verified by web search (and flagged `[web search — verify]` until fetched live, since the build environment's egress proxy blocked direct fetches): the **Dutch SLM Rijk / SURF / Privacy Company corpus** — complete professional DPIAs in English on Microsoft 365, Teams/OneDrive/SharePoint, Microsoft 365 Copilot, and Zoom, published with the vendor-negotiation remediation arc that models the inherent → residual → post-mitigation scoring this skill's tri-state conclusion depends on; **UK health DPIAs** (the versioned NHS COVID-19 app DPIA, the NHS Federated Data Platform's live overarching-plus-product-level DPIA architecture, the COVID-19 Data Store and GPES pandemic-data DPIAs, and Ireland's HSE COVID Tracker DPIA); **further police publications** (NPCC Police National Database DPIA, Met Violence Harm Assessment DPIA, Scottish Police Authority DESC DPIA) and gov.scot's steady supply of ordinary legislative DPIAs; the two remaining **ICO children's-code samples** (mobile gaming app, connected toy) joining the online-retail sample already catalogued; and a new **Discovery Corpora** section for standing collections rather than single analogs — WhatDoTheyKnow's FOI archive, Canada's mandatory federal PIA summaries, Australia's mandatory agency PIA registers, and New Zealand's per-release COVID Tracer PIAs. The catalog header now states the verification convention entry-by-entry instead of claiming everything is fetch-verified. Builder, suite, and workflow unchanged.

- **v4.0.3** — Maintenance pass, no builder behavior change. Live prose no longer hard-codes drift-prone facts: the suite size and regime count are gone from `SKILL.md`'s Reference Files and this README's Testing and Maintenance sections (the runner prints its own count; `references/jurisdictions/` is the regime list), and the per-file version tags in the two scripts are dropped — `SKILL.md`'s `## Version` section is the one version that exists, which also retires the stale "(v3.0)" the Reference Files entry still carried for a v4-era builder. The regression runner now fails on a fixture with no corresponding case, so the fixture directory and the suite are kept in step mechanically. `SKILL.md`'s version entries are condensed to the one-line format this changelog backs. README: the opening is rewritten into readable sentences and its module list corrected (Kenya, Vietnam, and Indonesia — added in v3.8 — were missing), and the Notes-and-limitations section is folded away: two bullets duplicated What-it-does items, and the two that did not now live there. `package.json` synced.

- **v4.0.2** — Public-release hygiene, no behavior change. Removes `docs/global-expansion-plan.md`: the plan executed in full as v3.0–v3.4 (with coverage since exceeding it — v3.8), and every rule it carried that still matters lives in a maintained file — the module skeleton in `SKILL.md`'s Reference Files section, the promotion path and volatility rules in this README's Maintenance section, the citation-upgrade pass in `references/authorities.md`. Also completes the project-structure tree (`docs/`, the package files, `.gitignore` were omitted) and syncs `package.json`'s version field, stale at 2.0.2. Suite unchanged at thirty-two cases.

- **v4.0.1** — The cover generation notice is trimmed to its first sentence: "AI-GENERATED DRAFT — produced by the dpia-generator skill." The adoption/not-legal-advice framing already lives in this README's disclaimer and in the delivery summary, so repeating it on every cover was surplus. Footer and file metadata unchanged.

- **v4.0** — Generation transparency, and pragmatism in the Article 36 conclusion.

**Every document now says what made it.** The cover carries a fixed notice — "AI-GENERATED DRAFT — produced by the dpia-generator skill." — the footer reads "AI-generated draft (dpia-generator) — for attorney review" where it previously said "Prepared by Counsel", the file metadata names the generator, and the revision history's initial author is the skill, not a person. None of this is manifest-controllable, and it renders on producible records too, where transparency matters most. The counsel's-voice analytical style is unchanged; what changed is that the *authorship* is no longer implied — the sign-off block is where a human reviewer adopts the draft as their own.

**Consultation conclusions are now pragmatic where the scores support it.** Article 36(1) requires consultation for high risk "in the absence of measures taken by the controller to mitigate the risk" — so a High residual that falls below High once the DPIA's own Section 5 mitigations are implemented should not read as an unconditional stop. Register rows may now score the post-mitigation residual (checked by the rating gate like everything else), and the derived conclusion becomes tri-state: required, not required, or **conditional** — required only if the controller proceeds without implementing the mitigations. The register grows a Post-mitigation column, the matrices a post-mitigation stage, the footnote and engagement table state the condition in plain terms, and the gate is symmetric: overstating the obligation (declaring unconditional "required" when every High residual is mitigable) fails the build exactly as understating it does. The discipline rules travel with it — a post-mitigation score is a commitment with an owner and a date, not a wish, and where any High residual survives the recommended mitigations, the unconditional flag stands. Suite: thirty-two cases.

- **v3.9.1** — A grammar defect found by the three-scenario test pass (global, EU-only, USA+KSA): with three consultation regimes engaged (EU + UK + Kenya), the register footnote chained the authorities with repeated "and"s. The join is now Oxford-style, and a new fixture pins both the three-item list and the legacy `art36` alias filling every derivable regime's conclusion. Suite: thirty cases.

- **v3.9** — The maintenance loop is written down, and the workflow gets evals. A README Maintenance section makes the upkeep rules explicit — volatility banners as contracts, check-by dates, the `tech-law-radar` intake for regulatory drift, and the single promotion path from screening entry to module. `docs/eval-prompts.md` adds three graded skill-level eval prompts for the behaviors the builder suite cannot test: regime mapping and per-regime screening on a four-jurisdiction fact pattern, the producible-record posture on a Colorado-only request, and — most importantly — the negative case: an assessment touching Saudi Arabia and the UAE must surface the screening notes and the coverage fallback rather than silently absorbing regimes the skill has not built. No behavior change.

- **v3.8** — Kenya, Vietnam, Indonesia — the two coverage omissions the optimization review named, plus the cheapest promotion.

All three were search-verified before a line was written. **Kenya** (`ke-dpa`) is promoted out of the screening catalog and becomes the builder's **third derivable regime**: s. 31 of the DPA 2019 requires Data Commissioner consultation where the DPIA indicates high risk — a true Article 36 analog with no advisor escape hatch — so the conclusion derives from the register exactly as for EU/UK, with its own "Requires ODPC Consultation" cover status and register footnote. **Vietnam** (`vn-pdpl`) covers the PDP Law No. 91/2025/QH15 (effective 2026-01-01, replacing Decree 13/2023): the most filing-intensive regime in the skill, with processing and transfer impact dossiers submitted to the Ministry of Public Security within 60 days — added to the regulator filing gate, with a China-grade privilege posture (no candid analysis in the Vietnam record, ever). **Indonesia** (`id-pdp`) covers UU PDP Article 34's high-risk DPIA duty behind a volatility banner while the implementing regulation is pending. Adding Kenya exposed and fixed a latent seam: the cover-status coherence warning was hard-coded to the Art. 36 status string and would have warned spuriously on a correct Kenya-only cover; it now accepts any derivable regime's blocking status. Registry: seventeen codes. Suite: twenty-nine cases.

- **v3.7** — The gate philosophy reaches the last hand-authored surface; the two-document posture becomes mechanical.

The Section 5 regulator-engagement table — the exact analog, for the other eleven regimes, of the Article 36 flag — was still a free-hand `table` block a manifest could contradict. A new `regulatorTable` block now renders it computed from `regulatorConclusions` plus the builder's registry (per-regime engagement mechanism and conclusion label, with per-regime reasoning passed as `notes`); a declared regime without a conclusion cannot render a row and fails the build. The Article 36 filing gate generalizes to a **regulator filing gate** covering every submission event the expansion added: the CPPA attestation package, China's SCC filing (which includes the PIPIA report itself), India's Data Protection Board report, and the Swiss FDPIC consultation. The two-document posture is now operational rather than aspirational: filenames derive their prefix from the document title's initials (the default title still yields `DPIA_`; a Colorado "DATA PROTECTION ASSESSMENT" ships as `DPA_`), and Step 5 specifies the two-manifest procedure — producible record and privileged spine, built separately, labelled in the delivery summary. Two workflow seams closed: the transfers intake question now runs per regime (China export routes, Quebec's intra-Canada trigger, Brazilian mechanisms) instead of asking only about EU adequacy, and Step 2 directs the lawful-basis analysis through each module's basis mapping rather than transplanting the Article 6 conclusion. The description is trimmed to 996 characters, restoring deliberate headroom under the 1024 packaging cap. Suite: twenty-eight cases.

- **v3.6** — Reviewer title simplified to a uniform "DPO", and a citation-verification pass.

The cover-status review state now reads "Under DPO Review" for every regime — the review officer's exact statutory title (SRI, Encarregado, Person in Charge of PI Protection, and so on) varies, but the checkbox does not need that specificity; the per-regime **blocking** states (Article 36, FDPIC consultation, PIPC agency assessment) are unchanged. Separately, a verification pass ran against the citations the earlier evaluation had flagged as UNVERIFIED. Primary-source fetches are still blocked (every official portal returns 403 to the fetch tool), so nothing reached `[official publication]` — but web search is available, and it corroborated the non-EU statutory identifiers, moving them off pure recall (`[model knowledge — verify]`) onto the corroborated middle tier (`[web search — verify]`): Colorado Rules 8.02/8.04/9.06, California's 11 CCR Article 10 §§ 7150 and 7152, Quebec ss. 3.3 and 17, LGPD Articles 5(XVII) and 38, PIPL Articles 55–56 with the three-year retention, GB/T 39335-2020, India's DPDP Rule 13, and Switzerland's revFADP SR 235.1 Articles 22/23/23(4). The pass also filled the long-recorded gap in the Data (Use and Access) Act 2025 citation — it is **chapter 18** (Royal Assent 19 June 2025) — and corrected a Brazilian resolution mis-attribution the verification surfaced: Resolução CD/ANPD nº 2/2022 is the small-agents regulation, not a binding high-risk-criteria list. `authorities.md` now spells out the three-tier tag semantics so the corroborated tier is never mistaken for a fetch. No behavior change; the regression suite is unchanged at twenty-seven cases.

- **v3.5** — Per-regime cover-status vocabulary, closing the last GDPR hard-coding the two-test evaluation reported.

The cover page's status checkboxes were a fixed GDPR list — a Colorado-only data protection assessment offered a "Requires Art. 36 Prior Consultation" box it could never lawfully check. The vocabulary is now derived from the manifest's `jurisdictions`: the review state names the primary regime's reviewer title (Under DPO Review, Under DPO / SRI Review, Under Privacy Counsel Review, Under Data Protection Advisor Review, Under Person in Charge of PI Protection Review, and so on through the registry), and each declared regime with a genuine consultation-style blocking state contributes its own checkbox — Article 36 for EU/UK scope, FDPIC consultation for Switzerland, the PIPC designated-agency assessment for Korean public-sector scope. Checklist regimes contribute none. A `statusOptions` manifest array overrides the derived list; a declared `status` outside the vocabulary renders as an additional checked box with a stderr note, so the cover always reflects the declared state rather than silently unchecking every option. Three new regression cases pin the Swiss vocabulary, the out-of-vocabulary path, and the absence of the Art. 36 box on checklist-regime covers (suite: twenty-seven cases).

- **v3.4.1** — Hardening found by a two-test global evaluation (a four-regime quality run and an adversarial security run). Manifest-supplied lookup keys could resolve through the JavaScript prototype chain: `"__proto__"` as a jurisdiction code slipped past the unknown-code check and produced a garbled gate diagnosis, and `"constructor"` as a matrix `source` crashed the builder with a stack trace — a latent defect dating to v1.1, exposed only once the registry pattern multiplied manifest-keyed lookups. All such lookups now go through own-property checks and null-prototype maps, failing cleanly with exit 1 and a correct message; two fixtures pin the behavior (suite: twenty-five cases). Also corrects the multi-regime Article 36 footnote to agree in number ("are engaged … those consultations have concluded") when both EU and UK authorities are named.

- **v3.4** — Phase 4 close-out: the screening catalog and the global triggering contract.

`references/jurisdictions/screening-catalog.md` adds Tier-3 screening entries — Saudi Arabia, UAE, South Africa (whose prior-authorisation regime under POPIA ss. 57–58 is closer to Article 36 than most), Nigeria, Kenya, Japan, Thailand — which upgrade the coverage fallback: instead of a bare "not covered", Section 6 may carry the one-paragraph screening note plus the explicit statement that coverage is limited to it. Promotion to a full module goes through the standard build (fetch, crosswalk, privilege posture, registry code), never by patching catalog prose. The skill description is rewritten for global triggering within the 1024-character packaging cap with every sibling routing clause intact, and the phase closes with an end-to-end smoke test: a four-regime biometric time-and-attendance manifest (EU, UK, Colorado, Brazil) through intake logic, per-regime conclusions, the regulator-engagement table and the builder's gates, with OOXML validation passing.

- **v3.3** — Phase 3 jurisdictions: Switzerland, India, Singapore, Malaysia, Australia, South Korea.

**Switzerland** (`ch-fadp`) is the cleanest overlay in the skill and carries its most instructive gate decision: revFADP Article 23 is a true Article 36 analog, but Article 23(4) lets a controller that consulted its data protection advisor lawfully skip the FDPIC on a High residual — a fact the builder cannot see. The regime is therefore deliberately non-derivable: the consultation conclusion is declared and reviewed, with the module spelling out the three lawful configurations. **India** (`in-dpdp`) models the entity-designation pattern — the DPIA duty attaches to designated Significant Data Fiduciaries annually with findings reported to the Data Protection Board, and a clean "no duty attaches" is treated as a first-class output. **Singapore** (`sg-pdpa`) captures the two statutory assessments gating deemed consent and the legitimate-interests exception; **Malaysia** (`my-pdpa`) ships on watch status with a volatility banner while the JPDP's DPIA guideline is in consultation; **Australia** (`au-privacy`) carries the agency-only PIA mandate plus the reform overlay already changing answers (statutory privacy tort since June 2025, ADM transparency from December 2026, employee-records and small-business exemptions reversing EU conclusions); **South Korea** (`kr-pipa`) documents the mandatory public-institution PIA run through PIPC-designated agencies — which the skill's output supports and pre-drafts but cannot substitute for, and says so. Korea joins China in the strictest privilege posture: the record is submitted or compellable by design, so candid analysis stays out.

- **v3.2** — Phase 2 jurisdictions: Brazil and China.

**Brazil** (`br-lgpd`) lands as a GDPR-family overlay: the LGPD's RIPD is satisfied by the Article 35 spine, with module coverage of the ten-basis lawful-basis mapping, the ANPD's high-risk criteria and demand power, and Brazilian transfer mechanics. The module opens with a volatility banner — the ANPD's dedicated RIPD regulation is still pending, and the module must be rebuilt from it when it lands rather than patched.

**China** (`cn-pipl`) is a standalone module: enumerated Article 55 triggers (sensitive PI is harm-defined and much broader than Article 9 — financial accounts, location, under-14s), short statutory content under Article 56 that the spine over-satisfies, a three-year retention rule, and the skill's second production-by-design regime — on the SCC export route the PIPIA report is filed with the provincial CAC. The privilege posture is the bluntest in the skill: China recognizes no legal professional privilege in the common-law sense, so counsel's candid analysis never enters the China record, without exception.

- **v3.1** — Phase 1 jurisdictions: the United States and Canada.

Four regime modules land in `references/jurisdictions/`: **Colorado** (`us-co` — the most prescriptive US content list, Rule 8.04, producible to the AG within 30 days), **California** (`us-ca` — CPPA risk assessments with the only scheduled filing obligation in the skill: first attestation due 2028-04-01 covering 2026–2027), the **harmonized US-state pattern** (`us-state` — Virginia CDPA archetype, one module rather than fifteen), and **Quebec Law 25** (`ca-qc` — project-based PIA trigger plus the outside-Quebec transfer PIA, the closest non-European analog to Article 35). The builder's registry gains all four as non-derivable checklist regimes: their conclusions are declared answers to their own trigger screens, gated on existence rather than derived from the register.

The plan's open privilege question is resolved: each module carries a **privilege posture** section, and the destination check now enforces a two-document default for regimes whose assessment is producible or filed by design — the producible record (no privileged header, regime-correct title) and counsel's candid analysis in the privileged GDPR-spine document. Build-time fetches of the primary sources returned 403 through the environment proxy; per the house rule every new citation ships UNVERIFIED with descriptive pinpoints, and each module says so at the top rather than presenting recall as verification. Suite grows to twenty-three cases.

- **v3.0** — Multi-jurisdiction architecture, deliberately behavior-preserving for EU/UK work.

**Jurisdictions and per-regime conclusions.** The manifest gains a `jurisdictions` array (default `["eu-gdpr"]`, so every existing manifest keeps its meaning) and a `regulatorConclusions` object requiring one declared engagement conclusion per regime wherever a risk register exists. The v2.0 `art36` field survives as an alias that fills the prior-consultation answer for GDPR-family regimes. The Article 36 conclusion gate becomes the general regulator conclusion gate: for prior-consultation regimes the declaration is checked against the register (exit 3 on contradiction, as before); for statutory-checklist regimes added by later phases the gate enforces that a conclusion exists at all (exit 1 on silence) — an assessment that has not formed a view on its regulator obligations is not finished, in any jurisdiction.

**Checklist regimes get a machine-checked map.** A new `complianceMap` block renders a regime's required-element → DPIA-section cross-reference; a `section` reference matching no heading in the manifest fails the build, because a dangling cross-reference is the checklist version of a fabricated citation.

**Privilege posture is now a parameter, not a constant.** `docTitle` and `headerText` override the cover title and the privileged header; `headerText: ""` deliberately omits the header for documents drafted for regulator production (a Colorado assessment producible to the AG cannot carry a header the disclosure itself would falsify). The default — full privileged header — is unchanged.

**Layout.** `references/uk-divergence.md` moved to `references/jurisdictions/uk-gdpr.md`, becoming the first module in the per-regime layout every subsequent jurisdiction follows; Section 6 generalized from "UK/EU Divergence" to "Jurisdictional Divergence"; intake question 9 became an applicable-regimes mapping with a hard coverage-fallback rule (a regime with no module is reported as not covered — never silently absorbed). Regression suite grows from fifteen to twenty-one cases.

- **v2.0.2** — Repo hygiene for public release. The builder's exit 2 previously conflated two different events: the validator ran and rejected the document, and the validator itself crashed before validating anything (a Python traceback from a missing `defusedxml` or `lxml` in the environment). The second is not a defect in the document, and the suite would go red on healthy code wherever the docx skill was present but its Python dependencies were not. The builder now captures the validator's output, detects a crash, and skips validation with a warning; exit 2 is reserved for a document the validator actually rejected. Also commits `package-lock.json` (previously gitignored) for reproducible installs, removes the README's reference to a packaged zip deleted from the repo, documents the validator's Python dependencies and `--no-validate`, and states the MIT license explicitly. Aligns the skill text with the README's not-legal-advice disclaimer: the work-product style note now reads "counsel's advice to the client" rather than "legal advice" (identical doctrine, no longer quotable out of context), and the delivery summary now restates on every run that the DPIA is a draft for attorney review — not legal advice until counsel has reviewed and adopted it.
- **v2.0.1** — Security hardening of the output path. The manifest is authored from instructions that can include untrusted ingested content (vendor pages, pasted specs), which makes its path fields semi-trusted. `outputDir` was unrestricted, so a manifest could direct the write to any location the process could reach — the same escape the `outputFilename` basename guard next to it was meant to prevent. `outputDir` is now confined to an allowlist (the default outputs directory and the OS temp dir, extendable via the `DPIA_OUTPUT_ROOTS` environment variable), and the residual `outputFilename` gap where `..`/`.` survive `basename()` and climb one level out of `outputDir` is closed, with the fully-resolved path re-checked against `outputDir`. Adds a pinned `package.json` (`npm test` runs the suite), a `.gitignore`, and two regression fixtures — `outputdir-escape` and `traversal-dotdot` — taking the suite to fifteen cases.

- **v2.0** — Extends the gate philosophy from the ratings to the conclusion, and adds the means to keep it honest.

**Article 36 conclusion gate.** The v1.1 rating gate stopped the register contradicting the matrix. It did nothing about the prose: a DPIA could carry a High residual in its table and a sentence in its executive summary saying prior consultation was not required, and nothing would object. A manifest with a risk register must now declare `"art36": true|false`, checked against the register, exit 3 on disagreement, exit 1 if undeclared — a DPIA that has not formed a view on prior consultation is not finished. A narrative scan additionally warns where the text appears to assert the opposite of the derived answer. This breaks existing manifests, hence the major version.

**Regression suite.** `scripts/run_regression.js` with thirteen fixtures covering both gates, the Article 36 positive and negative paths, XML escaping of untrusted vendor text, path traversal, and the manifest error cases. Mutation-tested: reverting the v1.1 Article 36 bug turns it red, as does corrupting a single cell of the matrix. Previously every change to this skill was verified by hand.

**Citation register.** `references/authorities.md` separates the recurring authorities that can be cited from stable identifiers from the guidance and case law that must be fetched first. It ships with the second category marked UNVERIFIED, and says what to capture on verification rather than inventing pinpoints — a precise citation that is wrong is worse than an approximate one honestly labelled.

**Tool-unavailable fallbacks.** Steps 0.5 and 1 now distinguish "checked and found nothing" from "could not check." The prior-work reconciliation no longer records a cold start when `conversation_search` was simply unavailable, and a run with no web access says in Appendix A that nothing was fetched rather than presenting an unreachable analog as an absent one.

- **v1.2.1** — Two items found by running the skill end to end against a full DPIA. A manifest `outputFilename` containing a path could write outside `outputDir`; it is now reduced to a basename, with a note on stderr when that happens. Step 5 now cites the script header's line range so the manifest schema can be read without loading the whole builder.

- **v1.2** — Corrected the Article 36 prior-consultation flag. It previously fired only on a High likelihood × High severity residual, so a Medium × High residual — which rates High on the published matrix, and which Art. 36(1) engages on identically — was rendered without the flag. The flag now keys to the derived residual rating wherever it appears: the register table, `risk-matrix.md`, and Step 4. The builder additionally warns when a High residual is present but the cover-page status does not say `Requires Art. 36 Prior Consultation`.

Also removed the v1.1 contradiction in `output-template.md`, which still told the model to hand-write a per-run `create_dpia.js` and specified a US-Letter/Arial layout and an eleven-column register that the bundled builder does not produce; it now carries a template → manifest mapping table matching the builder's actual output. Added a Fast-Path Default section to `SKILL.md`, made the A4 page geometry explicit in the builder, and narrowed Step 5's mandatory read of the public docx skill to the exit-2 repair path.

- **v1.1** — Step 5 moved from an unbundled per-run generator to the bundled, tested `scripts/build_dpia.js`. The matrix mapping and the Article 36 flag became script-computed under a hard gate (exit 3) rather than model-asserted. The description gained routing clauses against `product-regulatory-scan`, `tech-law-radar`, and `b2b-supplier-redline`.

- **v1.0** — Baseline: Article 35 framework, published-DPIA analogs, 3×3 matrix, UK/EU divergence notes.

## License

MIT — see [LICENSE](LICENSE).

dpia-generator

File Explorer

# Use via CDN

# Project Badges

Was this content helpful?

Recent Feedback

Download README