@wildo-ai/saas-models 1.1.0 → 1.1.2

package/dist/esm/compliance/privacy/impersonalization.shared.schemas.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"impersonalization.shared.schemas.d.ts","sourceRoot":"","sources":["../../../../../src/compliance/privacy/impersonalization.shared.schemas.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AAExB;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AACH,oBAAY,eAAe;IACzB,sDAAsD;IACtD,MAAM,WAAW;IACjB;;;;;OAKG;IACH,QAAQ,aAAa;CACtB;AAED;;;GAGG;AACH,eAAO,MAAM,qBAAqB,EAAE,CAAC,CAAC,OAAO,CAAC,OAAO,eAAe,CAC3C,CAAC;AAE1B;;;;;;;;;;;;;;GAcG;AACH,oBAAY,oBAAoB;IAC9B;;;;;;OAMG;IACH,WAAW,gBAAgB;IAC3B;;;;;;OAMG;IACH,wBAAwB,6BAA6B;CACtD;AAED;;;GAGG;AACH,eAAO,MAAM,0BAA0B,EAAE,CAAC,CAAC,OAAO,CAAC,OAAO,oBAAoB,CAChD,CAAC;AAE/B;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAkDG;AACH,oBAAY,uBAAuB;IACjC;;;;;;;;;;;;;;;;;;OAkBG;IACH,YAAY,iBAAiB;IAC7B;;;;;;;;;OASG;IACH,cAAc,mBAAmB;IACjC;;;;;;;;;;OAUG;IACH,gBAAgB,qBAAqB;CACtC;AAED;;;GAGG;AACH,eAAO,MAAM,6BAA6B,EAAE,CAAC,CAAC,OAAO,CAAC,OAAO,uBAAuB,CACnD,CAAC"}
+{"version":3,"file":"impersonalization.shared.schemas.d.ts","sourceRoot":"","sources":["../../../../../src/compliance/privacy/impersonalization.shared.schemas.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AAExB;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AACH,oBAAY,eAAe;IACzB,sDAAsD;IACtD,MAAM,WAAW;IACjB;;;;;;;;;;;;;OAaG;IACH,QAAQ,aAAa;CACtB;AAED;;;GAGG;AACH,eAAO,MAAM,qBAAqB,EAAE,CAAC,CAAC,OAAO,CAAC,OAAO,eAAe,CAC3C,CAAC;AAE1B;;;;;;;;;;;;;;GAcG;AACH,oBAAY,oBAAoB;IAC9B;;;;;;OAMG;IACH,WAAW,gBAAgB;IAC3B;;;;;;OAMG;IACH,wBAAwB,6BAA6B;CACtD;AAED;;;GAGG;AACH,eAAO,MAAM,0BAA0B,EAAE,CAAC,CAAC,OAAO,CAAC,OAAO,oBAAoB,CAChD,CAAC;AAE/B;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAkDG;AACH,oBAAY,uBAAuB;IACjC;;;;;;;;;;;;;;;;;;OAkBG;IACH,YAAY,iBAAiB;IAC7B;;;;;;;;;OASG;IACH,cAAc,mBAAmB;IACjC;;;;;;;;;;OAUG;IACH,gBAAgB,qBAAqB;CACtC;AAED;;;GAGG;AACH,eAAO,MAAM,6BAA6B,EAAE,CAAC,CAAC,OAAO,CAAC,OAAO,uBAAuB,CACnD,CAAC"}

package/dist/esm/compliance/privacy/impersonalization.shared.schemas.js

@@ -29,9 +29,17 @@ export var RetentionStatus;
     RetentionStatus["ACTIVE"] = "active";
     /**
      * Impersonalized-and-retained — personal fields scrubbed in place, the row kept for a
-     * retention obligation. Intended semantics (enforcement wired in a later phase): hidden
-     * and immutable to normal callers; readable only via the audited see-through path;
-     * disposable only by a privileged system op.
+     * retention obligation: hidden and immutable to normal callers, readable only via the audited
+     * `seeRetained` see-through path, disposable only by a privileged system op.
+     *
+     * ENFORCED, not intended. This said "enforcement wired in a later phase" long after the phase
+     * landed, which is worth correcting rather than deleting: a reader deciding whether to trust the
+     * marker would have concluded the row was still visible. The rule has one semantic authority —
+     * `compliance/privacy/retention-hide-predicate.backend` — consumed by both persistence adapters,
+     * the aggregation/charts surface and RAG retrieval, and a guard test fails the suite if any site
+     * hand-writes the predicate again. That single-authority shape exists because the duplicated
+     * version produced two recovered defects: retained rows still counted in every chart, and the
+     * Mongo/Postgres compilers silently disagreed about which rows a NULL marker selected.
      */
     RetentionStatus["RETAINED"] = "retained";
 })(RetentionStatus || (RetentionStatus = {}));

package/dist/esm/compliance/privacy/impersonalization.shared.schemas.js.map

