@wildo-ai/saas-models 1.1.4 → 1.1.6

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

@@ -85,6 +85,44 @@ export declare enum ErasureRetentionMode {
  * `isolatedDeclarations` emit constraint.
  */
 export declare const ErasureRetentionModeSchema: z.ZodEnum<typeof ErasureRetentionMode>;
+/** @wildo_source:part:start saas.models.privacy.statutory-retention-ground facet:layer:shared facet:audience:app-developer */
+/**
+ * **WHY the law lets a row survive an erasure** — the exemption a `retentionPolicy.statutoryRetention`
+ * declaration names (#1635).
+ *
+ * A data subject's right to erasure (GDPR Art. 17(1)) does not apply "to the extent that processing is
+ * necessary … for compliance with a legal obligation which requires processing by Union or Member State
+ * law to which the controller is subject" (Art. 17(3)(b)). Business correspondence and accounting source
+ * documents carry exactly such an obligation — HGB §257 and AO §147 in Germany, Code de commerce L123-22 in
+ * France — so a subject erasure keeps those rows until the statutory period ends, and RESTRICTS them in the
+ * meantime: stored, and processed for nothing else (the Art. 18(2) effect, which BDSG §35(1)/(3) states
+ * explicitly as the substitute for erasure).
+ *
+ * spec-cite: Regulation (EU) 2016/679, Art. 17(3) introductory sentence, (b) and (e), fetched from
+ * gdpr-info.eu/art-17-gdpr 2026-09-27; Art. 18(2) and BDSG §35(1)/(3) as fetched and quoted in #1635.
+ *
+ * ## One member, on purpose
+ *
+ * Art. 17(3)(e) — "for the establishment, exercise or defence of legal claims" — is the other ground an
+ * operator reaches for, and it is deliberately NOT a member. It is a property of a CASE, decided when a claim
+ * arises and lifted when it ends: that is a legal hold (#1634), not a property of every row of a class. A
+ * member here would let a resource declare every row permanently "needed for legal claims", which is the
+ * standing retention the storage-limitation principle forbids. The remaining grounds of Art. 17(3) (freedom
+ * of expression, public health, archiving in the public interest) have no Wildo mechanism behind them; a
+ * member without one would be a claim nothing enforces.
+ *
+ * `z.enum` rather than a literal so a member added later reaches every consumer through this one source.
+ */
+export declare enum StatutoryRetentionGround {
+    /** GDPR Art. 17(3)(b): the rows are kept because a statute requires the controller to keep them. */
+    LEGAL_OBLIGATION = "legal_obligation"
+}
+/**
+ * Zod schema for {@link StatutoryRetentionGround}. Explicitly annotated for the `isolatedDeclarations`
+ * emit constraint.
+ */
+export declare const StatutoryRetentionGroundSchema: z.ZodEnum<typeof StatutoryRetentionGround>;
+/** @wildo_source:part:end saas.models.privacy.statutory-retention-ground */
 /**
  * **WHOSE SESSION ENDS** when a row of this resource is erased. The second axis of the erasure
  * contract, beside {@link ErasureRetentionMode} (which says what happens to the row).

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;;;;;;;;;;;;;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"}
+{"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,8HAA8H;AAC9H;;;;;;;;;;;;;;;;;;;;;;;;;;GA0BG;AACH,oBAAY,wBAAwB;IAClC,oGAAoG;IACpG,gBAAgB,qBAAqB;CACtC;AAED;;;GAGG;AACH,eAAO,MAAM,8BAA8B,EAAE,CAAC,CAAC,OAAO,CAAC,OAAO,wBAAwB,CACpD,CAAC;AACnC,4EAA4E;AAE5E;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;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

@@ -87,6 +87,45 @@ export var ErasureRetentionMode;
  * `isolatedDeclarations` emit constraint.
  */
 export const ErasureRetentionModeSchema = z.enum(ErasureRetentionMode);
+/** @wildo_source:part:start saas.models.privacy.statutory-retention-ground facet:layer:shared facet:audience:app-developer */
+/**
+ * **WHY the law lets a row survive an erasure** — the exemption a `retentionPolicy.statutoryRetention`
+ * declaration names (#1635).
+ *
+ * A data subject's right to erasure (GDPR Art. 17(1)) does not apply "to the extent that processing is
+ * necessary … for compliance with a legal obligation which requires processing by Union or Member State
+ * law to which the controller is subject" (Art. 17(3)(b)). Business correspondence and accounting source
+ * documents carry exactly such an obligation — HGB §257 and AO §147 in Germany, Code de commerce L123-22 in
+ * France — so a subject erasure keeps those rows until the statutory period ends, and RESTRICTS them in the
+ * meantime: stored, and processed for nothing else (the Art. 18(2) effect, which BDSG §35(1)/(3) states
+ * explicitly as the substitute for erasure).
+ *
+ * spec-cite: Regulation (EU) 2016/679, Art. 17(3) introductory sentence, (b) and (e), fetched from
+ * gdpr-info.eu/art-17-gdpr 2026-09-27; Art. 18(2) and BDSG §35(1)/(3) as fetched and quoted in #1635.
+ *
+ * ## One member, on purpose
+ *
+ * Art. 17(3)(e) — "for the establishment, exercise or defence of legal claims" — is the other ground an
+ * operator reaches for, and it is deliberately NOT a member. It is a property of a CASE, decided when a claim
+ * arises and lifted when it ends: that is a legal hold (#1634), not a property of every row of a class. A
+ * member here would let a resource declare every row permanently "needed for legal claims", which is the
+ * standing retention the storage-limitation principle forbids. The remaining grounds of Art. 17(3) (freedom
+ * of expression, public health, archiving in the public interest) have no Wildo mechanism behind them; a
+ * member without one would be a claim nothing enforces.
+ *
+ * `z.enum` rather than a literal so a member added later reaches every consumer through this one source.
+ */
+export var StatutoryRetentionGround;
+(function (StatutoryRetentionGround) {
+    /** GDPR Art. 17(3)(b): the rows are kept because a statute requires the controller to keep them. */
+    StatutoryRetentionGround["LEGAL_OBLIGATION"] = "legal_obligation";
+})(StatutoryRetentionGround || (StatutoryRetentionGround = {}));
+/**
+ * Zod schema for {@link StatutoryRetentionGround}. Explicitly annotated for the `isolatedDeclarations`
+ * emit constraint.
+ */
+export const StatutoryRetentionGroundSchema = z.enum(StatutoryRetentionGround);
+/** @wildo_source:part:end saas.models.privacy.statutory-retention-ground */
 /**
  * **WHOSE SESSION ENDS** when a row of this resource is erased. The second axis of the erasure
  * contract, beside {@link ErasureRetentionMode} (which says what happens to the row).

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,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"]}
+{"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,8HAA8H;AAC9H;;;;;;;;;;;;;;;;;;;;;;;;;;GA0BG;AACH,MAAM,CAAN,IAAY,wBAGX;AAHD,WAAY,wBAAwB;IAClC,oGAAoG;IACpG,iEAAqC,CAAA;AACvC,CAAC,EAHW,wBAAwB,KAAxB,wBAAwB,QAGnC;AAED;;;GAGG;AACH,MAAM,CAAC,MAAM,8BAA8B,GACzC,CAAC,CAAC,IAAI,CAAC,wBAAwB,CAAC,CAAC;AACnC,4EAA4E;AAE5E;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;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/** @wildo_source:part:start saas.models.privacy.statutory-retention-ground facet:layer:shared facet:audience:app-developer */\n/**\n * **WHY the law lets a row survive an erasure** — the exemption a `retentionPolicy.statutoryRetention`\n * declaration names (#1635).\n *\n * A data subject's right to erasure (GDPR Art. 17(1)) does not apply \"to the extent that processing is\n * necessary … for compliance with a legal obligation which requires processing by Union or Member State\n * law to which the controller is subject\" (Art. 17(3)(b)). Business correspondence and accounting source\n * documents carry exactly such an obligation — HGB §257 and AO §147 in Germany, Code de commerce L123-22 in\n * France — so a subject erasure keeps those rows until the statutory period ends, and RESTRICTS them in the\n * meantime: stored, and processed for nothing else (the Art. 18(2) effect, which BDSG §35(1)/(3) states\n * explicitly as the substitute for erasure).\n *\n * spec-cite: Regulation (EU) 2016/679, Art. 17(3) introductory sentence, (b) and (e), fetched from\n * gdpr-info.eu/art-17-gdpr 2026-09-27; Art. 18(2) and BDSG §35(1)/(3) as fetched and quoted in #1635.\n *\n * ## One member, on purpose\n *\n * Art. 17(3)(e) — \"for the establishment, exercise or defence of legal claims\" — is the other ground an\n * operator reaches for, and it is deliberately NOT a member. It is a property of a CASE, decided when a claim\n * arises and lifted when it ends: that is a legal hold (#1634), not a property of every row of a class. A\n * member here would let a resource declare every row permanently \"needed for legal claims\", which is the\n * standing retention the storage-limitation principle forbids. The remaining grounds of Art. 17(3) (freedom\n * of expression, public health, archiving in the public interest) have no Wildo mechanism behind them; a\n * member without one would be a claim nothing enforces.\n *\n * `z.enum` rather than a literal so a member added later reaches every consumer through this one source.\n */\nexport enum StatutoryRetentionGround {\n  /** GDPR Art. 17(3)(b): the rows are kept because a statute requires the controller to keep them. */\n  LEGAL_OBLIGATION = 'legal_obligation',\n}\n\n/**\n * Zod schema for {@link StatutoryRetentionGround}. Explicitly annotated for the `isolatedDeclarations`\n * emit constraint.\n */\nexport const StatutoryRetentionGroundSchema: z.ZodEnum<typeof StatutoryRetentionGround> =\n  z.enum(StatutoryRetentionGround);\n/** @wildo_source:part:end saas.models.privacy.statutory-retention-ground */\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/legal-hold-subject-attribution.shared.utils.d.ts

@@ -0,0 +1,35 @@
+/**
+ * Which rows of a resource type a `DATA_SUBJECT` legal hold covers (#1634) — derived from the SAME
+ * subject-export classification an Art. 15 access request uses, so the rows a hold on a person preserves
+ * and the rows an access request about that person discloses cannot drift apart.
+ *
+ * Pure over configuration; the backend computes it once per resource type and caches it.
+ */
+import { type ResourceRelationship } from '../../resources/resources.shared.schemas';
+import type { ResourceType } from '../../resources/resources.shared.core.definitions';
+import { type SubjectExportRelationshipBuckets } from './subject-export.shared.schemas';
+import { type LegalHoldSubjectAttribution } from './legal-holds.shared.schemas';
+/**
+ * Plan the attribution of `targetResourceType`'s rows to a person.
+ *
+ * 1. `USERS` itself → the row IS the person.
+ * 2. A resource declared `exportSubject: FORBIDDEN` is outside the export graph → never attributed. Its rows
+ *    (credentials, sessions) are the ones an access request withholds, so a hold on the person does not
+ *    preserve them either.
+ * 3. A resource on an included `USERS` export edge whose rows hold the foreign key → attributed by that field.
+ * 4. A resource the export reaches only through another row — a key held on the `USERS` side, or an owned
+ *    descendant of an included owned edge — cannot be attributed from its own fields → UNRESOLVABLE, and the
+ *    hold covers every row of it in the held tenant. That is the conservative direction on purpose.
+ * 5. Anything else is not the person's data → not attributed.
+ */
+export declare function planLegalHoldSubjectAttribution(input: {
+    readonly usersResourceType: ResourceType;
+    readonly targetResourceType: ResourceType;
+    readonly usersRelationships: SubjectExportRelationshipBuckets;
+    readonly isExportForbidden: (resourceType: ResourceType) => boolean;
+    /** The child-direction relationships of a resource type (for the owned-descendant closure). */
+    readonly childRelationshipsOf: (resourceType: ResourceType) => readonly ResourceRelationship[];
+    /** The FK field of a relationship normalized with the referenced side as `resourceType1`. */
+    readonly resolveForeignKeyField: (relationship: ResourceRelationship) => string;
+}): LegalHoldSubjectAttribution;
+//# sourceMappingURL=legal-hold-subject-attribution.shared.utils.d.ts.map

package/dist/esm/compliance/privacy/legal-hold-subject-attribution.shared.utils.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"legal-hold-subject-attribution.shared.utils.d.ts","sourceRoot":"","sources":["../../../../../src/compliance/privacy/legal-hold-subject-attribution.shared.utils.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AAEH,OAAO,EAEL,KAAK,oBAAoB,EAC1B,MAAM,0CAA0C,CAAC;AAElD,OAAO,KAAK,EAAE,YAAY,EAAE,MAAM,mDAAmD,CAAC;AACtF,OAAO,EAKL,KAAK,gCAAgC,EACtC,MAAM,iCAAiC,CAAC;AACzC,OAAO,EAEL,KAAK,2BAA2B,EACjC,MAAM,8BAA8B,CAAC;AAEtC;;;;;;;;;;;;GAYG;AACH,wBAAgB,+BAA+B,CAAC,KAAK,EAAE;IACrD,QAAQ,CAAC,iBAAiB,EAAE,YAAY,CAAC;IACzC,QAAQ,CAAC,kBAAkB,EAAE,YAAY,CAAC;IAC1C,QAAQ,CAAC,kBAAkB,EAAE,gCAAgC,CAAC;IAC9D,QAAQ,CAAC,iBAAiB,EAAE,CAAC,YAAY,EAAE,YAAY,KAAK,OAAO,CAAC;IACpE,+FAA+F;IAC/F,QAAQ,CAAC,oBAAoB,EAAE,CAAC,YAAY,EAAE,YAAY,KAAK,SAAS,oBAAoB,EAAE,CAAC;IAC/F,6FAA6F;IAC7F,QAAQ,CAAC,sBAAsB,EAAE,CAAC,YAAY,EAAE,oBAAoB,KAAK,MAAM,CAAC;CACjF,GAAG,2BAA2B,CAyD9B"}

package/dist/esm/compliance/privacy/legal-hold-subject-attribution.shared.utils.js

@@ -0,0 +1,82 @@
+/**
+ * Which rows of a resource type a `DATA_SUBJECT` legal hold covers (#1634) — derived from the SAME
+ * subject-export classification an Art. 15 access request uses, so the rows a hold on a person preserves
+ * and the rows an access request about that person discloses cannot drift apart.
+ *
+ * Pure over configuration; the backend computes it once per resource type and caches it.
+ */
+import { RelationshipLifecycleModel, } from '../../resources/resources.shared.schemas.js';
+import { Resources_SharedUtils } from '../../resources/resources.shared.utils.js';
+import { SubjectExportEdgeDisposition, SubjectExportPurpose, enumerateSubjectExportRelationshipTraversals, isIncludedSubjectExportEdgeDisposition, } from './subject-export.shared.schemas.js';
+import { LegalHoldSubjectAttributionKind, } from './legal-holds.shared.schemas.js';
+/**
+ * Plan the attribution of `targetResourceType`'s rows to a person.
+ *
+ * 1. `USERS` itself → the row IS the person.
+ * 2. A resource declared `exportSubject: FORBIDDEN` is outside the export graph → never attributed. Its rows
+ *    (credentials, sessions) are the ones an access request withholds, so a hold on the person does not
+ *    preserve them either.
+ * 3. A resource on an included `USERS` export edge whose rows hold the foreign key → attributed by that field.
+ * 4. A resource the export reaches only through another row — a key held on the `USERS` side, or an owned
+ *    descendant of an included owned edge — cannot be attributed from its own fields → UNRESOLVABLE, and the
+ *    hold covers every row of it in the held tenant. That is the conservative direction on purpose.
+ * 5. Anything else is not the person's data → not attributed.
+ */
+export function planLegalHoldSubjectAttribution(input) {
+    const { usersResourceType, targetResourceType } = input;
+    if (targetResourceType === usersResourceType)
+        return { kind: LegalHoldSubjectAttributionKind.SUBJECT_ROW };
+    if (input.isExportForbidden(targetResourceType))
+        return { kind: LegalHoldSubjectAttributionKind.NOT_ATTRIBUTED };
+    const included = enumerateSubjectExportRelationshipTraversals(usersResourceType, input.usersRelationships, SubjectExportPurpose.ACCESS_ART_15).filter((traversal) => isIncludedSubjectExportEdgeDisposition(traversal.classification.disposition));
+    const foreignKeyFields = new Set();
+    let unresolvable = false;
+    for (const traversal of included) {
+        if (traversal.classification.relatedResourceType !== targetResourceType)
+            continue;
+        const holder = Resources_SharedUtils.resolveForeignKeyHolderResourceType(traversal.normalizedRelationship);
+        if (holder === targetResourceType) {
+            foreignKeyFields.add(input.resolveForeignKeyField(traversal.normalizedRelationship));
+        }
+        else {
+            unresolvable = true;
+        }
+    }
+    if (!unresolvable) {
+        // The owned-descendant closure: rows below a row the person owns are the person's data too, and their
+        // own fields do not say whose ancestor they hang from.
+        const pending = included
+            .filter((traversal) => traversal.classification.disposition === SubjectExportEdgeDisposition.INCLUDED_OWNED)
+            .map((traversal) => traversal.classification.relatedResourceType);
+        const walked = new Set([String(usersResourceType)]);
+        while (pending.length > 0 && !unresolvable) {
+            const current = pending.shift();
+            if (walked.has(String(current)))
+                continue;
+            walked.add(String(current));
+            for (const relationship of input.childRelationshipsOf(current)) {
+                if (relationship.isDisabled === true)
+                    continue;
+                const semantics = Resources_SharedUtils.requireResolvedRelationshipSemantics(relationship);
+                if (semantics.handling.lifecycleModelMode !== RelationshipLifecycleModel.DEPENDENT)
+                    continue;
+                const child = relationship.resourceType2;
+                if (child === targetResourceType) {
+                    unresolvable = true;
+                    break;
+                }
+                pending.push(child);
+            }
+        }
+    }
+    if (unresolvable) {
+        return foreignKeyFields.size > 0
+            ? { kind: LegalHoldSubjectAttributionKind.UNRESOLVABLE, foreignKeyFields: [...foreignKeyFields].sort() }
+            : { kind: LegalHoldSubjectAttributionKind.UNRESOLVABLE };
+    }
+    if (foreignKeyFields.size > 0) {
+        return { kind: LegalHoldSubjectAttributionKind.FOREIGN_KEY, foreignKeyFields: [...foreignKeyFields].sort() };
+    }
+    return { kind: LegalHoldSubjectAttributionKind.NOT_ATTRIBUTED };
+}
+//# sourceMappingURL=legal-hold-subject-attribution.shared.utils.js.map

package/dist/esm/compliance/privacy/legal-hold-subject-attribution.shared.utils.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"legal-hold-subject-attribution.shared.utils.js","sourceRoot":"","sources":["../../../../../src/compliance/privacy/legal-hold-subject-attribution.shared.utils.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AAEH,OAAO,EACL,0BAA0B,GAE3B,MAAM,0CAA0C,CAAC;AAClD,OAAO,EAAE,qBAAqB,EAAE,MAAM,wCAAwC,CAAC;AAE/E,OAAO,EACL,4BAA4B,EAC5B,oBAAoB,EACpB,4CAA4C,EAC5C,sCAAsC,GAEvC,MAAM,iCAAiC,CAAC;AACzC,OAAO,EACL,+BAA+B,GAEhC,MAAM,8BAA8B,CAAC;AAEtC;;;;;;;;;;;;GAYG;AACH,MAAM,UAAU,+BAA+B,CAAC,KAS/C;IACC,MAAM,EAAE,iBAAiB,EAAE,kBAAkB,EAAE,GAAG,KAAK,CAAC;IACxD,IAAI,kBAAkB,KAAK,iBAAiB;QAAE,OAAO,EAAE,IAAI,EAAE,+BAA+B,CAAC,WAAW,EAAE,CAAC;IAC3G,IAAI,KAAK,CAAC,iBAAiB,CAAC,kBAAkB,CAAC;QAAE,OAAO,EAAE,IAAI,EAAE,+BAA+B,CAAC,cAAc,EAAE,CAAC;IAEjH,MAAM,QAAQ,GAAG,4CAA4C,CAC3D,iBAAiB,EACjB,KAAK,CAAC,kBAAkB,EACxB,oBAAoB,CAAC,aAAa,CACnC,CAAC,MAAM,CAAC,CAAC,SAAS,EAAE,EAAE,CAAC,sCAAsC,CAAC,SAAS,CAAC,cAAc,CAAC,WAAW,CAAC,CAAC,CAAC;IAEtG,MAAM,gBAAgB,GAAG,IAAI,GAAG,EAAU,CAAC;IAC3C,IAAI,YAAY,GAAG,KAAK,CAAC;IACzB,KAAK,MAAM,SAAS,IAAI,QAAQ,EAAE,CAAC;QACjC,IAAI,SAAS,CAAC,cAAc,CAAC,mBAAmB,KAAK,kBAAkB;YAAE,SAAS;QAClF,MAAM,MAAM,GAAG,qBAAqB,CAAC,mCAAmC,CAAC,SAAS,CAAC,sBAAsB,CAAC,CAAC;QAC3G,IAAI,MAAM,KAAK,kBAAkB,EAAE,CAAC;YAClC,gBAAgB,CAAC,GAAG,CAAC,KAAK,CAAC,sBAAsB,CAAC,SAAS,CAAC,sBAAsB,CAAC,CAAC,CAAC;QACvF,CAAC;aAAM,CAAC;YACN,YAAY,GAAG,IAAI,CAAC;QACtB,CAAC;IACH,CAAC;IAED,IAAI,CAAC,YAAY,EAAE,CAAC;QAClB,sGAAsG;QACtG,uDAAuD;QACvD,MAAM,OAAO,GAAG,QAAQ;aACrB,MAAM,CAAC,CAAC,SAAS,EAAE,EAAE,CAAC,SAAS,CAAC,cAAc,CAAC,WAAW,KAAK,4BAA4B,CAAC,cAAc,CAAC;aAC3G,GAAG,CAAC,CAAC,SAAS,EAAE,EAAE,CAAC,SAAS,CAAC,cAAc,CAAC,mBAAmB,CAAC,CAAC;QACpE,MAAM,MAAM,GAAG,IAAI,GAAG,CAAS,CAAC,MAAM,CAAC,iBAAiB,CAAC,CAAC,CAAC,CAAC;QAC5D,OAAO,OAAO,CAAC,MAAM,GAAG,CAAC,IAAI,CAAC,YAAY,EAAE,CAAC;YAC3C,MAAM,OAAO,GAAG,OAAO,CAAC,KAAK,EAAG,CAAC;YACjC,IAAI,MAAM,CAAC,GAAG,CAAC,MAAM,CAAC,OAAO,CAAC,CAAC;gBAAE,SAAS;YAC1C,MAAM,CAAC,GAAG,CAAC,MAAM,CAAC,OAAO,CAAC,CAAC,CAAC;YAC5B,KAAK,MAAM,YAAY,IAAI,KAAK,CAAC,oBAAoB,CAAC,OAAO,CAAC,EAAE,CAAC;gBAC/D,IAAI,YAAY,CAAC,UAAU,KAAK,IAAI;oBAAE,SAAS;gBAC/C,MAAM,SAAS,GAAG,qBAAqB,CAAC,oCAAoC,CAAC,YAAY,CAAC,CAAC;gBAC3F,IAAI,SAAS,CAAC,QAAQ,CAAC,kBAAkB,KAAK,0BAA0B,CAAC,SAAS;oBAAE,SAAS;gBAC7F,MAAM,KAAK,GAAG,YAAY,CAAC,aAA6B,CAAC;gBACzD,IAAI,KAAK,KAAK,kBAAkB,EAAE,CAAC;oBACjC,YAAY,GAAG,IAAI,CAAC;oBACpB,MAAM;gBACR,CAAC;gBACD,OAAO,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC;YACtB,CAAC;QACH,CAAC;IACH,CAAC;IAED,IAAI,YAAY,EAAE,CAAC;QACjB,OAAO,gBAAgB,CAAC,IAAI,GAAG,CAAC;YAC9B,CAAC,CAAC,EAAE,IAAI,EAAE,+BAA+B,CAAC,YAAY,EAAE,gBAAgB,EAAE,CAAC,GAAG,gBAAgB,CAAC,CAAC,IAAI,EAAE,EAAE;YACxG,CAAC,CAAC,EAAE,IAAI,EAAE,+BAA+B,CAAC,YAAY,EAAE,CAAC;IAC7D,CAAC;IACD,IAAI,gBAAgB,CAAC,IAAI,GAAG,CAAC,EAAE,CAAC;QAC9B,OAAO,EAAE,IAAI,EAAE,+BAA+B,CAAC,WAAW,EAAE,gBAAgB,EAAE,CAAC,GAAG,gBAAgB,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC;IAC/G,CAAC;IACD,OAAO,EAAE,IAAI,EAAE,+BAA+B,CAAC,cAAc,EAAE,CAAC;AAClE,CAAC","sourcesContent":["/**\n * Which rows of a resource type a `DATA_SUBJECT` legal hold covers (#1634) — derived from the SAME\n * subject-export classification an Art. 15 access request uses, so the rows a hold on a person preserves\n * and the rows an access request about that person discloses cannot drift apart.\n *\n * Pure over configuration; the backend computes it once per resource type and caches it.\n */\n\nimport {\n  RelationshipLifecycleModel,\n  type ResourceRelationship,\n} from '../../resources/resources.shared.schemas';\nimport { Resources_SharedUtils } from '../../resources/resources.shared.utils';\nimport type { ResourceType } from '../../resources/resources.shared.core.definitions';\nimport {\n  SubjectExportEdgeDisposition,\n  SubjectExportPurpose,\n  enumerateSubjectExportRelationshipTraversals,\n  isIncludedSubjectExportEdgeDisposition,\n  type SubjectExportRelationshipBuckets,\n} from './subject-export.shared.schemas';\nimport {\n  LegalHoldSubjectAttributionKind,\n  type LegalHoldSubjectAttribution,\n} from './legal-holds.shared.schemas';\n\n/**\n * Plan the attribution of `targetResourceType`'s rows to a person.\n *\n * 1. `USERS` itself → the row IS the person.\n * 2. A resource declared `exportSubject: FORBIDDEN` is outside the export graph → never attributed. Its rows\n *    (credentials, sessions) are the ones an access request withholds, so a hold on the person does not\n *    preserve them either.\n * 3. A resource on an included `USERS` export edge whose rows hold the foreign key → attributed by that field.\n * 4. A resource the export reaches only through another row — a key held on the `USERS` side, or an owned\n *    descendant of an included owned edge — cannot be attributed from its own fields → UNRESOLVABLE, and the\n *    hold covers every row of it in the held tenant. That is the conservative direction on purpose.\n * 5. Anything else is not the person's data → not attributed.\n */\nexport function planLegalHoldSubjectAttribution(input: {\n  readonly usersResourceType: ResourceType;\n  readonly targetResourceType: ResourceType;\n  readonly usersRelationships: SubjectExportRelationshipBuckets;\n  readonly isExportForbidden: (resourceType: ResourceType) => boolean;\n  /** The child-direction relationships of a resource type (for the owned-descendant closure). */\n  readonly childRelationshipsOf: (resourceType: ResourceType) => readonly ResourceRelationship[];\n  /** The FK field of a relationship normalized with the referenced side as `resourceType1`. */\n  readonly resolveForeignKeyField: (relationship: ResourceRelationship) => string;\n}): LegalHoldSubjectAttribution {\n  const { usersResourceType, targetResourceType } = input;\n  if (targetResourceType === usersResourceType) return { kind: LegalHoldSubjectAttributionKind.SUBJECT_ROW };\n  if (input.isExportForbidden(targetResourceType)) return { kind: LegalHoldSubjectAttributionKind.NOT_ATTRIBUTED };\n\n  const included = enumerateSubjectExportRelationshipTraversals(\n    usersResourceType,\n    input.usersRelationships,\n    SubjectExportPurpose.ACCESS_ART_15,\n  ).filter((traversal) => isIncludedSubjectExportEdgeDisposition(traversal.classification.disposition));\n\n  const foreignKeyFields = new Set<string>();\n  let unresolvable = false;\n  for (const traversal of included) {\n    if (traversal.classification.relatedResourceType !== targetResourceType) continue;\n    const holder = Resources_SharedUtils.resolveForeignKeyHolderResourceType(traversal.normalizedRelationship);\n    if (holder === targetResourceType) {\n      foreignKeyFields.add(input.resolveForeignKeyField(traversal.normalizedRelationship));\n    } else {\n      unresolvable = true;\n    }\n  }\n\n  if (!unresolvable) {\n    // The owned-descendant closure: rows below a row the person owns are the person's data too, and their\n    // own fields do not say whose ancestor they hang from.\n    const pending = included\n      .filter((traversal) => traversal.classification.disposition === SubjectExportEdgeDisposition.INCLUDED_OWNED)\n      .map((traversal) => traversal.classification.relatedResourceType);\n    const walked = new Set<string>([String(usersResourceType)]);\n    while (pending.length > 0 && !unresolvable) {\n      const current = pending.shift()!;\n      if (walked.has(String(current))) continue;\n      walked.add(String(current));\n      for (const relationship of input.childRelationshipsOf(current)) {\n        if (relationship.isDisabled === true) continue;\n        const semantics = Resources_SharedUtils.requireResolvedRelationshipSemantics(relationship);\n        if (semantics.handling.lifecycleModelMode !== RelationshipLifecycleModel.DEPENDENT) continue;\n        const child = relationship.resourceType2 as ResourceType;\n        if (child === targetResourceType) {\n          unresolvable = true;\n          break;\n        }\n        pending.push(child);\n      }\n    }\n  }\n\n  if (unresolvable) {\n    return foreignKeyFields.size > 0\n      ? { kind: LegalHoldSubjectAttributionKind.UNRESOLVABLE, foreignKeyFields: [...foreignKeyFields].sort() }\n      : { kind: LegalHoldSubjectAttributionKind.UNRESOLVABLE };\n  }\n  if (foreignKeyFields.size > 0) {\n    return { kind: LegalHoldSubjectAttributionKind.FOREIGN_KEY, foreignKeyFields: [...foreignKeyFields].sort() };\n  }\n  return { kind: LegalHoldSubjectAttributionKind.NOT_ATTRIBUTED };\n}\n"]}

package/dist/esm/compliance/privacy/legal-holds.shared.resources-config.schemas.d.ts

@@ -0,0 +1,37 @@
+/**
+ * Legal holds — resource configuration (#1634).
+ *
+ * Two verbs and two tiers:
+ *
+ *   place   — the tenant's owner (default variant), or an application super-administrator crossing into the
+ *             tenant through the declared door (`admin` variant, requires a usable platform access grant)
+ *   release — the SAME tier that placed the hold, and only that tier (see {@link LegalHoldPlacementTier})
+ *
+ * No client can create, update or delete a hold any other way. The one DELETE is route-less and exists so
+ * the retention-class sweep can dispose of a RELEASED hold once its `AUDIT_LOGS` period has passed.
+ */
+import { LegalHoldPlacementTier, LegalHoldStatus, LegalHolds_Operations } from './legal-holds.shared.schemas';
+import { CoreResourceOperation } from '../../resources/resources.shared.core.definitions';
+import { type ResourceRelationship } from '../../resources/resources.shared.schemas';
+type LegalHoldsCoreOperations = CoreResourceOperation.READ | CoreResourceOperation.LIST | CoreResourceOperation.COUNT | CoreResourceOperation.DELETE;
+export declare const legalHoldsResourceConfiguration_InitializationFactory: (resourcesRelationships: ResourceRelationship[]) => import("../..").ResourceConfiguration<typeof LegalHolds_Operations, LegalHoldsCoreOperations, import("zod").ZodObject<{
+    _id: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("zod").ZodString>>;
+    organizationId: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("zod").ZodString>>>>>;
+    scopeKind: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("zod").ZodEnum<typeof import("./legal-holds.shared.schemas").LegalHoldScopeKind>>>>>>;
+    resourceType: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("zod").ZodOptional<import("zod").ZodString>>>;
+    rowIds: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("zod").ZodOptional<import("zod").ZodArray<import("zod").ZodString>>>>;
+    subjectUserId: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("zod").ZodOptional<import("zod").ZodString>>>>>;
+    legalGround: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("zod").ZodEnum<typeof import("./legal-holds.shared.schemas").LegalHoldGround>>>>>;
+    justification: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("zod").ZodString>>;
+    placementTier: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("zod").ZodEnum<typeof LegalHoldPlacementTier>>>>>>;
+    status: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("zod").ZodDefault<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("zod").ZodEnum<typeof LegalHoldStatus>>>>>>>>;
+    placedByUserId: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("zod").ZodString>>>>;
+    placedAt: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("zod").ZodDate>>>>;
+    releasedByUserId: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("zod").ZodOptional<import("zod").ZodString>>>>>;
+    releasedAt: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("zod").ZodOptional<import("zod").ZodDate>>>>>;
+    releaseReason: import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("@wildo-ai/zod-decorators").DecoratedPrimitiveZodType<import("zod").ZodOptional<import("zod").ZodString>>>>;
+    createdAt: import("zod").ZodOptional<import("zod").ZodDate>;
+    updatedAt: import("zod").ZodOptional<import("zod").ZodDate>;
+}, import("zod/v4/core").$strip>>;
+export {};
+//# sourceMappingURL=legal-holds.shared.resources-config.schemas.d.ts.map

package/dist/esm/compliance/privacy/legal-holds.shared.resources-config.schemas.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"legal-holds.shared.resources-config.schemas.d.ts","sourceRoot":"","sources":["../../../../../src/compliance/privacy/legal-holds.shared.resources-config.schemas.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;GAWG;AAEH,OAAO,EACL,sBAAsB,EAItB,eAAe,EACf,qBAAqB,EACtB,MAAM,8BAA8B,CAAC;AACtC,OAAO,EAAE,qBAAqB,EAAwD,MAAM,mDAAmD,CAAC;AAChJ,OAAO,EAGL,KAAK,oBAAoB,EAC1B,MAAM,0CAA0C,CAAC;AAMlD,KAAK,wBAAwB,GACzB,qBAAqB,CAAC,IAAI,GAC1B,qBAAqB,CAAC,IAAI,GAC1B,qBAAqB,CAAC,KAAK,GAC3B,qBAAqB,CAAC,MAAM,CAAC;AAGjC,eAAO,MAAM,qDAAqD,GAAI,wBAAwB,oBAAoB,EAAE;;;;;;;;;;;;;;;;;;iCAsNhH,CAAC"}

package/dist/esm/compliance/privacy/legal-holds.shared.resources-config.schemas.js

@@ -0,0 +1,223 @@
+/**
+ * Legal holds — resource configuration (#1634).
+ *
+ * Two verbs and two tiers:
+ *
+ *   place   — the tenant's owner (default variant), or an application super-administrator crossing into the
+ *             tenant through the declared door (`admin` variant, requires a usable platform access grant)
+ *   release — the SAME tier that placed the hold, and only that tier (see {@link LegalHoldPlacementTier})
+ *
+ * No client can create, update or delete a hold any other way. The one DELETE is route-less and exists so
+ * the retention-class sweep can dispose of a RELEASED hold once its `AUDIT_LOGS` period has passed.
+ */
+import { LegalHoldPlacementTier, LegalHoldPlaceRequestSchema, LegalHoldReleaseRequestSchema, LegalHoldSchema, LegalHoldStatus, LegalHolds_Operations, } from './legal-holds.shared.schemas.js';
+import { CoreResourceOperation, CoreResourceType, coreResourceShared_FieldIdentifier } from '../../resources/resources.shared.core.definitions.js';
+import { ResourceOperationRiskLevel, ResourceOperationVariantType, } from '../../resources/resources.shared.schemas.js';
+import { createResourceConfiguration_Initialization } from '../../resources/resources-config.shared.factory.js';
+import { ResourceSystemAccessMode } from '../../resources/resources-config.shared.schemas.js';
+import { CORE_APP_ROLES, CORE_ORG_ROLES } from '../../security/authorizations/roles.shared.schemas.js';
+import { DataRetentionClass, RetentionStartPoint } from './retention-schedule.shared.schemas.js';
+export const legalHoldsResourceConfiguration_InitializationFactory = (resourcesRelationships) => createResourceConfiguration_Initialization({
+    mainSchema: LegalHoldSchema,
+    resourceIdentifier: CoreResourceType.LEGAL_HOLDS,
+    resourceFieldIdentifier: coreResourceShared_FieldIdentifier[CoreResourceType.LEGAL_HOLDS],
+    resourceRelationships: resourcesRelationships,
+    isSystemResource: true,
+    /**
+     * No trusted door of any kind. Every deletion path reads the ACTIVE holds through the infrastructure
+     * tier (one indexed query), and every write is a custom verb. A system `create`/`update` would be a
+     * second, unaudited way to place or lift a preservation duty.
+     *
+     * `exportSubject: FORBIDDEN`: `placedByUserId`, `releasedByUserId` and `subjectUserId` put these rows on
+     * a user's access graph, and an included resource with no declaration refuses the whole export. A hold is
+     * the operator's litigation record; disclosing it to the person it concerns can prejudice the very claim
+     * it preserves, and it names the placer and the matter. Left OUT of the bundle and recorded, never
+     * silently dropped.
+     */
+    systemAccessPolicy: {
+        exportSubject: ResourceSystemAccessMode.FORBIDDEN,
+    },
+    /**
+     * A released hold is kept as defence evidence for the `AUDIT_LOGS` period, counted from its release.
+     * An ACTIVE hold has no `releasedAt`, so it never expires — a hold that lapsed on its own would be the
+     * failure it exists to prevent. The organization edge disables the teardown cascade, so the record also
+     * outlives a purged tenant until its period ends.
+     *
+     * Deliberately NOT retention-governed (`retentionPolicy`): a scrubbed-and-hidden hold would be invisible
+     * to the infrastructure read every deletion path consults, which would lift the hold silently.
+     */
+    retentionBinding: {
+        retentionClass: DataRetentionClass.AUDIT_LOGS,
+        startPoint: RetentionStartPoint.CLOSURE_EVENT,
+        closureFieldName: 'releasedAt',
+    },
+    coreOperations: [
+        CoreResourceOperation.READ,
+        CoreResourceOperation.LIST,
+        CoreResourceOperation.COUNT,
+        // Route-less, for the retention-class sweep only.
+        CoreResourceOperation.DELETE,
+    ],
+    operationsConfiguration: {
+        [CoreResourceOperation.READ]: {
+            variants: [
+                {
+                    variantType: ResourceOperationVariantType.API_CALL,
+                    isDefault: true,
+                    roles: [CORE_ORG_ROLES.ORG_OWNER],
+                    riskLevel: ResourceOperationRiskLevel.LOW,
+                },
+                {
+                    // The same read an operator makes into a tenant, through the declared door and a usable grant.
+                    variantType: ResourceOperationVariantType.API_CALL,
+                    isDefault: false,
+                    variantKey: 'admin',
+                    roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],
+                    riskLevel: ResourceOperationRiskLevel.LOW,
+                    // assurance-control: WILDO.ACCESS.CROSS_TENANT_ADMINISTRATION — an operator reads a tenant's holds only through a usable grant.
+                    admitsCrossTenantPlatformAdministration: true,
+                },
+            ],
+        },
+        [CoreResourceOperation.LIST]: {
+            variants: [
+                {
+                    variantType: ResourceOperationVariantType.API_CALL,
+                    isDefault: true,
+                    roles: [CORE_ORG_ROLES.ORG_OWNER],
+                    riskLevel: ResourceOperationRiskLevel.LOW,
+                },
+                {
+                    // The same read an operator makes into a tenant, through the declared door and a usable grant.
+                    variantType: ResourceOperationVariantType.API_CALL,
+                    isDefault: false,
+                    variantKey: 'admin',
+                    roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],
+                    riskLevel: ResourceOperationRiskLevel.LOW,
+                    // assurance-control: WILDO.ACCESS.CROSS_TENANT_ADMINISTRATION — an operator reads a tenant's holds only through a usable grant.
+                    admitsCrossTenantPlatformAdministration: true,
+                },
+            ],
+        },
+        [CoreResourceOperation.COUNT]: {
+            variants: [
+                {
+                    variantType: ResourceOperationVariantType.API_CALL,
+                    isDefault: true,
+                    roles: [CORE_ORG_ROLES.ORG_OWNER],
+                    riskLevel: ResourceOperationRiskLevel.LOW,
+                },
+                {
+                    // The same read an operator makes into a tenant, through the declared door and a usable grant.
+                    variantType: ResourceOperationVariantType.API_CALL,
+                    isDefault: false,
+                    variantKey: 'admin',
+                    roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],
+                    riskLevel: ResourceOperationRiskLevel.LOW,
+                    // assurance-control: WILDO.ACCESS.CROSS_TENANT_ADMINISTRATION — an operator reads a tenant's holds only through a usable grant.
+                    admitsCrossTenantPlatformAdministration: true,
+                },
+            ],
+        },
+        /**
+         * SWEEP ONLY — no client can delete a hold. `INTERNAL_CALL` registers no route; the retention-class
+         * sweep disposes of a released hold at the end of its period, and the delete chokepoint itself never
+         * holds a hold.
+         */
+        [CoreResourceOperation.DELETE]: {
+            variants: [
+                {
+                    variantType: ResourceOperationVariantType.INTERNAL_CALL,
+                    isDefault: true,
+                    roles: [],
+                    riskLevel: ResourceOperationRiskLevel.CRITICAL,
+                },
+            ],
+        },
+        /**
+         * Placing a hold suspends every deletion path for its scope until it is released.
+         *
+         * HIGH with step-up: a hold stops a tenant's retention schedule and its data subjects' erasures, and a
+         * hijacked session must not be able to do that on an old login.
+         *
+         * assurance-control: WILDO.PRIVACY.STORAGE_LIMITATION — deletion suspended under a recorded legal hold.
+         */
+        [LegalHolds_Operations.PLACE]: {
+            variants: [
+                {
+                    variantType: ResourceOperationVariantType.API_CALL,
+                    isDefault: true,
+                    roles: [CORE_ORG_ROLES.ORG_OWNER],
+                    riskLevel: ResourceOperationRiskLevel.HIGH,
+                    resourceOperationLike: CoreResourceOperation.CREATE,
+                    requestDto: LegalHoldPlaceRequestSchema,
+                    // No `auditableEvent.reasonField`: the justification names the matter, and the generic operation row
+                    // it would ride is exported to every SIEM route. The hold keeps it; LEGAL_HOLD_PLACED carries the scope.
+                    // assurance-control: WILDO.IDENTITY.STEP_UP_AUTHENTICATION — re-authentication before a high-impact action.
+                    requiresStepUpAuthentication: true,
+                },
+                {
+                    variantType: ResourceOperationVariantType.API_CALL,
+                    isDefault: false,
+                    variantKey: 'admin',
+                    roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],
+                    riskLevel: ResourceOperationRiskLevel.HIGH,
+                    resourceOperationLike: CoreResourceOperation.CREATE,
+                    requestDto: LegalHoldPlaceRequestSchema,
+                    // No `auditableEvent.reasonField`: the justification names the matter, and the generic operation row
+                    // it would ride is exported to every SIEM route. The hold keeps it; LEGAL_HOLD_PLACED carries the scope.
+                    // Preservation is monotonic — it only ever stops a destruction — so crossing to place it passes
+                    // the reversibility test (`administrative-continuity-floors.md`). Still never ambient: the
+                    // admission requires a usable platform access grant for the tenant.
+                    // assurance-control: WILDO.ACCESS.CROSS_TENANT_ADMINISTRATION — declared crossing, grant required.
+                    admitsCrossTenantPlatformAdministration: true,
+                    // assurance-control: WILDO.IDENTITY.STEP_UP_AUTHENTICATION — re-authentication before a high-impact action.
+                    requiresStepUpAuthentication: true,
+                },
+            ],
+        },
+        /**
+         * Releasing a hold lets the next sweep, purge or erasure proceed. Only an ACTIVE hold, and only by the
+         * tier that placed it — the enabled condition mirrors the server-side refusal in the paired implementation.
+         *
+         * assurance-control: WILDO.PRIVACY.STORAGE_LIMITATION — deletion resumes only on a recorded release.
+         */
+        [LegalHolds_Operations.RELEASE]: {
+            variants: [
+                {
+                    variantType: ResourceOperationVariantType.API_CALL,
+                    isDefault: true,
+                    roles: [CORE_ORG_ROLES.ORG_OWNER],
+                    riskLevel: ResourceOperationRiskLevel.HIGH,
+                    resourceOperationLike: CoreResourceOperation.UPDATE,
+                    requestDto: LegalHoldReleaseRequestSchema,
+                    // No `auditableEvent.reasonField`, for the same reason as `place`: the release reason stays on the hold.
+                    enabledCondition: ({ currentObject }) => currentObject.status === LegalHoldStatus.ACTIVE
+                        && currentObject.placementTier === LegalHoldPlacementTier.ORGANIZATION,
+                    // assurance-control: WILDO.IDENTITY.STEP_UP_AUTHENTICATION — re-authentication before a high-impact action.
+                    requiresStepUpAuthentication: true,
+                },
+                {
+                    variantType: ResourceOperationVariantType.API_CALL,
+                    isDefault: false,
+                    variantKey: 'admin',
+                    roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],
+                    riskLevel: ResourceOperationRiskLevel.HIGH,
+                    resourceOperationLike: CoreResourceOperation.UPDATE,
+                    requestDto: LegalHoldReleaseRequestSchema,
+                    // No `auditableEvent.reasonField`, for the same reason as `place`: the release reason stays on the hold.
+                    // assurance-control: WILDO.ACCESS.CROSS_TENANT_ADMINISTRATION — declared crossing, grant required.
+                    admitsCrossTenantPlatformAdministration: true,
+                    // Any ACTIVE hold: the platform's own, or a tenant's own once that tenant is marked for deletion (its
+                    // owners then hold no authority to release it). The tenant's status is not on the hold, so the server
+                    // decides the second case and refuses a live tenant's hold.
+                    enabledCondition: ({ currentObject }) => currentObject.status === LegalHoldStatus.ACTIVE,
+                    // assurance-control: WILDO.IDENTITY.STEP_UP_AUTHENTICATION — re-authentication before a high-impact action.
+                    requiresStepUpAuthentication: true,
+                },
+            ],
+        },
+    },
+    // The ORGANIZATIONS primary scope is declared on the registry relationship (ORGANIZATIONS → LEGAL_HOLDS).
+});
+//# sourceMappingURL=legal-holds.shared.resources-config.schemas.js.map