@wildo-ai/saas-models 1.1.4 → 1.1.6

package/dist/esm/compliance/privacy/subject-erasure.shared.schemas.d.ts

@@ -1,5 +1,9 @@
 import { type ResourceRelationship } from '../../resources/resources.shared.schemas';
 import type { ResourceType } from '../../resources/resources.shared.core.definitions';
+import { ErasureRetentionMode, type StatutoryRetentionGround } from './impersonalization.shared.schemas';
+import type { ApplicationRetentionSchedule, DataRetentionClass, ResourceRetentionBinding, RetentionStartPoint } from './retention-schedule.shared.schemas';
+import type { SubjectErasureLegalHoldRetention } from './legal-holds.shared.schemas';
+import type { SubjectDataRecipientsStatement, SubjectErasureRecipientOutcome } from './subject-data-recipients.shared.schemas';
 /**
  * What a SUBJECT ERASURE does to one child-direction edge of the subject.
  *
@@ -18,11 +22,12 @@ import type { ResourceType } from '../../resources/resources.shared.core.definit
  * about is exactly where personal data survives an erasure unnoticed.
  *
  * Two members therefore have no runtime action and exist to make the erasure FAIL LOUD
- * ({@link UNCLASSIFIED}, {@link UNSUPPORTED_DEFERRED}), and two describe leaving a row alone for
- * two genuinely different reasons ({@link RETAINED_BY_DECLARATION} vs {@link NOT_OWNED}). Those two
- * are not merged despite sharing a no-op: a data-protection reviewer asking "why is this row still
- * here?" needs "because the author declared it retained" and "because it was never the subject's
- * row" to be different answers, and only the first one is a compliance claim someone made.
+ * ({@link UNCLASSIFIED}, {@link UNSUPPORTED_DEFERRED}), and three describe leaving a row alone for
+ * three genuinely different reasons ({@link RETAINED_BY_DECLARATION}, {@link RESTRICTED_BY_DECLARATION},
+ * {@link NOT_OWNED}). They are not merged despite sharing a no-op: a data-protection reviewer asking
+ * "why is this row still here?" needs "because the author declared it retained", "because its parent
+ * may not be deleted while it exists" and "because it was never the subject's row" to be different
+ * answers, and only the first one is a retention claim someone made.
  */
 export declare enum SubjectErasureDisposition {
     /**
@@ -48,6 +53,45 @@ export declare enum SubjectErasureDisposition {
      * rely on the erased subject row still resolving their foreign keys.
      */
     RETAINED_BY_DECLARATION = "retained_by_declaration",
+    /**
+     * LEAVE THE ROWS EXACTLY AS THEY ARE — a dependent whose edge declares the RESTRICT posture
+     * (`onParentDelete.strategy: REFUSE_WHILE_CHILDREN_EXIST`): the parent's delete is refused while
+     * these rows exist, and nothing about the parent's teardown removes them.
+     *
+     * An erasure scrubs its subject in place and never deletes it, so at the direct level the refusal is
+     * never met and the rows keep resolving their foreign key, as a retained row does. Below a dependent
+     * the erasure DELETES, the same edge holding rows refuses the erasure, as a delete cascade frame does,
+     * because deleting that parent would strand them. Kept apart from
+     * {@link RETAINED_BY_DECLARATION} because the claim differs: that one says "these rows must outlive
+     * their parent", this one says "their parent may not go while they exist". The second is about
+     * referential integrity (an org-unit subtree, the provider-customer mapping a billing account holds
+     * for its financial records), not a retention obligation.
+     *
+     * Like the other leave-alone dispositions, the erasure does not walk below these rows.
+     */
+    RESTRICTED_BY_DECLARATION = "restricted_by_declaration",
+    /**
+     * KEEP THE ROWS, RESTRICTED, UNTIL THE LAW LETS THEM GO (#1635) — the child resource declares
+     * `retentionPolicy.statutoryRetention`: its rows are business records a statute requires kept, bound to
+     * `DataRetentionClass.BUSINESS_RECORDS`.
+     *
+     * GDPR Art. 17(3)(b) exempts them from erasure while the statutory period runs, and the erasure applies
+     * the Art. 18(2) restriction instead: each row takes the resource's declared `retentionPolicy.mode`
+     * treatment (scrubbed where the mode says so) and is flipped to `RETAINED`, which the retention
+     * row-hide chokepoints exclude from every ordinary read and write. The rows are LISTED in
+     * `SubjectErasureReport.restrictedUnderStatutoryRetention` with their ground and the instant their period
+     * ends, and the retention-class sweep deletes them then. Every other edge of the request is erased as
+     * usual — a statutory row never refuses the erasure.
+     *
+     * An EXECUTING disposition, like {@link IMPERSONALIZE_AND_RETAIN}, whose treatment it shares. Kept apart
+     * from it, and from {@link RETAINED_BY_DECLARATION}, because the CLAIM differs: those say the author chose
+     * to keep the rows; this says the law requires it, names the ground, and has an end. A reviewer asking
+     * "why is this row still here, and until when?" needs that difference in the receipt, not inferred.
+     *
+     * Like the other retain dispositions, the erasure does not walk below these rows: a kept row still
+     * anchors its own dependents.
+     */
+    RESTRICTED_UNDER_STATUTORY_RETENTION = "restricted_under_statutory_retention",
     /**
      * LEAVE THE ROWS ALONE — the edge is not an ownership edge at all
      * (`lifecycleModelMode` is `INDEPENDENT` or `LINK_ONLY`, or the relationship is disabled). The
@@ -83,6 +127,34 @@ export interface SubjectErasureEdgeClassification {
      */
     reason: string;
 }