@@ -1 +1 @@
-{"version":3,"file":"impersonalization.shared.schemas.js","sourceRoot":"","sources":["../../../../../src/compliance/privacy/impersonalization.shared.schemas.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AAExB;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AACH,MAAM,CAAN,IAAY,eAUX;AAVD,WAAY,eAAe;IACzB,sDAAsD;IACtD,oCAAiB,CAAA;IACjB;;;;;OAKG;IACH,wCAAqB,CAAA;AACvB,CAAC,EAVW,eAAe,KAAf,eAAe,QAU1B;AAED;;;GAGG;AACH,MAAM,CAAC,MAAM,qBAAqB,GAChC,CAAC,CAAC,IAAI,CAAC,eAAe,CAAC,CAAC;AAE1B;;;;;;;;;;;;;;GAcG;AACH,MAAM,CAAN,IAAY,oBAiBX;AAjBD,WAAY,oBAAoB;IAC9B;;;;;;OAMG;IACH,mDAA2B,CAAA;IAC3B;;;;;;OAMG;IACH,6EAAqD,CAAA;AACvD,CAAC,EAjBW,oBAAoB,KAApB,oBAAoB,QAiB/B;AAED;;;GAGG;AACH,MAAM,CAAC,MAAM,0BAA0B,GACrC,CAAC,CAAC,IAAI,CAAC,oBAAoB,CAAC,CAAC;AAE/B;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAkDG;AACH,MAAM,CAAN,IAAY,uBA4CX;AA5CD,WAAY,uBAAuB;IACjC;;;;;;;;;;;;;;;;;;OAkBG;IACH,wDAA6B,CAAA;IAC7B;;;;;;;;;OASG;IACH,4DAAiC,CAAA;IACjC;;;;;;;;;;OAUG;IACH,gEAAqC,CAAA;AACvC,CAAC,EA5CW,uBAAuB,KAAvB,uBAAuB,QA4ClC;AAED;;;GAGG;AACH,MAAM,CAAC,MAAM,6BAA6B,GACxC,CAAC,CAAC,IAAI,CAAC,uBAAuB,CAAC,CAAC","sourcesContent":["import { z } from 'zod';\n\n/**\n * # Impersonalization — per-record retention lifecycle state\n *\n * `impersonalization` = scrubbing the personal data OUT of a stored record while\n * KEEPING the row, so it can be retained for a legal/audit obligation (GDPR\n * Art. 17(3)(b) legal-obligation carve-out; tax/SOX retention). This is the third\n * erasure outcome alongside hard-delete and leave-as-is.\n *\n * ⚠️ **Not** the anonymous-user concept. `isAnonymizable` / `anonymousUserId` /\n * anonymous-session ownership transposition is an unrelated, opposite-direction\n * mechanism (carrying a pre-auth anonymous session's rows forward to a real user).\n * Never conflate the two. See `.claude/plans/retention-impersonalization-architecture.md`.\n *\n * `RetentionStatus` is the per-record marker the resource factory injects (as the\n * `retentionStatus` field) onto any resource that opts into `retentionPolicy`. The\n * INTENDED contract for a `RETAINED` record is **hidden and immutable by default**\n * (behave-as-deleted), reachable only through the audited `seeRetained` see-through path.\n *\n * **LIVE.** The factory injects the marker (defaulting to `ACTIVE`), the visibility/immutability\n * enforcement and the audited see-through read primitive are all wired and runtime-proven. A\n * `RETAINED` record is hidden from every ordinary read, list, count and chart aggregate, and is\n * immutable to ordinary writes. (This block previously said the enforcement was \"wired in a later\n * phase\"; that became false without being revisited.)\n */\nexport enum RetentionStatus {\n  /** Live record — normal visibility and mutability. */\n  ACTIVE = 'active',\n  /**\n   * Impersonalized-and-retained — personal fields scrubbed in place, the row kept for a\n   * retention obligation. Intended semantics (enforcement wired in a later phase): hidden\n   * and immutable to normal callers; readable only via the audited see-through path;\n   * disposable only by a privileged system op.\n   */\n  RETAINED = 'retained',\n}\n\n/**\n * Zod schema for {@link RetentionStatus}. Explicitly annotated for the\n * `isolatedDeclarations` emit constraint.\n */\nexport const RetentionStatusSchema: z.ZodEnum<typeof RetentionStatus> =\n  z.enum(RetentionStatus);\n\n/**\n * # What erasure DOES to a retention-governed row\n *\n * Retention (the row survives, is marked `RETAINED`, becomes hidden + immutable) and\n * impersonalization (its personal FIELDS are scrubbed) are ORTHOGONAL. A record can be legally\n * retainable while holding no personal data of its own — a financial row that merely POINTS at a\n * person is the canonical case: erasing the subject must not destroy the invoice, but there is\n * nothing on the invoice to scrub, because the name and address live on the linked user.\n *\n * Fusing the two axes forced such a resource to either declare a fake scrub (shipping a record\n * stamped \"impersonalized\" that never was) or forgo retention entirely (letting the cascade destroy a\n * legally-required record). Naming the two outcomes separately removes that false choice AND makes\n * the author's claim auditable: \"this resource holds no personal data\" becomes an explicit, reviewable\n * declaration rather than something a compliance reviewer must infer from an absence of treatments.\n */\nexport enum ErasureRetentionMode {\n  /**\n   * Keep and FREEZE the row; scrub nothing — this resource holds no personal data of its own.\n   *\n   * Declaring a `.impersonalizeWith()` treatment under this mode is a contradiction and fails at\n   * config build: if a field does hold personal data, the resource wants\n   * {@link ErasureRetentionMode.RETAIN_AND_IMPERSONALIZE} instead.\n   */\n  RETAIN_ONLY = 'retain_only',\n  /**\n   * Keep and freeze the row AND scrub the fields marked with `.impersonalizeWith()`.\n   *\n   * Requires at least one field that the writer would ACTUALLY scrub (a `KEEP` treatment, or one on a\n   * never-scrub floor field such as a scope FK, does not count) — otherwise the row would flip to\n   * `RETAINED` with every field intact while claiming to have been impersonalized.\n   */\n  RETAIN_AND_IMPERSONALIZE = 'retain_and_impersonalize',\n}\n\n/**\n * Zod schema for {@link ErasureRetentionMode}. Explicitly annotated for the\n * `isolatedDeclarations` emit constraint.\n */\nexport const ErasureRetentionModeSchema: z.ZodEnum<typeof ErasureRetentionMode> =\n  z.enum(ErasureRetentionMode);\n\n/**\n * **WHOSE SESSION ENDS** when a row of this resource is erased. The second axis of the erasure\n * contract, beside {@link ErasureRetentionMode} (which says what happens to the row).\n *\n * ## This axis is NOT \"is this row about a person?\" — read this before adding a member\n *\n * The two questions look like one and are not, and conflating them cost this vocabulary a member name\n * for months (see the rename note below). Wildo answers them on SEPARATE axes:\n *\n * | question | the axis that answers it |\n * |---|---|\n * | Does this resource hold personal data? | {@link ErasureRetentionMode} — `RETAIN_AND_IMPERSONALIZE` requires at least one field that would actually be scrubbed; `RETAIN_ONLY` means *\"holds no personal data of its own\"*, and a scrub treatment under it fails at config build |\n * | Can a subject-access or portability export answer for it? | `systemAccessPolicy.exportSubject` |\n * | **Whose login session must be revoked?** | **this enum** |\n *\n * A CRM contact, a sales lead, a newsletter subscriber and a patient with no portal account are all\n * **data subjects with no session**. They declare `RETAIN_AND_IMPERSONALIZE` (they hold personal data)\n * and {@link ResourceDataSubjectKind.NO_PRINCIPAL} (there is no session to end) — two independent,\n * truthful answers. Adding a fourth member here for them would make this enum a cross-product of two\n * axes, which is two fields wearing one name.\n *\n * ## Why the third member is `NO_PRINCIPAL` and not `NOT_A_DATA_SUBJECT`\n *\n * It was `NOT_A_DATA_SUBJECT` until 2026-08-28, and the name was the defect. Operationally it always\n * meant *\"revoke nobody\"* — which is exactly right for a CRM contact — while its NAME claimed the row\n * was not about a person, which is false for one. Nothing misbehaved at runtime (the single consumer,\n * `resolveScrubSessionPrincipals`, only ever asked the session question), so the cost landed entirely\n * on readers: a human, and a compliance-document generator, both read the name and would have stated\n * in a published privacy notice that the application holds no personal data in precisely the resource\n * its customers care most about.\n *\n * The industry model this now matches is unambiguous — Intercom deletes \"a user **or lead**\", HubSpot\n * GDPR-deletes a Contact by id or by email, Zendesk \"forgets\" an end-user: an account and a data\n * subject are different objects, and the erasure verb applies to both. Wildo's `eraseSubjectAsSystem`\n * already takes `(resourceType, rowIds)` with no principal, so the capability was never missing.\n *\n * ## Why this must be DECLARED and can never be inferred\n *\n * An erasure of a person must also end that person's session, or a \"deleted\" person keeps browsing on\n * a live token until it expires. The tempting shortcut is to look for a `userId`-shaped foreign key on\n * the erased row and revoke it. **That shortcut is a defect, not an optimisation.** On almost every\n * resource a user foreign key names the OWNER or the ACTOR, not the subject: Wonder Todos' `TODOS` is\n * retention-governed and carries `createdByUserId`, `assignedToUserId` and `escalationContactUserId`,\n * so an inferring implementation would log out the author, the assignee and the escalation contact —\n * three people, none of them the data subject — every time a todo was erased.\n *\n * So the linkage is authored, never guessed, and a resource that can be an erasure subject (i.e. one\n * declaring a `retentionPolicy`) must say which of these it is. Undeclared is refused at config build:\n * nobody has decided yet, and refusing is what forces the decision — the same doctrine the subject\n * EXPORT model applies to an undeclared resource.\n */\nexport enum ResourceDataSubjectKind {\n  /**\n   * Erasing a row of this resource revokes **no session**, because no login is reachable from it.\n   *\n   * Two very different populations share this answer, and the enum is deliberately silent about which\n   * one a given resource is — {@link ErasureRetentionMode} says that:\n   *\n   * - **Not a person at all.** A todo, an invoice, a log line. Any user foreign keys it carries name\n   *   ACTORS — an author, an assignee, an owner, an escalation contact — and revoking their sessions\n   *   because a record was erased would log out three uninvolved people. Such a resource pairs this\n   *   with `RETAIN_ONLY`.\n   * - **A person with no account.** A CRM contact, a sales lead, a subscriber, a patient with no\n   *   portal login. Their rows ARE personal data and carry the full weight of Arts 15–17 and 20 —\n   *   there is simply no session to end. Such a resource pairs this with `RETAIN_AND_IMPERSONALIZE`\n   *   and per-field `.impersonalizeWith()` treatments, and its subject-rights path is the ordinary\n   *   administrative one: `eraseSubjectAsSystem(resourceType, rowIds)` and a subject export.\n   *\n   * The second population is the majority of what a B2B SaaS customer stores about third parties, and\n   * it is what most of a privacy notice describes. Do not read this member as \"nothing to disclose\".\n   */\n  NO_PRINCIPAL = 'no_principal',\n  /**\n   * Rows of this resource ARE the person, and the row's own id IS the session principal: erasing row\n   * `X` ends the session of user `X`. This is `USERS` / `USER_SELF`.\n   *\n   * Note this makes EXPLICIT a revocation that is otherwise only incidental. Erasing a `USERS` row\n   * already logs the user out today — but only as a side effect of the retention row-hide (the auth\n   * fronts re-read the user, find the row hidden, and 401) plus the scrub write bumping\n   * `authorizationVersion`. Nothing on the erasure path ever WROTE a revocation, so the guarantee\n   * lived entirely in the behaviour of two unrelated mechanisms.\n   */\n  SELF_PRINCIPAL = 'self_principal',\n  /**\n   * Rows of this resource are a person whose login lives in a DIFFERENT `USERS` row — a Patient, an\n   * Employee, a Member record that a human signs in as. `sessionPrincipalField` names the field\n   * holding that user's id.\n   *\n   * The named field must carry no `.impersonalizeWith()` treatment. Not because the revocation would\n   * break — the principal is resolved BEFORE the scrub, so a scrubbed field is still readable when it\n   * matters — but because declaring one field to be BOTH the link to a person and personal data to\n   * destroy is self-contradictory, and it leaves the retained row with no way to say whose session was\n   * ended. Enforced at config build.\n   */\n  LINKED_PRINCIPAL = 'linked_principal',\n}\n\n/**\n * Zod schema for {@link ResourceDataSubjectKind}. Explicitly annotated for the\n * `isolatedDeclarations` emit constraint.\n */\nexport const ResourceDataSubjectKindSchema: z.ZodEnum<typeof ResourceDataSubjectKind> =\n  z.enum(ResourceDataSubjectKind);\n"]}
+{"version":3,"file":"impersonalization.shared.schemas.js","sourceRoot":"","sources":["../../../../../src/compliance/privacy/impersonalization.shared.schemas.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AAExB;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AACH,MAAM,CAAN,IAAY,eAkBX;AAlBD,WAAY,eAAe;IACzB,sDAAsD;IACtD,oCAAiB,CAAA;IACjB;;;;;;;;;;;;;OAaG;IACH,wCAAqB,CAAA;AACvB,CAAC,EAlBW,eAAe,KAAf,eAAe,QAkB1B;AAED;;;GAGG;AACH,MAAM,CAAC,MAAM,qBAAqB,GAChC,CAAC,CAAC,IAAI,CAAC,eAAe,CAAC,CAAC;AAE1B;;;;;;;;;;;;;;GAcG;AACH,MAAM,CAAN,IAAY,oBAiBX;AAjBD,WAAY,oBAAoB;IAC9B;;;;;;OAMG;IACH,mDAA2B,CAAA;IAC3B;;;;;;OAMG;IACH,6EAAqD,CAAA;AACvD,CAAC,EAjBW,oBAAoB,KAApB,oBAAoB,QAiB/B;AAED;;;GAGG;AACH,MAAM,CAAC,MAAM,0BAA0B,GACrC,CAAC,CAAC,IAAI,CAAC,oBAAoB,CAAC,CAAC;AAE/B;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAkDG;AACH,MAAM,CAAN,IAAY,uBA4CX;AA5CD,WAAY,uBAAuB;IACjC;;;;;;;;;;;;;;;;;;OAkBG;IACH,wDAA6B,CAAA;IAC7B;;;;;;;;;OASG;IACH,4DAAiC,CAAA;IACjC;;;;;;;;;;OAUG;IACH,gEAAqC,CAAA;AACvC,CAAC,EA5CW,uBAAuB,KAAvB,uBAAuB,QA4ClC;AAED;;;GAGG;AACH,MAAM,CAAC,MAAM,6BAA6B,GACxC,CAAC,CAAC,IAAI,CAAC,uBAAuB,CAAC,CAAC","sourcesContent":["import { z } from 'zod';\n\n/**\n * # Impersonalization — per-record retention lifecycle state\n *\n * `impersonalization` = scrubbing the personal data OUT of a stored record while\n * KEEPING the row, so it can be retained for a legal/audit obligation (GDPR\n * Art. 17(3)(b) legal-obligation carve-out; tax/SOX retention). This is the third\n * erasure outcome alongside hard-delete and leave-as-is.\n *\n * ⚠️ **Not** the anonymous-user concept. `isAnonymizable` / `anonymousUserId` /\n * anonymous-session ownership transposition is an unrelated, opposite-direction\n * mechanism (carrying a pre-auth anonymous session's rows forward to a real user).\n * Never conflate the two. See `.claude/plans/retention-impersonalization-architecture.md`.\n *\n * `RetentionStatus` is the per-record marker the resource factory injects (as the\n * `retentionStatus` field) onto any resource that opts into `retentionPolicy`. The\n * INTENDED contract for a `RETAINED` record is **hidden and immutable by default**\n * (behave-as-deleted), reachable only through the audited `seeRetained` see-through path.\n *\n * **LIVE.** The factory injects the marker (defaulting to `ACTIVE`), the visibility/immutability\n * enforcement and the audited see-through read primitive are all wired and runtime-proven. A\n * `RETAINED` record is hidden from every ordinary read, list, count and chart aggregate, and is\n * immutable to ordinary writes. (This block previously said the enforcement was \"wired in a later\n * phase\"; that became false without being revisited.)\n */\nexport enum RetentionStatus {\n  /** Live record — normal visibility and mutability. */\n  ACTIVE = 'active',\n  /**\n   * Impersonalized-and-retained — personal fields scrubbed in place, the row kept for a\n   * retention obligation: hidden and immutable to normal callers, readable only via the audited\n   * `seeRetained` see-through path, disposable only by a privileged system op.\n   *\n   * ENFORCED, not intended. This said \"enforcement wired in a later phase\" long after the phase\n   * landed, which is worth correcting rather than deleting: a reader deciding whether to trust the\n   * marker would have concluded the row was still visible. The rule has one semantic authority —\n   * `compliance/privacy/retention-hide-predicate.backend` — consumed by both persistence adapters,\n   * the aggregation/charts surface and RAG retrieval, and a guard test fails the suite if any site\n   * hand-writes the predicate again. That single-authority shape exists because the duplicated\n   * version produced two recovered defects: retained rows still counted in every chart, and the\n   * Mongo/Postgres compilers silently disagreed about which rows a NULL marker selected.\n   */\n  RETAINED = 'retained',\n}\n\n/**\n * Zod schema for {@link RetentionStatus}. Explicitly annotated for the\n * `isolatedDeclarations` emit constraint.\n */\nexport const RetentionStatusSchema: z.ZodEnum<typeof RetentionStatus> =\n  z.enum(RetentionStatus);\n\n/**\n * # What erasure DOES to a retention-governed row\n *\n * Retention (the row survives, is marked `RETAINED`, becomes hidden + immutable) and\n * impersonalization (its personal FIELDS are scrubbed) are ORTHOGONAL. A record can be legally\n * retainable while holding no personal data of its own — a financial row that merely POINTS at a\n * person is the canonical case: erasing the subject must not destroy the invoice, but there is\n * nothing on the invoice to scrub, because the name and address live on the linked user.\n *\n * Fusing the two axes forced such a resource to either declare a fake scrub (shipping a record\n * stamped \"impersonalized\" that never was) or forgo retention entirely (letting the cascade destroy a\n * legally-required record). Naming the two outcomes separately removes that false choice AND makes\n * the author's claim auditable: \"this resource holds no personal data\" becomes an explicit, reviewable\n * declaration rather than something a compliance reviewer must infer from an absence of treatments.\n */\nexport enum ErasureRetentionMode {\n  /**\n   * Keep and FREEZE the row; scrub nothing — this resource holds no personal data of its own.\n   *\n   * Declaring a `.impersonalizeWith()` treatment under this mode is a contradiction and fails at\n   * config build: if a field does hold personal data, the resource wants\n   * {@link ErasureRetentionMode.RETAIN_AND_IMPERSONALIZE} instead.\n   */\n  RETAIN_ONLY = 'retain_only',\n  /**\n   * Keep and freeze the row AND scrub the fields marked with `.impersonalizeWith()`.\n   *\n   * Requires at least one field that the writer would ACTUALLY scrub (a `KEEP` treatment, or one on a\n   * never-scrub floor field such as a scope FK, does not count) — otherwise the row would flip to\n   * `RETAINED` with every field intact while claiming to have been impersonalized.\n   */\n  RETAIN_AND_IMPERSONALIZE = 'retain_and_impersonalize',\n}\n\n/**\n * Zod schema for {@link ErasureRetentionMode}. Explicitly annotated for the\n * `isolatedDeclarations` emit constraint.\n */\nexport const ErasureRetentionModeSchema: z.ZodEnum<typeof ErasureRetentionMode> =\n  z.enum(ErasureRetentionMode);\n\n/**\n * **WHOSE SESSION ENDS** when a row of this resource is erased. The second axis of the erasure\n * contract, beside {@link ErasureRetentionMode} (which says what happens to the row).\n *\n * ## This axis is NOT \"is this row about a person?\" — read this before adding a member\n *\n * The two questions look like one and are not, and conflating them cost this vocabulary a member name\n * for months (see the rename note below). Wildo answers them on SEPARATE axes:\n *\n * | question | the axis that answers it |\n * |---|---|\n * | Does this resource hold personal data? | {@link ErasureRetentionMode} — `RETAIN_AND_IMPERSONALIZE` requires at least one field that would actually be scrubbed; `RETAIN_ONLY` means *\"holds no personal data of its own\"*, and a scrub treatment under it fails at config build |\n * | Can a subject-access or portability export answer for it? | `systemAccessPolicy.exportSubject` |\n * | **Whose login session must be revoked?** | **this enum** |\n *\n * A CRM contact, a sales lead, a newsletter subscriber and a patient with no portal account are all\n * **data subjects with no session**. They declare `RETAIN_AND_IMPERSONALIZE` (they hold personal data)\n * and {@link ResourceDataSubjectKind.NO_PRINCIPAL} (there is no session to end) — two independent,\n * truthful answers. Adding a fourth member here for them would make this enum a cross-product of two\n * axes, which is two fields wearing one name.\n *\n * ## Why the third member is `NO_PRINCIPAL` and not `NOT_A_DATA_SUBJECT`\n *\n * It was `NOT_A_DATA_SUBJECT` until 2026-08-28, and the name was the defect. Operationally it always\n * meant *\"revoke nobody\"* — which is exactly right for a CRM contact — while its NAME claimed the row\n * was not about a person, which is false for one. Nothing misbehaved at runtime (the single consumer,\n * `resolveScrubSessionPrincipals`, only ever asked the session question), so the cost landed entirely\n * on readers: a human, and a compliance-document generator, both read the name and would have stated\n * in a published privacy notice that the application holds no personal data in precisely the resource\n * its customers care most about.\n *\n * The industry model this now matches is unambiguous — Intercom deletes \"a user **or lead**\", HubSpot\n * GDPR-deletes a Contact by id or by email, Zendesk \"forgets\" an end-user: an account and a data\n * subject are different objects, and the erasure verb applies to both. Wildo's `eraseSubjectAsSystem`\n * already takes `(resourceType, rowIds)` with no principal, so the capability was never missing.\n *\n * ## Why this must be DECLARED and can never be inferred\n *\n * An erasure of a person must also end that person's session, or a \"deleted\" person keeps browsing on\n * a live token until it expires. The tempting shortcut is to look for a `userId`-shaped foreign key on\n * the erased row and revoke it. **That shortcut is a defect, not an optimisation.** On almost every\n * resource a user foreign key names the OWNER or the ACTOR, not the subject: Wonder Todos' `TODOS` is\n * retention-governed and carries `createdByUserId`, `assignedToUserId` and `escalationContactUserId`,\n * so an inferring implementation would log out the author, the assignee and the escalation contact —\n * three people, none of them the data subject — every time a todo was erased.\n *\n * So the linkage is authored, never guessed, and a resource that can be an erasure subject (i.e. one\n * declaring a `retentionPolicy`) must say which of these it is. Undeclared is refused at config build:\n * nobody has decided yet, and refusing is what forces the decision — the same doctrine the subject\n * EXPORT model applies to an undeclared resource.\n */\nexport enum ResourceDataSubjectKind {\n  /**\n   * Erasing a row of this resource revokes **no session**, because no login is reachable from it.\n   *\n   * Two very different populations share this answer, and the enum is deliberately silent about which\n   * one a given resource is — {@link ErasureRetentionMode} says that:\n   *\n   * - **Not a person at all.** A todo, an invoice, a log line. Any user foreign keys it carries name\n   *   ACTORS — an author, an assignee, an owner, an escalation contact — and revoking their sessions\n   *   because a record was erased would log out three uninvolved people. Such a resource pairs this\n   *   with `RETAIN_ONLY`.\n   * - **A person with no account.** A CRM contact, a sales lead, a subscriber, a patient with no\n   *   portal login. Their rows ARE personal data and carry the full weight of Arts 15–17 and 20 —\n   *   there is simply no session to end. Such a resource pairs this with `RETAIN_AND_IMPERSONALIZE`\n   *   and per-field `.impersonalizeWith()` treatments, and its subject-rights path is the ordinary\n   *   administrative one: `eraseSubjectAsSystem(resourceType, rowIds)` and a subject export.\n   *\n   * The second population is the majority of what a B2B SaaS customer stores about third parties, and\n   * it is what most of a privacy notice describes. Do not read this member as \"nothing to disclose\".\n   */\n  NO_PRINCIPAL = 'no_principal',\n  /**\n   * Rows of this resource ARE the person, and the row's own id IS the session principal: erasing row\n   * `X` ends the session of user `X`. This is `USERS` / `USER_SELF`.\n   *\n   * Note this makes EXPLICIT a revocation that is otherwise only incidental. Erasing a `USERS` row\n   * already logs the user out today — but only as a side effect of the retention row-hide (the auth\n   * fronts re-read the user, find the row hidden, and 401) plus the scrub write bumping\n   * `authorizationVersion`. Nothing on the erasure path ever WROTE a revocation, so the guarantee\n   * lived entirely in the behaviour of two unrelated mechanisms.\n   */\n  SELF_PRINCIPAL = 'self_principal',\n  /**\n   * Rows of this resource are a person whose login lives in a DIFFERENT `USERS` row — a Patient, an\n   * Employee, a Member record that a human signs in as. `sessionPrincipalField` names the field\n   * holding that user's id.\n   *\n   * The named field must carry no `.impersonalizeWith()` treatment. Not because the revocation would\n   * break — the principal is resolved BEFORE the scrub, so a scrubbed field is still readable when it\n   * matters — but because declaring one field to be BOTH the link to a person and personal data to\n   * destroy is self-contradictory, and it leaves the retained row with no way to say whose session was\n   * ended. Enforced at config build.\n   */\n  LINKED_PRINCIPAL = 'linked_principal',\n}\n\n/**\n * Zod schema for {@link ResourceDataSubjectKind}. Explicitly annotated for the\n * `isolatedDeclarations` emit constraint.\n */\nexport const ResourceDataSubjectKindSchema: z.ZodEnum<typeof ResourceDataSubjectKind> =\n  z.enum(ResourceDataSubjectKind);\n"]}

package/dist/esm/compliance/privacy/operating-jurisdictions.shared.schemas.d.ts

@@ -0,0 +1,93 @@
+import { z } from 'zod';
+/**
+ * WHERE this application operates, as the one source every compliance surface reads (issue #229).
+ *
+ * ## The hole this closes
+ *
+ * Measured 2026-09-02: nothing in application configuration said which jurisdictions an application
+ * reaches. `jurisdiction` appeared only as prose, as the Art. 27 origin of a representative, and as
+ * `jurisdictionRefs` on a governed-document release. The assurance programme's `jurisdictionSlugs`
+ * were free text supplied per run BY THE PRODUCING MODEL — which is the opposite of a source: it is
+ * unverifiable, it can differ between two runs of the same application, and nothing downstream could
+ * disagree with it.
+ *
+ * ## Why a sibling of `operatorComplianceIdentity` rather than a field inside it
+ *
+ * Both describe legal posture, so folding this in is tempting. It is the wrong shape for one reason
+ * that outranks the tidiness: that schema is all-or-nothing inside, so a jurisdiction could not be
+ * recorded until the lawful bases were settled with counsel. Where you sell is known long before why
+ * you may process — and issue #228 exists precisely because filling the entity must never block.
+ *
+ * Keeping them siblings means each is answerable the day it is known.
+ *
+ * ## Why an open slug and not an enum
+ *
+ * A jurisdiction is a genuinely open identifier: an application may operate anywhere, and an enum
+ * would have to be widened before an operator could state the truth about their own product. That is
+ * the "genuinely open app/provider/resource identifier" exemption in the semantic-literal rule, not a
+ * shortcut around it. The shape is constrained; the membership is not.
+ *
+ * The framework's ability to KNOW what a declared jurisdiction requires is a separate question, and
+ * a deliberately visible one — see {@link JURISDICTION_CONTAINMENT} and the coverage report that
+ * consumes it. An application may always declare where it operates; Wildo says plainly where it has
+ * nothing to offer.
+ */
+export declare const JurisdictionSlugSchema: z.ZodString;
+export type JurisdictionSlug = z.infer<typeof JurisdictionSlugSchema>;
+/**
+ * One jurisdiction this application operates in, and why it reaches the product.
+ *
+ * `basis` is REQUIRED, and it is the half that makes the declaration mean anything — the same
+ * argument the sibling schemas make for `assessmentNote` on a legitimate-interests basis and for
+ * `gatedProcessing` on a consent gate. "eu" alone does not say whether the operator is established
+ * there, sells there, or merely holds data about people there, and those imply different obligations.
+ *
+ * It is free prose deliberately. Nothing structured exists to key it to, and inventing a closed
+ * vocabulary of reasons would be a legal taxonomy nobody reviewed.
+ */
+export declare const OperatingJurisdictionSchema: z.ZodObject<{
+    jurisdictionSlug: z.ZodString;
+    /** Why this jurisdiction reaches the product — "customers established here", "data subjects resident here". */
+    basis: z.ZodString;
+}, z.core.$strict>;
+export type OperatingJurisdiction = z.infer<typeof OperatingJurisdictionSchema>;
+/**
+ * The jurisdictions this application operates in.
+ *
+ * ## Absent is UNDECLARED, and an empty list is not offered
+ *
+ * The sibling `clientStorage` inventory distinguishes absent ("not inventoried") from an empty array
+ * ("this surface sets nothing"), because there both are meaningful. Here only one is: every product
+ * operates somewhere, so an empty list would be a claim nobody could mean. `min(1)` therefore refuses
+ * it, and the whole declaration stays optional at the configuration level — absence is the honest
+ * "nobody has answered", and every consumer must render it as that rather than as "nowhere".
+ */
+export declare const ApplicationOperatingJurisdictionsSchema: z.ZodObject<{
+    jurisdictions: z.ZodArray<z.ZodObject<{
+        jurisdictionSlug: z.ZodString;
+        /** Why this jurisdiction reaches the product — "customers established here", "data subjects resident here". */
+        basis: z.ZodString;
+    }, z.core.$strict>>;
+}, z.core.$strict>;
+export type ApplicationOperatingJurisdictions = z.infer<typeof ApplicationOperatingJurisdictionsSchema>;
+/**
+ * Which jurisdictions a broader one contains, so a source addressing the broader one answers for them.
+ *
+ * Without this, an application declaring `fr` would be reported as uncovered while the GDPR source
+ * plainly reaches it — over-warning, which is the failure mode that trains a reader to skim past the
+ * warnings that matter. Subdivisions need no table: `us-ca` is contained by `us` by construction, and
+ * that rule is applied in code rather than enumerated here.
+ *
+ * ⚠️ EU membership is a legal fact with a review trigger, not a convenience list: it changes when a
+ * state accedes or withdraws, and it has done both. Verified against the 27 members as of 2026-09-02.
+ * Nothing derives it, so a change is a deliberate edit here.
+ */
+export declare const JURISDICTION_CONTAINMENT: Readonly<Record<string, readonly string[]>>;
+/**
+ * Does a source addressing `reach` answer for an application operating in `declared`?
+ *
+ * Three ways, and the order is deliberate — exact first, because it is the common case and the other
+ * two are refinements of it.
+ */
+export declare function jurisdictionReachCovers(reach: string, declared: string): boolean;
+//# sourceMappingURL=operating-jurisdictions.shared.schemas.d.ts.map

package/dist/esm/compliance/privacy/operating-jurisdictions.shared.schemas.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"operating-jurisdictions.shared.schemas.d.ts","sourceRoot":"","sources":["../../../../../src/compliance/privacy/operating-jurisdictions.shared.schemas.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AAExB;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAgCG;AACH,eAAO,MAAM,sBAAsB,aAQhC,CAAC;AACJ,MAAM,MAAM,gBAAgB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,sBAAsB,CAAC,CAAC;AAEtE;;;;;;;;;;GAUG;AACH,eAAO,MAAM,2BAA2B;;IAEtC,+GAA+G;;kBAE/G,CAAC;AACH,MAAM,MAAM,qBAAqB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,2BAA2B,CAAC,CAAC;AAEhF;;;;;;;;;;GAUG;AACH,eAAO,MAAM,uCAAuC;;;QAhBlD,+GAA+G;;;kBAgC7G,CAAC;AACL,MAAM,MAAM,iCAAiC,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,uCAAuC,CAAC,CAAC;AAExG;;;;;;;;;;;GAWG;AACH,eAAO,MAAM,wBAAwB,EAAE,QAAQ,CAAC,MAAM,CAAC,MAAM,EAAE,SAAS,MAAM,EAAE,CAAC,CAK/E,CAAC;AAEH;;;;;GAKG;AACH,wBAAgB,uBAAuB,CAAC,KAAK,EAAE,MAAM,EAAE,QAAQ,EAAE,MAAM,GAAG,OAAO,CAOhF"}

package/dist/esm/compliance/privacy/operating-jurisdictions.shared.schemas.js

@@ -0,0 +1,116 @@
+import { z } from 'zod';
+/**
+ * WHERE this application operates, as the one source every compliance surface reads (issue #229).
+ *
+ * ## The hole this closes
+ *
+ * Measured 2026-09-02: nothing in application configuration said which jurisdictions an application
+ * reaches. `jurisdiction` appeared only as prose, as the Art. 27 origin of a representative, and as
+ * `jurisdictionRefs` on a governed-document release. The assurance programme's `jurisdictionSlugs`
+ * were free text supplied per run BY THE PRODUCING MODEL — which is the opposite of a source: it is
+ * unverifiable, it can differ between two runs of the same application, and nothing downstream could
+ * disagree with it.
+ *
+ * ## Why a sibling of `operatorComplianceIdentity` rather than a field inside it
+ *
+ * Both describe legal posture, so folding this in is tempting. It is the wrong shape for one reason
+ * that outranks the tidiness: that schema is all-or-nothing inside, so a jurisdiction could not be
+ * recorded until the lawful bases were settled with counsel. Where you sell is known long before why
+ * you may process — and issue #228 exists precisely because filling the entity must never block.
+ *
+ * Keeping them siblings means each is answerable the day it is known.
+ *
+ * ## Why an open slug and not an enum
+ *
+ * A jurisdiction is a genuinely open identifier: an application may operate anywhere, and an enum
+ * would have to be widened before an operator could state the truth about their own product. That is
+ * the "genuinely open app/provider/resource identifier" exemption in the semantic-literal rule, not a
+ * shortcut around it. The shape is constrained; the membership is not.
+ *
+ * The framework's ability to KNOW what a declared jurisdiction requires is a separate question, and
+ * a deliberately visible one — see {@link JURISDICTION_CONTAINMENT} and the coverage report that
+ * consumes it. An application may always declare where it operates; Wildo says plainly where it has
+ * nothing to offer.
+ */
+export const JurisdictionSlugSchema = z
+    .string()
+    .trim()
+    .regex(/^[a-z]{2}(-[a-z0-9]{1,8})?$/u, 'a jurisdiction slug is an ISO 3166-1 alpha-2 country code, a supranational code such as "eu", '
+    + 'optionally with a subdivision suffix such as "us-ca" — lowercase, because a slug that differs '
+    + 'only by case is a second identifier for one place');
+/**
+ * One jurisdiction this application operates in, and why it reaches the product.
+ *
+ * `basis` is REQUIRED, and it is the half that makes the declaration mean anything — the same
+ * argument the sibling schemas make for `assessmentNote` on a legitimate-interests basis and for
+ * `gatedProcessing` on a consent gate. "eu" alone does not say whether the operator is established
+ * there, sells there, or merely holds data about people there, and those imply different obligations.
+ *
+ * It is free prose deliberately. Nothing structured exists to key it to, and inventing a closed
+ * vocabulary of reasons would be a legal taxonomy nobody reviewed.
+ */
+export const OperatingJurisdictionSchema = z.strictObject({
+    jurisdictionSlug: JurisdictionSlugSchema,
+    /** Why this jurisdiction reaches the product — "customers established here", "data subjects resident here". */
+    basis: z.string().trim().min(1),
+});
+/**
+ * The jurisdictions this application operates in.
+ *
+ * ## Absent is UNDECLARED, and an empty list is not offered
+ *
+ * The sibling `clientStorage` inventory distinguishes absent ("not inventoried") from an empty array
+ * ("this surface sets nothing"), because there both are meaningful. Here only one is: every product
+ * operates somewhere, so an empty list would be a claim nobody could mean. `min(1)` therefore refuses
+ * it, and the whole declaration stays optional at the configuration level — absence is the honest
+ * "nobody has answered", and every consumer must render it as that rather than as "nowhere".
+ */
+export const ApplicationOperatingJurisdictionsSchema = z
+    .strictObject({
+    jurisdictions: z.array(OperatingJurisdictionSchema).min(1),
+})
+    .superRefine((declaration, context) => {
+    const slugs = declaration.jurisdictions.map((entry) => entry.jurisdictionSlug);
+    const duplicates = slugs.filter((slug, index) => slugs.indexOf(slug) !== index);
+    if (duplicates.length > 0) {
+        context.addIssue({
+            code: 'custom',
+            path: ['jurisdictions'],
+            message: `jurisdiction ${[...new Set(duplicates)].map((slug) => `"${slug}"`).join(', ')} is declared more than once — `
+                + 'one place has one basis, and two entries would let a document cite whichever suits the clause',
+        });
+    }
+});
+/**
+ * Which jurisdictions a broader one contains, so a source addressing the broader one answers for them.
+ *
+ * Without this, an application declaring `fr` would be reported as uncovered while the GDPR source
+ * plainly reaches it — over-warning, which is the failure mode that trains a reader to skim past the
+ * warnings that matter. Subdivisions need no table: `us-ca` is contained by `us` by construction, and
+ * that rule is applied in code rather than enumerated here.
+ *
+ * ⚠️ EU membership is a legal fact with a review trigger, not a convenience list: it changes when a
+ * state accedes or withdraws, and it has done both. Verified against the 27 members as of 2026-09-02.
+ * Nothing derives it, so a change is a deliberate edit here.
+ */
+export const JURISDICTION_CONTAINMENT = Object.freeze({
+    eu: Object.freeze([
+        'at', 'be', 'bg', 'cy', 'cz', 'de', 'dk', 'ee', 'es', 'fi', 'fr', 'gr', 'hr', 'hu',
+        'ie', 'it', 'lt', 'lu', 'lv', 'mt', 'nl', 'pl', 'pt', 'ro', 'se', 'si', 'sk',
+    ]),
+});
+/**
+ * Does a source addressing `reach` answer for an application operating in `declared`?
+ *
+ * Three ways, and the order is deliberate — exact first, because it is the common case and the other
+ * two are refinements of it.
+ */
+export function jurisdictionReachCovers(reach, declared) {
+    if (reach === declared)
+        return true;
+    // A source addressing the whole of `us` answers for `us-ca`; one addressing only `us-ca` does not answer for `us`.
+    if (declared.startsWith(`${reach}-`))
+        return true;
+    return (JURISDICTION_CONTAINMENT[reach] ?? []).some((member) => member === declared || declared.startsWith(`${member}-`));
+}
+//# sourceMappingURL=operating-jurisdictions.shared.schemas.js.map

package/dist/esm/compliance/privacy/operating-jurisdictions.shared.schemas.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"operating-jurisdictions.shared.schemas.js","sourceRoot":"","sources":["../../../../../src/compliance/privacy/operating-jurisdictions.shared.schemas.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AAExB;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAgCG;AACH,MAAM,CAAC,MAAM,sBAAsB,GAAG,CAAC;KACpC,MAAM,EAAE;KACR,IAAI,EAAE;KACN,KAAK,CACJ,8BAA8B,EAC9B,gGAAgG;MAC5F,gGAAgG;MAChG,mDAAmD,CACxD,CAAC;AAGJ;;;;;;;;;;GAUG;AACH,MAAM,CAAC,MAAM,2BAA2B,GAAG,CAAC,CAAC,YAAY,CAAC;IACxD,gBAAgB,EAAE,sBAAsB;IACxC,+GAA+G;IAC/G,KAAK,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,IAAI,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC;CAChC,CAAC,CAAC;AAGH;;;;;;;;;;GAUG;AACH,MAAM,CAAC,MAAM,uCAAuC,GAAG,CAAC;KACrD,YAAY,CAAC;IACZ,aAAa,EAAE,CAAC,CAAC,KAAK,CAAC,2BAA2B,CAAC,CAAC,GAAG,CAAC,CAAC,CAAC;CAC3D,CAAC;KACD,WAAW,CAAC,CAAC,WAAW,EAAE,OAAO,EAAE,EAAE;IACpC,MAAM,KAAK,GAAG,WAAW,CAAC,aAAa,CAAC,GAAG,CAAC,CAAC,KAAK,EAAE,EAAE,CAAC,KAAK,CAAC,gBAAgB,CAAC,CAAC;IAC/E,MAAM,UAAU,GAAG,KAAK,CAAC,MAAM,CAAC,CAAC,IAAI,EAAE,KAAK,EAAE,EAAE,CAAC,KAAK,CAAC,OAAO,CAAC,IAAI,CAAC,KAAK,KAAK,CAAC,CAAC;IAChF,IAAI,UAAU,CAAC,MAAM,GAAG,CAAC,EAAE,CAAC;QAC1B,OAAO,CAAC,QAAQ,CAAC;YACf,IAAI,EAAE,QAAQ;YACd,IAAI,EAAE,CAAC,eAAe,CAAC;YACvB,OAAO,EACL,gBAAgB,CAAC,GAAG,IAAI,GAAG,CAAC,UAAU,CAAC,CAAC,CAAC,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,IAAI,IAAI,GAAG,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC,gCAAgC;kBAC5G,+FAA+F;SACpG,CAAC,CAAC;IACL,CAAC;AACH,CAAC,CAAC,CAAC;AAGL;;;;;;;;;;;GAWG;AACH,MAAM,CAAC,MAAM,wBAAwB,GAAgD,MAAM,CAAC,MAAM,CAAC;IACjG,EAAE,EAAE,MAAM,CAAC,MAAM,CAAC;QAChB,IAAI,EAAE,IAAI,EAAE,IAAI,EAAE,IAAI,EAAE,IAAI,EAAE,IAAI,EAAE,IAAI,EAAE,IAAI,EAAE,IAAI,EAAE,IAAI,EAAE,IAAI,EAAE,IAAI,EAAE,IAAI,EAAE,IAAI;QAClF,IAAI,EAAE,IAAI,EAAE,IAAI,EAAE,IAAI,EAAE,IAAI,EAAE,IAAI,EAAE,IAAI,EAAE,IAAI,EAAE,IAAI,EAAE,IAAI,EAAE,IAAI,EAAE,IAAI,EAAE,IAAI;KAC7E,CAAC;CACH,CAAC,CAAC;AAEH;;;;;GAKG;AACH,MAAM,UAAU,uBAAuB,CAAC,KAAa,EAAE,QAAgB;IACrE,IAAI,KAAK,KAAK,QAAQ;QAAE,OAAO,IAAI,CAAC;IACpC,mHAAmH;IACnH,IAAI,QAAQ,CAAC,UAAU,CAAC,GAAG,KAAK,GAAG,CAAC;QAAE,OAAO,IAAI,CAAC;IAClD,OAAO,CAAC,wBAAwB,CAAC,KAAK,CAAC,IAAI,EAAE,CAAC,CAAC,IAAI,CACjD,CAAC,MAAM,EAAE,EAAE,CAAC,MAAM,KAAK,QAAQ,IAAI,QAAQ,CAAC,UAAU,CAAC,GAAG,MAAM,GAAG,CAAC,CACrE,CAAC;AACJ,CAAC","sourcesContent":["import { z } from 'zod';\n\n/**\n * WHERE this application operates, as the one source every compliance surface reads (issue #229).\n *\n * ## The hole this closes\n *\n * Measured 2026-09-02: nothing in application configuration said which jurisdictions an application\n * reaches. `jurisdiction` appeared only as prose, as the Art. 27 origin of a representative, and as\n * `jurisdictionRefs` on a governed-document release. The assurance programme's `jurisdictionSlugs`\n * were free text supplied per run BY THE PRODUCING MODEL — which is the opposite of a source: it is\n * unverifiable, it can differ between two runs of the same application, and nothing downstream could\n * disagree with it.\n *\n * ## Why a sibling of `operatorComplianceIdentity` rather than a field inside it\n *\n * Both describe legal posture, so folding this in is tempting. It is the wrong shape for one reason\n * that outranks the tidiness: that schema is all-or-nothing inside, so a jurisdiction could not be\n * recorded until the lawful bases were settled with counsel. Where you sell is known long before why\n * you may process — and issue #228 exists precisely because filling the entity must never block.\n *\n * Keeping them siblings means each is answerable the day it is known.\n *\n * ## Why an open slug and not an enum\n *\n * A jurisdiction is a genuinely open identifier: an application may operate anywhere, and an enum\n * would have to be widened before an operator could state the truth about their own product. That is\n * the \"genuinely open app/provider/resource identifier\" exemption in the semantic-literal rule, not a\n * shortcut around it. The shape is constrained; the membership is not.\n *\n * The framework's ability to KNOW what a declared jurisdiction requires is a separate question, and\n * a deliberately visible one — see {@link JURISDICTION_CONTAINMENT} and the coverage report that\n * consumes it. An application may always declare where it operates; Wildo says plainly where it has\n * nothing to offer.\n */\nexport const JurisdictionSlugSchema = z\n  .string()\n  .trim()\n  .regex(\n    /^[a-z]{2}(-[a-z0-9]{1,8})?$/u,\n    'a jurisdiction slug is an ISO 3166-1 alpha-2 country code, a supranational code such as \"eu\", '\n      + 'optionally with a subdivision suffix such as \"us-ca\" — lowercase, because a slug that differs '\n      + 'only by case is a second identifier for one place',\n  );\nexport type JurisdictionSlug = z.infer<typeof JurisdictionSlugSchema>;\n\n/**\n * One jurisdiction this application operates in, and why it reaches the product.\n *\n * `basis` is REQUIRED, and it is the half that makes the declaration mean anything — the same\n * argument the sibling schemas make for `assessmentNote` on a legitimate-interests basis and for\n * `gatedProcessing` on a consent gate. \"eu\" alone does not say whether the operator is established\n * there, sells there, or merely holds data about people there, and those imply different obligations.\n *\n * It is free prose deliberately. Nothing structured exists to key it to, and inventing a closed\n * vocabulary of reasons would be a legal taxonomy nobody reviewed.\n */\nexport const OperatingJurisdictionSchema = z.strictObject({\n  jurisdictionSlug: JurisdictionSlugSchema,\n  /** Why this jurisdiction reaches the product — \"customers established here\", \"data subjects resident here\". */\n  basis: z.string().trim().min(1),\n});\nexport type OperatingJurisdiction = z.infer<typeof OperatingJurisdictionSchema>;\n\n/**\n * The jurisdictions this application operates in.\n *\n * ## Absent is UNDECLARED, and an empty list is not offered\n *\n * The sibling `clientStorage` inventory distinguishes absent (\"not inventoried\") from an empty array\n * (\"this surface sets nothing\"), because there both are meaningful. Here only one is: every product\n * operates somewhere, so an empty list would be a claim nobody could mean. `min(1)` therefore refuses\n * it, and the whole declaration stays optional at the configuration level — absence is the honest\n * \"nobody has answered\", and every consumer must render it as that rather than as \"nowhere\".\n */\nexport const ApplicationOperatingJurisdictionsSchema = z\n  .strictObject({\n    jurisdictions: z.array(OperatingJurisdictionSchema).min(1),\n  })\n  .superRefine((declaration, context) => {\n    const slugs = declaration.jurisdictions.map((entry) => entry.jurisdictionSlug);\n    const duplicates = slugs.filter((slug, index) => slugs.indexOf(slug) !== index);\n    if (duplicates.length > 0) {\n      context.addIssue({\n        code: 'custom',\n        path: ['jurisdictions'],\n        message:\n          `jurisdiction ${[...new Set(duplicates)].map((slug) => `\"${slug}\"`).join(', ')} is declared more than once — `\n          + 'one place has one basis, and two entries would let a document cite whichever suits the clause',\n      });\n    }\n  });\nexport type ApplicationOperatingJurisdictions = z.infer<typeof ApplicationOperatingJurisdictionsSchema>;\n\n/**\n * Which jurisdictions a broader one contains, so a source addressing the broader one answers for them.\n *\n * Without this, an application declaring `fr` would be reported as uncovered while the GDPR source\n * plainly reaches it — over-warning, which is the failure mode that trains a reader to skim past the\n * warnings that matter. Subdivisions need no table: `us-ca` is contained by `us` by construction, and\n * that rule is applied in code rather than enumerated here.\n *\n * ⚠️ EU membership is a legal fact with a review trigger, not a convenience list: it changes when a\n * state accedes or withdraws, and it has done both. Verified against the 27 members as of 2026-09-02.\n * Nothing derives it, so a change is a deliberate edit here.\n */\nexport const JURISDICTION_CONTAINMENT: Readonly<Record<string, readonly string[]>> = Object.freeze({\n  eu: Object.freeze([\n    'at', 'be', 'bg', 'cy', 'cz', 'de', 'dk', 'ee', 'es', 'fi', 'fr', 'gr', 'hr', 'hu',\n    'ie', 'it', 'lt', 'lu', 'lv', 'mt', 'nl', 'pl', 'pt', 'ro', 'se', 'si', 'sk',\n  ]),\n});\n\n/**\n * Does a source addressing `reach` answer for an application operating in `declared`?\n *\n * Three ways, and the order is deliberate — exact first, because it is the common case and the other\n * two are refinements of it.\n */\nexport function jurisdictionReachCovers(reach: string, declared: string): boolean {\n  if (reach === declared) return true;\n  // A source addressing the whole of `us` answers for `us-ca`; one addressing only `us-ca` does not answer for `us`.\n  if (declared.startsWith(`${reach}-`)) return true;\n  return (JURISDICTION_CONTAINMENT[reach] ?? []).some(\n    (member) => member === declared || declared.startsWith(`${member}-`),\n  );\n}\n"]}

package/dist/esm/compliance/privacy/operator-compliance-identity.shared.schemas.d.ts

@@ -142,19 +142,36 @@ export type ServiceConsentRequirement = z.infer<typeof ServiceConsentRequirement
  * A DPO appointment record, a processing-activities register (Art. 30), a retention schedule
  * (`dataRetention`), a processor register (#88). This is the operator's identity and legal posture —
  * the answers a notice needs in its opening sections — not a compliance programme.
+ *
+ * ## Every part is independently declarable, and that is the point (issue #228)
+ *
+ * This schema was optional AS A WHOLE and all-or-nothing INSIDE until 2026-09-02: the entity name,
+ * address, contact, role allocations and lawful bases were each required, so an operator who knew
+ * the registered name but had not settled lawful bases with counsel could record NOTHING. They
+ * answered by editing the produced document, and a landing REPLACES it — losing the answer on the
+ * next regeneration, which is the exact failure this schema was created to end.
+ *
+ * Paul's decision (#225) is that filling the entity must never block, and that generation is
+ * resilient to what is missing while saying plainly that the result is incomplete. So every part is
+ * optional and {@link outstandingOperatorComplianceIdentityParts} names what is still owed.
+ *
+ * What did NOT weaken: every refinement guarding a STATED claim. A legitimate-interests basis still
+ * requires its assessment, and a consent level above `NONE` still requires what it gates. Those
+ * refuse an INCOHERENT answer, never an ABSENT one, and the distinction is the whole design — a
+ * partial declaration is honest, a self-contradicting one is not.
  */
 export declare const ApplicationOperatorComplianceIdentitySchema: z.ZodObject<{
-    /** The legal entity operating the service, as registered. */
-    legalEntityName: z.ZodString;
-    /** Its registered address, as a reader would need it to serve a request. */
-    registeredAddress: z.ZodString;
+    /** The legal entity operating the service, as registered. Absent means unanswered — see the partial-filling note above. */
+    legalEntityName: z.ZodOptional<z.ZodString>;
+    /** Its registered address, as a reader would need it to serve a request. Absent means unanswered. */
+    registeredAddress: z.ZodOptional<z.ZodString>;
     /**
      * How a data subject reaches the operator about privacy — an address, an email, or a URL.
      *
      * Open string because all three are legitimate and the law names none: what matters is that a route
      * exists and is stated, not what shape it takes.
      */
-    privacyContact: z.ZodString;
+    privacyContact: z.ZodOptional<z.ZodString>;
     /**
      * An Art. 27 representative in the origin jurisdiction, where the operator is established outside it.
      *
@@ -171,11 +188,11 @@ export declare const ApplicationOperatorComplianceIdentitySchema: z.ZodObject<{
      *
      * See {@link OperatorRoleAllocationSchema} for why this is a list rather than a field.
      */
-    roleAllocations: z.ZodArray<z.ZodObject<{
+    roleAllocations: z.ZodOptional<z.ZodArray<z.ZodObject<{
         /** Which data this role covers, in the operator's own words — "customer records in a workspace". */
         dataScope: z.ZodString;
         role: z.ZodEnum<typeof OperatorProcessingRole>;
-    }, z.core.$strict>>;
+    }, z.core.$strict>>>;
     /**
      * The lawful basis relied on, per processing purpose. At least one.
      *
@@ -183,7 +200,7 @@ export declare const ApplicationOperatorComplianceIdentitySchema: z.ZodObject<{
      * declaring no basis at all is a refusal wearing a declaration's clothes, and it would land as a
      * complete answer.
      */
-    lawfulBases: z.ZodArray<z.ZodObject<{
+    lawfulBases: z.ZodOptional<z.ZodArray<z.ZodObject<{
         /** The purpose, in the operator's own words. Matches how the notice states purposes: prose, not a ref. */
         purpose: z.ZodString;
         basis: z.ZodEnum<typeof LawfulBasis>;
@@ -192,7 +209,7 @@ export declare const ApplicationOperatorComplianceIdentitySchema: z.ZodObject<{
          * that needs a balancing test — see the superRefine below.
          */
         assessmentNote: z.ZodOptional<z.ZodString>;
-    }, z.core.$strict>>;
+    }, z.core.$strict>>>;
     /**
      * What a person must consent to in order to use the service at all (issue #139).
      *
@@ -220,11 +237,49 @@ export declare const ApplicationOperatorComplianceIdentitySchema: z.ZodObject<{
     }, z.core.$strict>>;
 }, z.core.$strict>;
 export type ApplicationOperatorComplianceIdentity = z.infer<typeof ApplicationOperatorComplianceIdentitySchema>;
+/**
+ * The parts of an operator's compliance identity, so "what is still owed" has one named home.
+ *
+ * A closed vocabulary rather than free strings: every consumer that reports an incomplete identity —
+ * a drafter's brief, a document's marked gap, an operator-facing check — must name the same parts by
+ * the same names, or two surfaces tell an operator to fill two different things.
+ *
+ * `representative` and `serviceConsentRequirement` are deliberately absent from this list. Both are
+ * legitimately unset on a COMPLETE identity: an operator established where its subjects are needs no
+ * Art. 27 representative, and a declared absence of a consent gate is expressed by
+ * `serviceConsentRequirement.requiredLevel = NONE`, which is a value rather than an omission. Listing
+ * them would report every correct identity as incomplete.
+ */
+export declare enum OperatorComplianceIdentityPart {
+    LEGAL_ENTITY_NAME = "legalEntityName",
+    REGISTERED_ADDRESS = "registeredAddress",
+    PRIVACY_CONTACT = "privacyContact",
+    ROLE_ALLOCATIONS = "roleAllocations",
+    LAWFUL_BASES = "lawfulBases"
+}
+/**
+ * Which parts of the identity are still owed, in declaration order.
+ *
+ * Empty means complete. An UNDECLARED identity is not this function's case — pass it and you get every
+ * part back, which is correct but says less than the caller needs: "nobody has been asked" and "four of
+ * five parts are outstanding" are different things to tell an operator, and the caller distinguishes
+ * them by checking for the identity itself first.
+ */
+export declare function outstandingOperatorComplianceIdentityParts(identity: ApplicationOperatorComplianceIdentity | undefined): readonly OperatorComplianceIdentityPart[];
 /**
  * The lawful bases an operator declares, deduplicated — what a notice enumerates when it says which
  * bases the service relies on.
+ *
+ * `undefined` when none are declared, and NOT an empty array. A notice rendering an empty list would
+ * say the service relies on no lawful basis, which is a claim nobody made and one no processing could
+ * survive; the caller has to meet the absent case rather than fall into it.
+ */
+export declare function declaredLawfulBases(identity: ApplicationOperatorComplianceIdentity): readonly LawfulBasis[] | undefined;
+/**
+ * True when the operator declares more than one role, so a notice must not assign a single one.
+ *
+ * `undefined` when no roles are declared — the question cannot be answered, and `false` would be read
+ * as "one role", licensing exactly the collapse {@link OperatorRoleAllocationSchema} exists to prevent.
  */
-export declare function declaredLawfulBases(identity: ApplicationOperatorComplianceIdentity): readonly LawfulBasis[];
-/** True when the operator declares more than one role, so a notice must not assign a single one. */
-export declare function operatorHoldsSeveralProcessingRoles(identity: ApplicationOperatorComplianceIdentity): boolean;
+export declare function operatorHoldsSeveralProcessingRoles(identity: ApplicationOperatorComplianceIdentity): boolean | undefined;
 //# sourceMappingURL=operator-compliance-identity.shared.schemas.d.ts.map

package/dist/esm/compliance/privacy/operator-compliance-identity.shared.schemas.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"operator-compliance-identity.shared.schemas.d.ts","sourceRoot":"","sources":["../../../../../src/compliance/privacy/operator-compliance-identity.shared.schemas.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AAExB,OAAO,EAAE,qBAAqB,EAAE,MAAM,0BAA0B,CAAC;AAEjE;;;;;;;;GAQG;AACH,oBAAY,WAAW;IACrB,gGAAgG;IAChG,OAAO,YAAY;IACnB,iGAAiG;IACjG,QAAQ,aAAa;IACrB,+FAA+F;IAC/F,gBAAgB,qBAAqB;IACrC,4FAA4F;IAC5F,eAAe,oBAAoB;IACnC,wFAAwF;IACxF,WAAW,gBAAgB;IAC3B;;;;OAIG;IACH,oBAAoB,yBAAyB;CAC9C;AAED,6GAA6G;AAC7G,oBAAY,sBAAsB;IAChC,sDAAsD;IACtD,UAAU,eAAe;IACzB,mHAAmH;IACnH,SAAS,cAAc;IACvB,oHAAoH;IACpH,gBAAgB,qBAAqB;CACtC;AAED;;;;;;;;;;;GAWG;AACH,eAAO,MAAM,4BAA4B;IACvC,oGAAoG;;;kBAGpG,CAAC;AACH,MAAM,MAAM,sBAAsB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,4BAA4B,CAAC,CAAC;AAElF,0EAA0E;AAC1E,eAAO,MAAM,yBAAyB;IACpC,0GAA0G;;;IAG1G;;;OAGG;;kBAgBH,CAAC;AACH,MAAM,MAAM,mBAAmB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,yBAAyB,CAAC,CAAC;AAE5E;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA6BG;AACH,eAAO,MAAM,+BAA+B;IAC1C;;;;;;OAMG;;IAEH;;;;;;OAMG;;kBAgBH,CAAC;AACH,MAAM,MAAM,yBAAyB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,+BAA+B,CAAC,CAAC;AAExF;;;;;;;;;;;;;;;;;;;;;;;;;;;GA2BG;AACH,eAAO,MAAM,2CAA2C;IACtD,6DAA6D;;IAE7D,4EAA4E;;IAE5E;;;;;OAKG;;IAEH;;;;;;OAMG;;;;;IAKH;;;;OAIG;;QAxJH,oGAAoG;;;;IA0JpG;;;;;;OAMG;;QAxJH,0GAA0G;;;QAG1G;;;WAGG;;;IAoJH;;;;;;OAMG;;QAxGH;;;;;;WAMG;;QAEH;;;;;;WAMG;;;kBA4FH,CAAC;AACH,MAAM,MAAM,qCAAqC,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,2CAA2C,CAAC,CAAC;AAGhH;;;GAGG;AACH,wBAAgB,mBAAmB,CAAC,QAAQ,EAAE,qCAAqC,GAAG,SAAS,WAAW,EAAE,CAI3G;AAED,oGAAoG;AACpG,wBAAgB,mCAAmC,CAAC,QAAQ,EAAE,qCAAqC,GAAG,OAAO,CAE5G"}
+{"version":3,"file":"operator-compliance-identity.shared.schemas.d.ts","sourceRoot":"","sources":["../../../../../src/compliance/privacy/operator-compliance-identity.shared.schemas.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AAExB,OAAO,EAAE,qBAAqB,EAAE,MAAM,0BAA0B,CAAC;AAEjE;;;;;;;;GAQG;AACH,oBAAY,WAAW;IACrB,gGAAgG;IAChG,OAAO,YAAY;IACnB,iGAAiG;IACjG,QAAQ,aAAa;IACrB,+FAA+F;IAC/F,gBAAgB,qBAAqB;IACrC,4FAA4F;IAC5F,eAAe,oBAAoB;IACnC,wFAAwF;IACxF,WAAW,gBAAgB;IAC3B;;;;OAIG;IACH,oBAAoB,yBAAyB;CAC9C;AAED,6GAA6G;AAC7G,oBAAY,sBAAsB;IAChC,sDAAsD;IACtD,UAAU,eAAe;IACzB,mHAAmH;IACnH,SAAS,cAAc;IACvB,oHAAoH;IACpH,gBAAgB,qBAAqB;CACtC;AAED;;;;;;;;;;;GAWG;AACH,eAAO,MAAM,4BAA4B;IACvC,oGAAoG;;;kBAGpG,CAAC;AACH,MAAM,MAAM,sBAAsB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,4BAA4B,CAAC,CAAC;AAElF,0EAA0E;AAC1E,eAAO,MAAM,yBAAyB;IACpC,0GAA0G;;;IAG1G;;;OAGG;;kBAgBH,CAAC;AACH,MAAM,MAAM,mBAAmB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,yBAAyB,CAAC,CAAC;AAE5E;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA6BG;AACH,eAAO,MAAM,+BAA+B;IAC1C;;;;;;OAMG;;IAEH;;;;;;OAMG;;kBAgBH,CAAC;AACH,MAAM,MAAM,yBAAyB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,+BAA+B,CAAC,CAAC;AAExF;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA4CG;AACH,eAAO,MAAM,2CAA2C;IACtD,2HAA2H;;IAE3H,qGAAqG;;IAErG;;;;;OAKG;;IAEH;;;;;;OAMG;;;;;IAKH;;;;OAIG;;QAzKH,oGAAoG;;;;IA2KpG;;;;;;OAMG;;QAzKH,0GAA0G;;;QAG1G;;;WAGG;;;IAqKH;;;;;;OAMG;;QAzHH;;;;;;WAMG;;QAEH;;;;;;WAMG;;;kBAiIH,CAAC;AACH,MAAM,MAAM,qCAAqC,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,2CAA2C,CAAC,CAAC;AAGhH;;;;;;;;;;;;GAYG;AACH,oBAAY,8BAA8B;IACxC,iBAAiB,oBAAoB;IACrC,kBAAkB,sBAAsB;IACxC,eAAe,mBAAmB;IAClC,gBAAgB,oBAAoB;IACpC,YAAY,gBAAgB;CAC7B;AAED;;;;;;;GAOG;AACH,wBAAgB,0CAA0C,CACxD,QAAQ,EAAE,qCAAqC,GAAG,SAAS,GAC1D,SAAS,8BAA8B,EAAE,CAQ3C;AAED;;;;;;;GAOG;AACH,wBAAgB,mBAAmB,CAAC,QAAQ,EAAE,qCAAqC,GAAG,SAAS,WAAW,EAAE,GAAG,SAAS,CAKvH;AAED;;;;;GAKG;AACH,wBAAgB,mCAAmC,CAAC,QAAQ,EAAE,qCAAqC,GAAG,OAAO,GAAG,SAAS,CAGxH"}

package/dist/esm/compliance/privacy/operator-compliance-identity.shared.schemas.js

@@ -169,19 +169,36 @@ export const ServiceConsentRequirementSchema = z.strictObject({
  * A DPO appointment record, a processing-activities register (Art. 30), a retention schedule
  * (`dataRetention`), a processor register (#88). This is the operator's identity and legal posture —
  * the answers a notice needs in its opening sections — not a compliance programme.
+ *
+ * ## Every part is independently declarable, and that is the point (issue #228)
+ *
+ * This schema was optional AS A WHOLE and all-or-nothing INSIDE until 2026-09-02: the entity name,
+ * address, contact, role allocations and lawful bases were each required, so an operator who knew
+ * the registered name but had not settled lawful bases with counsel could record NOTHING. They
+ * answered by editing the produced document, and a landing REPLACES it — losing the answer on the
+ * next regeneration, which is the exact failure this schema was created to end.
+ *
+ * Paul's decision (#225) is that filling the entity must never block, and that generation is
+ * resilient to what is missing while saying plainly that the result is incomplete. So every part is
+ * optional and {@link outstandingOperatorComplianceIdentityParts} names what is still owed.
+ *
+ * What did NOT weaken: every refinement guarding a STATED claim. A legitimate-interests basis still
+ * requires its assessment, and a consent level above `NONE` still requires what it gates. Those
+ * refuse an INCOHERENT answer, never an ABSENT one, and the distinction is the whole design — a
+ * partial declaration is honest, a self-contradicting one is not.
  */
 export const ApplicationOperatorComplianceIdentitySchema = z.strictObject({
-    /** The legal entity operating the service, as registered. */
-    legalEntityName: z.string().trim().min(1),
-    /** Its registered address, as a reader would need it to serve a request. */
-    registeredAddress: z.string().trim().min(1),
+    /** The legal entity operating the service, as registered. Absent means unanswered — see the partial-filling note above. */
+    legalEntityName: z.string().trim().min(1).optional(),
+    /** Its registered address, as a reader would need it to serve a request. Absent means unanswered. */
+    registeredAddress: z.string().trim().min(1).optional(),
     /**
      * How a data subject reaches the operator about privacy — an address, an email, or a URL.
      *
      * Open string because all three are legitimate and the law names none: what matters is that a route
      * exists and is stated, not what shape it takes.
      */
-    privacyContact: z.string().trim().min(1),
+    privacyContact: z.string().trim().min(1).optional(),
     /**
      * An Art. 27 representative in the origin jurisdiction, where the operator is established outside it.
      *
@@ -198,7 +215,7 @@ export const ApplicationOperatorComplianceIdentitySchema = z.strictObject({
      *
      * See {@link OperatorRoleAllocationSchema} for why this is a list rather than a field.
      */
-    roleAllocations: z.array(OperatorRoleAllocationSchema).min(1),
+    roleAllocations: z.array(OperatorRoleAllocationSchema).min(1).optional(),
     /**
      * The lawful basis relied on, per processing purpose. At least one.
      *
@@ -206,7 +223,7 @@ export const ApplicationOperatorComplianceIdentitySchema = z.strictObject({
      * declaring no basis at all is a refusal wearing a declaration's clothes, and it would land as a
      * complete answer.
      */
-    lawfulBases: z.array(OperatorLawfulBasisSchema).min(1),
+    lawfulBases: z.array(OperatorLawfulBasisSchema).min(1).optional(),
     /**
      * What a person must consent to in order to use the service at all (issue #139).
      *
@@ -215,18 +232,88 @@ export const ApplicationOperatorComplianceIdentitySchema = z.strictObject({
      * absence is nobody having been asked, and a notice must not render the second as the first.
      */
     serviceConsentRequirement: ServiceConsentRequirementSchema.optional(),
+}).superRefine((identity, context) => {
+    /*
+     * A declaration with nothing in it is a no-op that reads as an answer.
+     *
+     * Every part is independently optional so an operator can record the half they know (#228), and the
+     * cost of that is a new shape the old schema could not express: `operatorComplianceIdentity: {}`.
+     * Absent and empty must not mean the same thing — absence is "nobody was asked", which every
+     * consumer already renders as outstanding, while an empty object would satisfy the field and
+     * disclose nothing. Same defect the file refuses twice already, for a legitimate-interests basis
+     * with no assessment and a consent gate that names nothing.
+     */
+    if (Object.values(identity).every((part) => part === undefined)) {
+        context.addIssue({
+            code: 'custom',
+            path: [],
+            message: 'an operator compliance identity that declares nothing is not a partial answer, it is an empty one — '
+                + 'record the part you know, or omit `operatorComplianceIdentity` entirely so it reads as unanswered',
+        });
+    }
 });
+/**
+ * The parts of an operator's compliance identity, so "what is still owed" has one named home.
+ *
+ * A closed vocabulary rather than free strings: every consumer that reports an incomplete identity —
+ * a drafter's brief, a document's marked gap, an operator-facing check — must name the same parts by
+ * the same names, or two surfaces tell an operator to fill two different things.
+ *
+ * `representative` and `serviceConsentRequirement` are deliberately absent from this list. Both are
+ * legitimately unset on a COMPLETE identity: an operator established where its subjects are needs no
+ * Art. 27 representative, and a declared absence of a consent gate is expressed by
+ * `serviceConsentRequirement.requiredLevel = NONE`, which is a value rather than an omission. Listing
+ * them would report every correct identity as incomplete.
+ */
+export var OperatorComplianceIdentityPart;
+(function (OperatorComplianceIdentityPart) {
+    OperatorComplianceIdentityPart["LEGAL_ENTITY_NAME"] = "legalEntityName";
+    OperatorComplianceIdentityPart["REGISTERED_ADDRESS"] = "registeredAddress";
+    OperatorComplianceIdentityPart["PRIVACY_CONTACT"] = "privacyContact";
+    OperatorComplianceIdentityPart["ROLE_ALLOCATIONS"] = "roleAllocations";
+    OperatorComplianceIdentityPart["LAWFUL_BASES"] = "lawfulBases";
+})(OperatorComplianceIdentityPart || (OperatorComplianceIdentityPart = {}));
+/**
+ * Which parts of the identity are still owed, in declaration order.
+ *
+ * Empty means complete. An UNDECLARED identity is not this function's case — pass it and you get every
+ * part back, which is correct but says less than the caller needs: "nobody has been asked" and "four of
+ * five parts are outstanding" are different things to tell an operator, and the caller distinguishes
+ * them by checking for the identity itself first.
+ */
+export function outstandingOperatorComplianceIdentityParts(identity) {
+    return [
+        identity?.legalEntityName === undefined ? OperatorComplianceIdentityPart.LEGAL_ENTITY_NAME : undefined,
+        identity?.registeredAddress === undefined ? OperatorComplianceIdentityPart.REGISTERED_ADDRESS : undefined,
+        identity?.privacyContact === undefined ? OperatorComplianceIdentityPart.PRIVACY_CONTACT : undefined,
+        identity?.roleAllocations === undefined ? OperatorComplianceIdentityPart.ROLE_ALLOCATIONS : undefined,
+        identity?.lawfulBases === undefined ? OperatorComplianceIdentityPart.LAWFUL_BASES : undefined,
+    ].filter((part) => part !== undefined);
+}
 /**
  * The lawful bases an operator declares, deduplicated — what a notice enumerates when it says which
  * bases the service relies on.
+ *
+ * `undefined` when none are declared, and NOT an empty array. A notice rendering an empty list would
+ * say the service relies on no lawful basis, which is a claim nobody made and one no processing could
+ * survive; the caller has to meet the absent case rather than fall into it.
  */
 export function declaredLawfulBases(identity) {
+    if (identity.lawfulBases === undefined)
+        return undefined;
     const order = Object.values(LawfulBasis);
     return [...new Set(identity.lawfulBases.map((entry) => entry.basis))]
         .sort((left, right) => order.indexOf(left) - order.indexOf(right));
 }
-/** True when the operator declares more than one role, so a notice must not assign a single one. */
+/**
+ * True when the operator declares more than one role, so a notice must not assign a single one.
+ *
+ * `undefined` when no roles are declared — the question cannot be answered, and `false` would be read
+ * as "one role", licensing exactly the collapse {@link OperatorRoleAllocationSchema} exists to prevent.
+ */
 export function operatorHoldsSeveralProcessingRoles(identity) {
+    if (identity.roleAllocations === undefined)
+        return undefined;
     return new Set(identity.roleAllocations.map((allocation) => allocation.role)).size > 1;
 }
 //# sourceMappingURL=operator-compliance-identity.shared.schemas.js.map