+/**
+ * The only part of a child's `retentionPolicy` an erasure classification reads (#1279).
+ *
+ * Structural and minimal on purpose: the classifier needs the erasure TREATMENT and nothing else, and
+ * narrowing the parameter to this keeps every caller — the runtime orchestrator, the registry sweep and
+ * the boot-time guards, which each hold a differently-shaped configuration record — able to answer
+ * without first building a full `ResourceRetentionPolicy` it does not otherwise need.
+ *
+ * `mode` is optional because a caller may legitimately hold a resource entry with no retention opt-in;
+ * that is the same answer as passing `undefined` and means "this child declares no erasure treatment".
+ */
+export interface SubjectErasureChildRetentionDeclaration {
+    readonly mode?: ErasureRetentionMode;
+    /**
+     * The statutory ground the child keeps its rows on (#1635). Present only on a `BUSINESS_RECORDS`-bound
+     * resource — the resource factory refuses it anywhere else. Its presence is what turns the retain
+     * disposition into {@link SubjectErasureDisposition.RESTRICTED_UNDER_STATUTORY_RETENTION}.
+     */
+    readonly statutoryRetention?: {
+        readonly ground: StatutoryRetentionGround;
+    };
+}
+/**
+ * True when the erasure runs a teardown for an edge of this disposition, so `executed: false` on it is a
+ * DECLINE — personal data possibly still live — and never an expected leave-alone. Read an edge's
+ * `executed` through this, never through a hand-written list of members.
+ */
+export declare function isExecutingSubjectErasureDisposition(disposition: SubjectErasureDisposition): boolean;
 /**
  * True when a disposition must stop the erasure before any write lands.
  *
@@ -106,28 +178,235 @@ export declare function isBlockingSubjectErasureDisposition(disposition: Subject
  *  2. **`childOperations.lifecycle.onParentDelete`** — for an owned dependent, what did the author
  *     declare happens when the parent stops owning it: hard-delete, scrub-and-retain, or nothing.
  *
- * ## The semantic caveat, stated plainly
+ *  3. **the child's own `retentionPolicy`** — the ONE declaration whose entire subject is this
+ *     question: *"`retentionPolicy.mode` on a resource says WHAT erasure does to a row"*
+ *     (`retention-schedule.shared.schemas.ts`). Supplied through `resolveChildRetentionPolicy` so this
+ *     function stays pure.
+ *
+ * ## The semantic caveat — CORRECTED 2026-09-17 (#1279), and the correction is the point
  *
  * `onParentDelete` literally answers "what happens when the parent row is DELETED", and an erasure
- * does NOT delete the subject — it scrubs and keeps it. v1 deliberately treats the two questions as
- * one because they have the same answer for every edge in the shipped registry, and because an
- * author who declared "this dependent dies with its parent" has already said the thing that
- * matters: the dependent's data has no life of its own once the subject's does not.
+ * does NOT delete the subject — it scrubs and keeps it. This function used to treat the two questions
+ * as one, on a stated premise: *"they have the same answer for every edge in the shipped registry"*.
+ *
+ * **That premise was false, and it had never been measured.** Measured across `engine/`, `platform/`
+ * and `examples/`: 28 edges reached a `DELETE` erasure disposition while the child resource declared
+ * `retentionPolicy` — i.e. an erasure deleting rows whose own resource says an erasure keeps them.
+ *
+ * What made it invisible was a SCHEMA DEFAULT. `strategy` carried
+ * `.default(ChildLifecycleStrategy.DELETE)`, so every parsed edge presented `strategy: 'delete'` as an
+ * own property whether or not a human had ever considered the question — and **28 of those 28 edges
+ * reached DELETE through that default. Not one author had written `strategy: DELETE` for a
+ * retain-declaring resource.** The default was removed (see `ChildLifecycleOnDeleteConfigSchema`), so
+ * absence now arrives here intact and this function can tell a decision from a silence.
+ *
+ * ## The precedence, which decides no legal question
  *
- * They are NOT the same question though, and the day a resource needs to answer them differently
- * (retain a dependent on erasure that it hard-deletes on parent-delete, or the reverse) the
- * expressible extension is a sibling `onSubjectErasure` axis on the same edge, defaulting to this
- * derivation. Adding that axis speculatively now would give app authors a second knob with no
- * consumer and two ways to say the same thing.
+ * | child `retentionPolicy` | this edge's `strategy` | disposition |
+ * |---|---|---|
+ * | declared (retain) | **absent** | the retain treatment — the author answered the ERASURE question and nobody answered the teardown one. A default may not overrule a declaration |
+ * | declared (retain) | authored `DELETE` | `CONTRADICTED_BY_DECLARATIONS` — refused |
+ * | declared (retain) | authored `IMPERSONALIZE_AND_RETAIN` | they agree; the edge's arm below runs |
+ * | none | anything, including absent | unchanged — no erasure declaration exists to honour |
+ *
+ * Note what is deliberately NOT done: "retain wins" is not made a blanket default over an AUTHORED
+ * `DELETE`. {@link findSubjectErasureRetainDeleteConflicts} rejects exactly that reasoning for the
+ * edge-vs-edge case — *it decides a legal question on the author's behalf; neither default is safe, so
+ * no default* — and that rejection stands here. Deleting data a retention obligation required keeping
+ * and stranding data an erasure claimed to have removed are both unsafe, and nothing in the
+ * configuration says which the author meant. The only thing that changed is that a SCHEMA DEFAULT may
+ * no longer impersonate an author's decision.
+ *
+ * A sibling `onSubjectErasure` axis on the edge was reconsidered and stays rejected: `retentionPolicy`
+ * already IS the erasure axis, and adding a second one would give app authors two ways to say the same
+ * thing — the objection the previous version of this note raised against it, which survives its own
+ * premise being wrong.
  *
  * Pure and side-effect free — no registry lookups, no I/O — so it is equally usable from a runtime
  * orchestrator and from a boot-time guard.
  */
-export declare function classifySubjectErasureDisposition(relationship: ResourceRelationship): SubjectErasureEdgeClassification;
+export declare function classifySubjectErasureDisposition(relationship: ResourceRelationship, resolveChildRetentionPolicy: (resourceType: ResourceType) => SubjectErasureChildRetentionDeclaration | undefined): SubjectErasureEdgeClassification;
+/**
+ * One DESCENDANT edge an erasure must account for — an edge below the subject's direct dependents,
+ * planned from configuration before anything runs (#976).
+ *
+ * `parentResourceType` is the resource whose rows the erasure tears down and that owns this edge;
+ * the classification is the same one a direct edge gets, from the same shared classifier, so a
+ * descendant and a direct edge can never disagree about what an identical declaration means.
+ */
+export interface SubjectErasureDescendantEdgePlan {
+    /** The edge itself, as the parent resource's configuration declares it. */
+    relationship: ResourceRelationship;
+    /** The resource that owns this edge — its rows are the ones being torn down above it. */
+    parentResourceType: ResourceType;
+    classification: SubjectErasureEdgeClassification;
+}
+/**
+ * Plan every DESCENDANT edge a subject erasure walks below ONE direct dependent (#976).
+ *
+ * ## What an erasure walks, and why exactly that
+ *
+ * - **Below a `DELETE` edge — everything, at every depth, regardless of `maxDepth`.** The rows are
+ *   gone, so whatever depended on them has lost its owner; an erasure that stops at a depth budget
+ *   leaves the subject's data one level down with nothing left to reach it. `maxDepth` is a
+ *   parent-DELETE performance budget and keeps meaning exactly that on the delete cascade.
+ * - **Below an `IMPERSONALIZE_AND_RETAIN` or `RESTRICTED_UNDER_STATUTORY_RETENTION` edge — nothing.**
+ *   The retained row survives, scrubbed where its mode says so, so
+ *   its own dependents still have their owner and remain bound to THAT row's future lifecycle. The
+ *   retention obligation that keeps the row is the obligation that keeps what hangs off it; tearing
+ *   those down would destroy records a legal obligation required keeping, and scrubbing them would
+ *   need a declaration nobody made. This matches the cascade itself, whose retain arm never recurses.
+ * - **Below `RETAINED_BY_DECLARATION` / `NOT_OWNED` — nothing.** The rows are not touched.
+ *
+ * Every child-direction edge of every walked resource is returned — including the ones that do
+ * nothing — because the receipt is total over what the erasure walked, exactly as it is at the
+ * direct level. A blocking classification anywhere in the plan must refuse the erasure BEFORE its
+ * transaction opens; returning it (rather than throwing here) lets the caller name every one.
+ *
+ * ## Termination
+ *
+ * The walk is over RESOURCE TYPES, not rows, so each type's edges are planned once: a self-referential
+ * edge (a folder of folders) or a cycle between types terminates here, while the row-level cascade
+ * keeps its own visited-row guard.
+ *
+ * Pure: the caller supplies the lookup, so a boot-time guard can run the same planner the runtime
+ * does rather than re-deriving it.
+ *
+ * @param directChildResourceType - the far side of the subject's direct `DELETE` edge.
+ * @param resolveChildDirectionRelationships - the child-direction edges of a resource type, or
+ *   `undefined` when the type has no configuration in this process (nothing is planned below it; the
+ *   runtime cascade then declines that edge and reports it as not executed).
+ * @param resolveChildRetentionPolicy - a resource type's declared `retentionPolicy`, or `undefined`
+ *   when it declares none. Injected for the same reason as the lookup above: it keeps this planner
+ *   pure, so a boot-time guard classifies a descendant edge exactly as the runtime will (#1279).
+ */
+export declare function planSubjectErasureDescendantEdges(directChildResourceType: ResourceType, resolveChildDirectionRelationships: (resourceType: ResourceType) => ResourceRelationship[] | undefined, resolveChildRetentionPolicy: (resourceType: ResourceType) => SubjectErasureChildRetentionDeclaration | undefined): SubjectErasureDescendantEdgePlan[];
+/**
+ * One resource an erasure's plan reaches both to KEEP its rows and to DELETE them (#1017).
+ *
+ * `TEdge` is whatever the caller planned — a direct edge, a descendant edge, or its own record of either —
+ * so the orchestrator can name the edges the way its refusal already names unresolved ones.
+ */
+export interface SubjectErasureRetainDeleteConflict<TEdge> {
+    /** The resource on the far side of every edge below. */
+    resourceType: ResourceType;
+    /**
+     * Edges that keep these rows under a treatment (`IMPERSONALIZE_AND_RETAIN`, or
+     * `RESTRICTED_UNDER_STATUTORY_RETENTION` since #1635), in plan order.
+     */
+    retainingEdges: TEdge[];
+    /** Edges that hard-delete these rows (`DELETE`), in plan order. */
+    deletingEdges: TEdge[];
+}
+/**
+ * Find every resource a subject erasure's WHOLE plan reaches through both a retaining edge and a deleting
+ * edge (#1017). The erasure REFUSES before its transaction opens when this returns anything.
+ *
+ * ## The shape
+ *
+ * Each edge applies its own declared treatment to the rows it reaches: `DELETE` hard-deletes them,
+ * `IMPERSONALIZE_AND_RETAIN` scrubs them and keeps them. Two DIFFERENT paths can reach the same resource — a
+ * `people → records` retain edge beside `people → profiles → notes → records` delete, or two edges on one
+ * resource through two foreign keys — and nothing in either declaration says what happens to a row BOTH
+ * reach. Before this, the answer was the walk order: a row kept by the retain edge could still be deleted
+ * when the delete edge's cascade got there, and #976 could only make the receipt admit it (`executed: false`).
+ *
+ * ## Why REFUSE, and why at the level of resource types
+ *
+ * The two declarations contradict each other for the rows they share, and neither outranks the other in
+ * configuration. Refusing is the one answer that needs no new meaning: it surfaces the contradiction to the
+ * author, who owns both declarations and can make them agree — declare the delete edge
+ * `IMPERSONALIZE_AND_RETAIN` too, declare the retain edge `DELETE`, or disable one edge's teardown
+ * (`onParentDelete.enabled: false`) — on the ground the legal obligation actually gives.
+ *
+ * The check is over resource TYPES, not rows, on purpose. Whether two edges share a row is only knowable by
+ * reading rows, which the pre-flight must not do (every refusal here lands before the first read and write),
+ * and it changes as rows are written, so a row-level "no overlap today" would be a guess about the future.
+ * An edge pair that can never share a row in practice is still refused; the remedy is the same one-edge edit.
+ *
+ * ## Rejected: a precedence where retain wins
+ *
+ * "Keep a row whenever any edge retains it" was considered and rejected, for three reasons:
+ *
+ * - **It decides a legal question on the author's behalf.** A `DELETE` edge is a declaration too — that the
+ *   rows hold nothing worth keeping once their owner is gone. GDPR Art. 17(3) lists the grounds on which the
+ *   right to erasure does not apply (a legal obligation, the defence of legal claims, archiving, …), and
+ *   Art. 5(2) makes the controller "responsible for, and be able to demonstrate compliance with" the
+ *   principles. Keeping personal data an explicit declaration said to remove therefore needs a ground the
+ *   controller can name, and a framework default names none. "Delete wins" fails the other way, destroying
+ *   records a retention obligation required keeping. Neither default is safe, so no default.
+ *   spec-cite: Regulation (EU) 2016/679, Art. 5(2) (accountability) and Art. 17(3)(a)–(e) (exceptions to the right to erasure).
+ * - **Only its row-level form is faithful, and that form cannot be decided before the transaction.** A
+ *   TYPE-level "retain wins" could be decided pre-flight, but it would keep every row of the resource,
+ *   including rows only the delete edge reaches and the retain edge never touches — rows no retention
+ *   declaration covers. The faithful rule is ROW-level: the delete walk skips each row a retain edge kept and
+ *   prunes everything it planned below that row (a kept row still anchors its own dependents), per row,
+ *   mid-transaction. The pre-flight plan is over types and cannot express that, so the
+ *   refusal-before-any-write guarantee the rest of the erasure keeps would be lost.
+ * - **It adds a meaning with no vocabulary for its opposite.** Once precedence exists, an author who needs
+ *   the delete to win has no way to say so.
+ *
+ * ## What is NOT a conflict
+ *
+ * Only `DELETE` against a retaining treatment the erasure EXECUTES — `IMPERSONALIZE_AND_RETAIN`, and
+ * `RESTRICTED_UNDER_STATUTORY_RETENTION` (#1635), which keeps its rows by the same treatment. Two deleting or
+ * two retaining edges agree. `NOT_OWNED` rows are not the subject's, and the erasure never discovers them.
+ * Two cases are deliberately NOT refused here. Each is an open decision, not an answer this rule gives:
+ *
+ * - **(a) A `RETAINED_BY_DECLARATION` dependent beside a `DELETE` path to the same resource (#1084).** The
+ *   erasure never discovers `enabled: false` rows, and a row with two parents that survives one teardown and
+ *   dies with the other is also what an ordinary parent delete does. **DECIDED 2026-09-17: this stays out.**
+ *   `enabled: false` executes nothing, so there are not two treatments to reconcile — and the refusal below
+ *   names `onParentDelete.enabled: false` as its own remedy, so counting it as a conflict would make that
+ *   remedy produce the next refusal. The full argument is at the classification site.
+ * - **(b) A delete closure that cycles back to the SUBJECT's own resource type while the subject row is
+ *   retained (#1085).** The subject's retention is the erasure's own final step (the scrub), not an edge, so
+ *   this detector — which reads only edges — cannot see it. **CLOSED 2026-09-17 by
+ *   {@link findSubjectErasureSubjectTypeDeleteEdges}**, a sibling that takes the subject's own type as an
+ *   argument precisely because it is not derivable from the edges.
+ *
+ * Pure, so a boot-time guard can run it over the same plan the runtime refuses on.
+ *
+ * @param plannedEdges - every edge of ONE erasure: the subject's direct edges AND every descendant edge
+ *   planned below its deleted dependents, each carrying its classification.
+ * @returns one entry per conflicting resource, in the order the resource is first reached.
+ */
+export declare function findSubjectErasureRetainDeleteConflicts<TEdge extends {
+    classification: SubjectErasureEdgeClassification;
+}>(plannedEdges: readonly TEdge[]): Array<SubjectErasureRetainDeleteConflict<TEdge>>;
+/**
+ * What happened on ONE descendant edge of an executed erasure (#976) — reported exactly like a direct
+ * edge: its disposition, the configuration that justified it, and whether its teardown ran.
+ */
+export interface SubjectErasureDescendantEdgeOutcome extends SubjectErasureEdgeClassification {
+    /** The resource that owns this edge. */
+    parentResourceType: ResourceType;
+    /**
+     * `true` when every teardown the erasure reached on this edge ran, `false` when any was declined, when
+     * this DELETE edge reached rows an earlier retain edge of the same walk scrubbed and KEPT (they are not
+     * gone, whatever this edge declares — unreachable since #1017, which refuses a plan that retains and deletes
+     * one resource before it runs, and kept as defence in depth), or when an edge ABOVE it was declined (its rows were then never
+     * walked, so nothing can be said about what they still hold). `false` on a non-executing disposition
+     * is expected, as on a direct edge.
+     *
+     * An executing edge the walk never had to dispatch — its parent resource had no rows of the subject's
+     * left to tear down — is `true`: that is a teardown with nothing to do, not a decline.
+     */
+    executed: boolean;
+}
 /** Per-edge outcome of an executed erasure — the classification plus what actually happened. */
 export interface SubjectErasureEdgeOutcome extends SubjectErasureEdgeClassification {
     /**
-     * `true` when the erasure ran a teardown for this edge.
+     * Every edge below this one that the erasure walked, flat and in plan order (#976). Empty for a
+     * non-executing disposition and for `IMPERSONALIZE_AND_RETAIN`, which retains its rows and therefore
+     * does not walk below them — see {@link planSubjectErasureDescendantEdges}.
+     */
+    descendantEdges: SubjectErasureDescendantEdgeOutcome[];
+    /**
+     * `true` when the erasure ran a teardown for this edge AND for every descendant edge below it whose
+     * disposition executes (#976). A declined descendant therefore makes its direct edge `false`: a
+     * reader who only counts direct edges must not read a subtree that still holds live data as erased.
+     * {@link descendantEdges} says which descendant it was.
      *
      * Reports that the teardown RAN, not that rows existed — discovery finding no dependents is a
      * teardown that ran with nothing to do, and is `true`.
@@ -137,9 +416,12 @@ export interface SubjectErasureEdgeOutcome extends SubjectErasureEdgeClassificat
      * - a NON-executing disposition (`RETAINED_BY_DECLARATION`, `NOT_OWNED`) ⇒ the erasure deliberately
      *   left the rows alone, and `false` is the expected, correct answer;
      * - an EXECUTING disposition (`DELETE`, `IMPERSONALIZE_AND_RETAIN`) ⇒ the cascade DECLINED the edge
-     *   (the child had no registered service or repository, or the depth budget was spent). The
-     *   subject's data is partly still live. This pairing should never appear in a healthy system; it is
-     *   logged at ERROR when it happens, with the missing registration named.
+     *   (the child had no registered service or repository), or an edge BELOW it did not tear its rows
+     *   down (see `descendantEdges`) — declined the same way, or a DELETE edge that reached rows an
+     *   earlier retain edge of the walk kept. An erasure never spends a depth budget — it walks every
+     *   descendant. The subject's data is partly still live. This pairing should never appear in a
+     *   healthy system; it is logged at ERROR when it happens, naming the missing registration or the
+     *   descendant edges concerned.
      *
      * ⚠️ This flag was set unconditionally until 2026-08-11 — it meant "the dispatcher returned without
      * throwing" and reported a skipped edge as torn down. Anything persisted before that date overstates
@@ -180,6 +462,12 @@ export declare enum SubjectErasureExternalEffectStatus {
      * looked and found nothing, this means nobody looked.
      */
     NOT_REGISTERED = "not-registered",
+    /**
+     * A bound external-effects port returned no usable report. The local erasure committed, but
+     * external outcomes are UNKNOWN: neither no work nor no change can be inferred. Incomplete;
+     * reconcile provider state before retrying work that may already have succeeded.
+     */
+    UNMEASURED = "unmeasured",
     /**
      * The external system's binding DECLARES its rows hold no personal/subject data
      * (`HttpApiErasureStance.NO_SUBJECT_DATA`, ETL D6 stance 6a) — nothing was erased because,
@@ -229,6 +517,12 @@ export interface SubjectErasureExternalEffectOutcome {
  * Returned to the caller (rather than only logged) so the flow that fronts the request can record
  * or surface it: every edge of the subject appears exactly once with the disposition applied and
  * the configuration that justified it, which is the evidence a data-protection response needs.
+ *
+ * assurance-control: WILDO.PRIVACY.ERASURE_PROPAGATION — an erasure accounts per store instead of
+ * one verdict: each direct dependent edge with whether its teardown ran, each descendant edge the
+ * erasure walked below it (nested in `descendantEdges`, folded into the direct edge's `executed`),
+ * each registered external effect with its own outcome. The engine returns this and persists none of
+ * it; retaining it is the calling application's job.
  */
 export interface SubjectErasureReport {
     /** The erased subject's resource type. */
@@ -238,17 +532,37 @@ export interface SubjectErasureReport {
     /** Every child-direction edge of the subject, classified, in registry order. */
     edges: SubjectErasureEdgeOutcome[];
     /**
-     * `true` once the subject rows themselves were scrubbed and flipped to `RETAINED`. Always `true`
-     * on a successful erasure — an erasure that could not retain its subject throws rather than
-     * returning a report.
+     * `true` once EVERY subject row was scrubbed and flipped to `RETAINED`. An erasure that could not retain its
+     * subject throws rather than returning a report — with one exception: a subject row under an active legal hold
+     * (#1634) is left as it is, reported in {@link heldByLegalHold}, and this is `false` while the rest completes.
+     * Also `false` when no subject row was found (`subjectIds` empty).
      */
     subjectImpersonalized: boolean;
+    /**
+     * Whose sessions this erasure ended, and whether resolving them failed.
+     *
+     * A LOCAL fact, not an external effect: the revocation is a write to our own session fence, applied
+     * at the scrub chokepoint so it covers every path that scrubs a person's row. It is recorded here
+     * because "the erased person can no longer be logged in" is exactly what a data-protection response
+     * has to be able to evidence.
+     *
+     * `lookupFailed` is kept distinct from an empty `principalUserIds`: no principals is a legitimate
+     * outcome (the resource declared `NO_PRINCIPAL`), whereas a failed lookup means the person may
+     * still hold a live session — and the two must never look alike in a compliance artifact.
+     */
+    sessionRevocation?: {
+        principalUserIds: string[];
+        lookupFailed: boolean;
+    };
     /**
      * Outcomes of the external, non-transactional effects the erasure triggered — every SYSTEM WE
      * DO NOT OWN that the subject's personal data reached: registered effect handlers (a billing
      * provider), and each HTTP_API-bound resource linked to the subject (one entry per resource,
      * `effectRef: 'http-api:<resourceType>'`, carrying its declared D6 erasure stance's outcome).
      *
+     * A malformed response from a bound registry produces one aggregate UNMEASURED entry,
+     * identifying that boundary rather than inventing individual provider outcomes.
+     *
      * Empty when no effect was registered for the subject's resource type. These run AFTER the local
      * scrub has committed, so a failure here cannot roll the erasure back — the local data is
      * already gone and re-running the whole erasure would be wrong. That asymmetry is precisely why
@@ -258,22 +572,180 @@ export interface SubjectErasureReport {
      * Check {@link isIncompleteSubjectErasureExternalEffect} over these before treating a report as a
      * complete erasure.
      */
+    externalEffects: SubjectErasureExternalEffectOutcome[];
     /**
-     * Whose sessions this erasure ended, and whether resolving them failed.
+     * Every row the erasure KEPT because a statute requires it, with the ground and the instant it may go
+     * (#1635) — what an operator tells the data subject under GDPR Art. 12(4) and Art. 19: what was not
+     * erased, why, and until when.
      *
-     * A LOCAL fact, not an external effect: the revocation is a write to our own session fence, applied
-     * at the scrub chokepoint so it covers every path that scrubs a person's row. It is recorded here
-     * because "the erased person can no longer be logged in" is exactly what a data-protection response
-     * has to be able to evidence.
+     * One entry per row of a {@link SubjectErasureDisposition.RESTRICTED_UNDER_STATUTORY_RETENTION} edge
+     * (direct or below a deleted dependent) whose statutory period had NOT ended at the erasure: still
+     * running, or not yet started. Rows only; no field of the row travels here. Empty when nothing
+     * statutory was reached — which is the ordinary answer, and not a sign the capability is off.
+     */
+    restrictedUnderStatutoryRetention: SubjectErasureStatutoryRestriction[];
+    /**
+     * Rows of a statutory edge whose period had ALREADY ended when the erasure reached them (#1635).
      *
-     * `lookupFailed` is kept distinct from an empty `principalUserIds`: no principals is a legitimate
-     * outcome (the resource declared `NO_PRINCIPAL`), whereas a failed lookup means the person may
-     * still hold a live session — and the two must never look alike in a compliance artifact.
+     * No longer exempt, so they are NOT listed under a legal ground above. The erasure does not delete them
+     * inline: it gives them the same restriction (hidden, frozen, processed for nothing) and the NEXT run of the
+     * retention-class sweep disposes of them through the service layer, cascades included — the one mechanism
+     * that deletes bound rows at period end. Deleting inline was rejected because the erasure's pre-flight
+     * plans walks only below DELETE edges, so the refusals that guard an erasure would not cover the cascades
+     * below these rows. The window is one sweep interval.
      */
-    sessionRevocation?: {
-        principalUserIds: string[];
-        lookupFailed: boolean;
+    releasedToRetentionSweep: SubjectErasureReleasedToRetentionSweep[];
+    /**
+     * Every row the erasure left EXACTLY as it was because a legal hold covers it (#1634) — neither deleted
+     * nor scrubbed, since impersonalization destroys what a hold preserves. One entry per row, with the
+     * grounds, which are what the data subject is told (Art. 17(3)(b)/(e)). The rest of the erasure
+     * completes; an edge whose rows were held reports `executed: false`, and a held subject row leaves
+     * `subjectImpersonalized: false`.
+     */
+    heldByLegalHold: SubjectErasureLegalHoldRetention[];
+    /**
+     * Every recipient that may hold the erased subject's data, and what the erasure did about each (#1710) — the list
+     * Art. 19 asks the controller to communicate to, and to give the data subject on request.
+     *
+     * `statement` names the recipients and the operator's role for the subject's resource type; `outcomes` gives each
+     * operator-account recipient a status (a registered effect's, or the one its declared stance decides — UNMEASURED
+     * when it declares none), and names each tenant-account recipient for the tenant to notify. A recipient no
+     * registered effect reached ALSO appears in {@link externalEffects} under `recipient:<ref>`, so completeness is
+     * judged by the one predicate every reader already uses.
+     */
+    recipients: {
+        statement: SubjectDataRecipientsStatement;
+        outcomes: SubjectErasureRecipientOutcome[];
     };
-    externalEffects: SubjectErasureExternalEffectOutcome[];
 }
+/** One row a subject erasure restricted under a statutory ground instead of erasing (#1635). */
+export interface SubjectErasureStatutoryRestriction {
+    resourceType: ResourceType;
+    rowId: string;
+    /** The GDPR Art. 17(3) exemption the resource declares. */
+    ground: StatutoryRetentionGround;
+    /** The class whose period applies — `BUSINESS_RECORDS` by construction; carried so the entry reads alone. */
+    retentionClass: DataRetentionClass;
+    /** Where the period is counted from — what an operator names when {@link retainedUntil} is `null`. */
+    retentionStartPoint: RetentionStartPoint;
+    /**
+     * The instant after which the row is deleted, under the schedule in force at the erasure.
+     *
+     * `null` when that instant is not yet knowable: the start point has not occurred (a `SCOPE_DELETED`
+     * row whose organization still exists), or the application declares no `BUSINESS_RECORDS` period.
+     * Never a guess — the row stays restricted either way, and the sweep deletes it once both are known.
+     */
+    retainedUntil: Date | null;
+}
+/** One row of a statutory edge whose period had already ended at the erasure (#1635). */
+export interface SubjectErasureReleasedToRetentionSweep {
+    resourceType: ResourceType;
+    rowId: string;
+    /** The instant its statutory period ended — at or before the erasure. */
+    retentionEndedAt: Date;
+}
+/**
+ * Split the rows a statutory edge reached into those still under the statute and those already released
+ * (#1635). Pure: the executor passes the discovered rows, the resource's binding and ground, the schedule it
+ * read, and the erasure instant.
+ *
+ * The rule, and its one boundary: a row is released only when `retainedUntil < now` — exactly the rows the
+ * retention-class sweep's strict `start < now − days` (`resolveBoundRetentionCutoff`) selects, because
+ * `start + days < now` is the same inequality. A row whose period ends AT this instant is still under the
+ * statute and the sweep keeps it, so it is listed as restricted. Everything else is restricted too,
+ * including a row whose instant is unknown (`null`): an unknown end is never an ended one.
+ *
+ * A row without an id is skipped rather than listed: an entry the operator cannot find is not evidence.
+ */
+export declare function partitionStatutoryRetentionRows(input: {
+    resourceType: ResourceType;
+    rows: readonly Record<string, unknown>[];
+    binding: ResourceRetentionBinding;
+    ground: StatutoryRetentionGround;
+    schedule: ApplicationRetentionSchedule | undefined;
+    now: Date;
+}): {
+    restricted: SubjectErasureStatutoryRestriction[];
+    released: SubjectErasureReleasedToRetentionSweep[];
+};
+/**
+ * Edges that DELETE a resource whose OWN `retentionPolicy` says an erasure keeps its rows (#1279).
+ *
+ * ## The contradiction
+ *
+ * A resource's `retentionPolicy` is the declaration whose entire subject is what an erasure does to
+ * its rows, and the config factory refuses it unless it is paired with a `dataSubjectPolicy` — so it
+ * is among the most deliberate statements an author makes. An edge that nevertheless AUTHORS
+ * `onParentDelete.strategy: DELETE` says the opposite about the same rows. Nothing in the
+ * configuration ranks the two, so an erasure must refuse rather than pick: deleting could destroy
+ * data a retention obligation required keeping, and retaining could strand personal data the erasure
+ * claimed to have removed. That is the same reasoning {@link findSubjectErasureRetainDeleteConflicts}
+ * gives for refusing rather than defaulting, applied one level down — there between two EDGES, here
+ * between an edge and the RESOURCE it points at.
+ *
+ * ## Why a DELETE disposition here is necessarily AUTHORED
+ *
+ * Since #1279 `classifySubjectErasureDisposition` applies the child's retention treatment whenever the
+ * edge is SILENT, so a `DELETE` disposition toward a retain-declaring child can only have come from an
+ * author writing `strategy: DELETE`. This filter therefore needs no second look at the declaration:
+ * the invariant is expressed once, in the classifier, and read here. Do NOT re-derive "was it
+ * authored?" from the relationship — that would be a second copy of the rule, free to drift.
+ *
+ * ## Measured population: ZERO, and that is the point
+ *
+ * Across `engine/`, `platform/` and `examples/` on 2026-09-17, 28 edges deleted a retain-declaring
+ * resource and **not one of them authored `DELETE`** — every one reached that outcome through the
+ * schema default this fix removed. So the shipped registry trips this detector nowhere, which is the
+ * shape worth having: it cannot regress silently, and an application that later authors the
+ * contradiction meets a refusal before any read or write rather than an erasure that quietly
+ * contradicts its own declarations.
+ *
+ * Pure, so a boot-time guard can run it over the same plan the runtime refuses on.
+ *
+ * @param plannedEdges - every edge of ONE erasure, each carrying its classification.
+ * @param resolveChildRetentionPolicy - a resource type's declared `retentionPolicy`, or `undefined`.
+ * @returns the offending edges, in plan order. Empty is the healthy answer.
+ */
+export declare function findSubjectErasureRetentionContradictedEdges<TEdge extends {
+    classification: SubjectErasureEdgeClassification;
+}>(plannedEdges: readonly TEdge[], resolveChildRetentionPolicy: (resourceType: ResourceType) => SubjectErasureChildRetentionDeclaration | undefined): TEdge[];
+/**
+ * Edges whose DELETE would reach the SUBJECT'S OWN resource type (#1085).
+ *
+ * ## The hazard
+ *
+ * A subject erasure SCRUBS the subject row and keeps it — that is the erasure's contract with the data
+ * subject, and it is unconditional: `eraseSubjectInPlace` refuses outright when the subject resource
+ * declares no `retentionPolicy`. Since #976 the walk also descends below every dependent it deletes, so
+ * a DELETE closure that comes back round to the subject's own type would delete the very row the
+ * erasure promised to retain — and the receipt would still report it retained.
+ *
+ * That last part is why this refuses rather than skips. `SubjectErasureDescendantWalk`'s accounting is
+ * written so a receipt can never OVERSTATE an erasure; deleting the scrubbed subject would overstate in
+ * the one way nothing downstream can detect, because every edge reports exactly what it did.
+ *
+ * ## Why the sibling detector cannot do this
+ *
+ * {@link findSubjectErasureRetainDeleteConflicts} compares two EDGE dispositions. The subject's retention
+ * is not an edge — no relationship declares it — so the subject's type is passed in here rather than
+ * inferred. It is the whole reason this is a second function and not a case in the first.
+ *
+ * ## Measured 2026-09-17: the population is EMPTY, and that is the point
+ *
+ * In the engine's core graph `USERS` is never the CHILD of a composition. The one relationship naming it
+ * second — `ORGANIZATIONS → USERS` — is a `RelationshipNature.ASSOCIATION` through
+ * `ORGANIZATION_MEMBERS`, and an association carries no `onParentDelete` teardown, so no closure can
+ * reach it. A guard over an empty population costs nothing at runtime and is exactly the shape worth
+ * having: it cannot regress silently, and an application that later declares such an edge meets a
+ * refusal before any read or write instead of an erasure that quietly contradicts itself.
+ *
+ * Pure, so a boot-time guard can run it over the same plan the runtime refuses on.
+ *
+ * @param plannedEdges - every edge of ONE erasure, each carrying its classification.
+ * @param subjectResourceType - the resource being erased, whose row is retained.
+ * @returns the offending edges, in plan order. Empty is the healthy answer.
+ */
+export declare function findSubjectErasureSubjectTypeDeleteEdges<TEdge extends {
+    classification: SubjectErasureEdgeClassification;
+}>(plannedEdges: readonly TEdge[], subjectResourceType: string): TEdge[];
 //# sourceMappingURL=subject-erasure.shared.schemas.d.ts.map