@wildo-ai/saas-models 1.0.1 → 1.1.0

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

@@ -0,0 +1,457 @@
+import type { z } from 'zod';
+import { type ResourceRelationship } from '../../resources/resources.shared.schemas';
+import type { ResourceType } from '../../resources/resources.shared.core.definitions';
+/**
+ * WHICH data-subject right an export is answering.
+ *
+ * ## Why this is an enum and not a boolean flag on one bundle
+ *
+ * GDPR Art. 15 (right of access) and Art. 20 (right to data portability) are DIFFERENT rights over
+ * DIFFERENT data, and conflating them is the defect this capability was built to correct: the four
+ * routed export operations removed on 2026-08-01 declared themselves "portability / GDPR" while
+ * their actual options (`includeActivityData`, `includeOrganizationData`) described an *access*
+ * bundle. One output with a flag would reproduce that merge.
+ *
+ * - **Access** is a disclosure obligation: everything the controller holds *concerning* the subject,
+ *   including data the controller itself derived about them, in any readable form.
+ * - **Portability** is a transfer obligation: only the data the subject *provided* — actively, or by
+ *   using the service — and it must be machine-readable and re-importable elsewhere. Data the
+ *   controller inferred is deliberately OUT of scope; a competitor must not receive a rival's
+ *   analytics through a subject's portability request.
+ *
+ * The two therefore diverge at BOTH levels this module classifies: per-edge (see
+ * {@link classifySubjectExportDisposition}) and per-field (see
+ * {@link resolveSubjectExportFieldScope}).
+ *
+ * assurance-control: WILDO.PRIVACY.SUBJECT_DATA_EXPORT
+ */
+export declare enum SubjectExportPurpose {
+    /**
+     * Art. 15 — right of access. The broadest bundle: every row concerning the subject, whoever
+     * produced it, including rows the subject does not own (an audit log about them, a membership an
+     * administrator created).
+     */
+    ACCESS_ART_15 = "access_art_15",
+    /**
+     * Art. 20 — right to data portability. Narrower on purpose: only data the subject supplied or
+     * generated by using the service, and only from rows the subject owns. Controller-derived data is
+     * excluded by {@link DataPortabilityProvenance.DERIVED}.
+     */
+    PORTABILITY_ART_20 = "portability_art_20"
+}
+/**
+ * WHERE one field's value came from — the axis that decides Art. 20 scope.
+ *
+ * ## Why three values and not `isSubjectProvided: boolean`
+ *
+ * EDPB/WP29 guidance splits "provided by the data subject" into data supplied *knowingly* and data
+ * *observed* from the subject's use of the service, and puts BOTH in Art. 20 scope while excluding
+ * data the controller *inferred*. A boolean forces `OBSERVED` to be mis-filed against whichever
+ * side the author guesses — and it is the member most often got wrong, because "the user did not
+ * type it" reads as "the user did not provide it", which is precisely the wrong conclusion.
+ *
+ * ## Why this is per-FIELD and not per-resource
+ *
+ * A single row routinely mixes the two: a user profile holds `firstName` (supplied) beside a
+ * controller-computed status or score. A resource-level answer would have to round one way for the
+ * whole row. The resource-level declaration exists only as a DEFAULT
+ * (`portabilityPolicy.defaultProvenance`) so that annotating a resource stays a one-line cost; the
+ * per-field decorator overrides it where a field differs.
+ *
+ * ⚠️ NOT a redaction or scrub concept. This says where a value CAME FROM, for a disclosure
+ * decision. What happens to a value on ERASURE is `.impersonalizeWith()` / `RedactionType`, a
+ * different axis entirely — a field can be `SUBJECT_PROVIDED` and also masked on erasure.
+ */
+export declare enum DataPortabilityProvenance {
+    /**
+     * The subject actively and knowingly supplied this value — form input, an uploaded file, a
+     * setting they chose. Unambiguously in scope for both rights.
+     */
+    SUBJECT_PROVIDED = "subject_provided",
+    /**
+     * Generated by the subject's USE of the service rather than typed by them — activity timestamps,
+     * event history, usage counters, telemetry. **In scope for Art. 20**, which is the whole reason
+     * this member exists separately from {@link DERIVED}.
+     */
+    OBSERVED = "observed",
+    /**
+     * Produced BY the controller about the subject — inferred classifications, computed scores,
+     * risk or segmentation labels, server-assigned lifecycle state. Disclosed under Art. 15 (the
+     * subject may see what we concluded about them) but **excluded from Art. 20** (a portability
+     * request is not a channel for exporting the controller's own analysis).
+     */
+    DERIVED = "derived"
+}
+/**
+ * What an export does with ONE child-direction edge of the subject.
+ *
+ * ## Why this is NOT `SubjectErasureDisposition`
+ *
+ * Erasure and export share a traversal and answer opposite questions — *what do I destroy?* versus
+ * *what must I disclose?* — and they diverge on exactly the edges erasure calls `NOT_OWNED`.
+ *
+ * Erasure leaves audit logs, memberships and job executions alone, correctly: you do not delete an
+ * audit log because a user exercised a right. But those same rows hold personal data CONCERNING the
+ * subject, and Art. 15 covers "all personal data concerning him or her" — not "rows he owns".
+ * Reusing erasure's vocabulary verbatim would have silently omitted the data an access request most
+ * often targets. Hence {@link INCLUDED_REFERENCES_SUBJECT}, a case erasure has no use for.
+ *
+ * The two classifiers still read the SAME upstream authority for what an edge *says*
+ * (`requireResolvedRelationshipSemantics`), so they can never disagree about ownership — only about
+ * what to do with it.
+ *
+ * ## Why there is no blocking disposition here
+ *
+ * Erasure refuses up-front on `UNCLASSIFIED` / `UNSUPPORTED_DEFERRED` because it is about to
+ * WRITE, cannot half-destroy a subject, and needs a teardown declaration nobody made. An export
+ * writes nothing: ownership alone answers the edge question, a deferred teardown is irrelevant to a
+ * read, and a cross-adapter dependent is merely a second query rather than a broken transaction.
+ * The one genuine refusal in an export is field-level and Art. 20-only — see
+ * {@link SubjectExportFieldScope.UNDECLARED}. Manufacturing an edge-level blocker for symmetry
+ * would be false symmetry.
+ */
+export declare enum SubjectExportEdgeDisposition {
+    /**
+     * The subject OWNS this dependent (`lifecycleModelMode: DEPENDENT`), so its rows are the
+     * subject's own data. Included for both purposes — for Art. 20 the per-field provenance filter
+     * still applies to what comes back.
+     */
+    INCLUDED_OWNED = "included_owned",
+    /**
+     * The subject does NOT own these rows, but they REFERENCE the subject — the far side carries a
+     * foreign key back to them (an audit log, an organization membership, a job execution).
+     *
+     * **Art. 15 only.** These are personal data concerning the subject, so an access request must
+     * disclose them. A portability request must not: the subject did not provide a row that a third
+     * party or the controller created about them, and shipping them would export the controller's
+     * operational records under a transfer right. For `PORTABILITY_ART_20` this same edge classifies
+     * as {@link EXCLUDED_NOT_SUBJECT_PROVIDED}.
+     */
+    INCLUDED_REFERENCES_SUBJECT = "included_references_subject",
+    /**
+     * The edge carries no personal data of the subject at all: an independent or link-only
+     * relationship whose far side does not even reference them, or a disabled relationship that is
+     * not part of the live graph. Out of scope for both rights.
+     */
+    EXCLUDED_NOT_SUBJECT_DATA = "excluded_not_subject_data",
+    /**
+     * In scope for access, but excluded from THIS export because the export is a portability request
+     * and the rows were not provided by the subject. Kept as its own member rather than collapsing
+     * into {@link EXCLUDED_NOT_SUBJECT_DATA}: a reviewer asking "why is my audit trail missing from
+     * my portability export?" needs "because Art. 20 does not cover controller records" and "because
+     * that edge holds nothing about you" to be different answers, and only the first is a legal
+     * position someone took.
+     */
+    EXCLUDED_NOT_SUBJECT_PROVIDED = "excluded_not_subject_provided",
+    /**
+     * The rows ARE the subject's data and the right covers them, but the resource is declared
+     * `systemAccessPolicy.exportSubject = FORBIDDEN` — someone decided it must never reach a data
+     * subject (an authentication-credential store, a security audit trail).
+     *
+     * ## Why this excludes rather than refusing
+     *
+     * An UNDECLARED resource refuses the whole export, because nobody has decided yet and refusing is
+     * what forces the decision. A FORBIDDEN one is the opposite: the decision exists, and refusing
+     * would make it permanent sabotage — a `USERS` access export whose graph touches a credential
+     * store could then NEVER run, no matter how many other resources opted in. Honouring the
+     * declaration means leaving those rows out and saying so.
+     *
+     * ⚠️ This applies to EDGES only. A subject whose OWN resource is FORBIDDEN still refuses: there is
+     * no export of a person whose identity row may not be disclosed, and silently returning an
+     * edges-only bundle would be a disclosure that omits its own subject.
+     */
+    EXCLUDED_NOT_DISCLOSABLE = "excluded_not_disclosable"
+}
+/** Whether an edge disposition puts the far side's rows INTO the bundle. */
+export declare function isIncludedSubjectExportEdgeDisposition(disposition: SubjectExportEdgeDisposition): boolean;
+/** The classification of ONE child-direction edge of an export subject. */
+export interface SubjectExportEdgeClassification {
+    /** The related resource on the far side of the edge. */
+    relatedResourceType: ResourceType;
+    /** Whether, and why, this edge's rows join the bundle. */
+    disposition: SubjectExportEdgeDisposition;
+    /**
+     * Human-readable justification quoting the configuration that produced it. Surfaced in the export
+     * report so a data-protection reviewer never has to re-derive WHY a resource was included or
+     * left out — which, for a disclosure obligation, is the evidence that matters.
+     */
+    reason: string;
+}
+/**
+ * Classify what an export must do with ONE child-direction edge — the disclose-vs-omit decision,
+ * DERIVED FROM CONFIGURATION rather than a hardcoded list of resource types.
+ *
+ * ## Where the answer comes from
+ *
+ * Two declarations the author already makes, read through the same shared authorities the delete
+ * cascade and the erasure orchestrator read, so the three can never disagree about what an edge is:
+ *
+ *  1. **`handling.lifecycleModelMode`** — does the subject own this related resource's lifecycle?
+ *     `DEPENDENT` means the rows are the subject's own data.
+ *  2. **Foreign-key topology** (`resolveForeignKeyHolderResourceType`, cardinality-only and
+ *     therefore pure) — for a NON-owned edge, does the far side nonetheless carry a reference back
+ *     to the subject? If it does, its rows are *about* the subject and Art. 15 must disclose them.
+ *
+ * ## The `purpose` parameter, and why it is a parameter
+ *
+ * Art. 15 and Art. 20 diverge on exactly one edge case — the referencing-but-not-owned edge — and
+ * keeping that divergence in ONE switch here is what stops two near-identical classifiers from
+ * drifting apart. Exposing `classifyForAccess` / `classifyForPortability` would duplicate the
+ * ownership logic, and the day someone fixes a bug in one they would miss the other.
+ *
+ * ## Caller contract
+ *
+ * `relationship.resourceType2` MUST be the far side and `resourceType1` the subject — the same
+ * child-direction normalization {@link classifySubjectErasureDisposition} requires. The caller
+ * filters to child-direction edges before classifying.
+ *
+ * Pure and side-effect free — no registry lookups, no I/O, no row reads — so it is equally usable
+ * from a runtime orchestrator and from a boot-time coherence guard.
+ */
+export declare function classifySubjectExportDisposition(relationship: ResourceRelationship, purpose: SubjectExportPurpose): SubjectExportEdgeClassification;
+/**
+ * The three relationship buckets exposed by a compiled resource configuration.
+ *
+ * Kept structural here so the privacy compiler does not import resource configuration schemas:
+ * those schemas already import this module for {@link DataPortabilityProvenance}.
+ */
+export interface SubjectExportRelationshipBuckets {
+    readonly parentRelationships: readonly ResourceRelationship[];
+    readonly childRelationships: readonly ResourceRelationship[];
+    readonly selfRelationships: readonly ResourceRelationship[];
+}
+/** One graph edge normalized so the export subject is always `resourceType1`. */
+export interface SubjectExportRelationshipTraversal {
+    /** Original compiled relationship; runtime adapters use it to resolve the real FK field. */
+    readonly relationship: ResourceRelationship;
+    /** Direction-normalized relationship consumed by the shared legal-scope classifier. */
+    readonly normalizedRelationship: ResourceRelationship;
+    readonly classification: SubjectExportEdgeClassification;
+}
+/**
+ * Enumerate every edge touching one export subject, including child-first reference declarations.
+ *
+ * Resource configurations deliberately preserve parent/child/self buckets. Subject disclosure is
+ * different: personal data can point *to* the subject from either authored orientation. This helper
+ * joins both directional buckets, includes self edges once, and swaps only the positional topology
+ * needed by {@link classifySubjectExportDisposition}. It preserves the original compiled edge for
+ * FK resolution and never collapses multiple foreign keys between the same resource pair.
+ */
+export declare function enumerateSubjectExportRelationshipTraversals(subjectResourceType: ResourceType, relationships: SubjectExportRelationshipBuckets, purpose: SubjectExportPurpose): SubjectExportRelationshipTraversal[];
+/** Stable identity retaining distinct foreign keys between otherwise identical resource pairs. */
+export declare function subjectExportRelationshipTraversalKey(traversal: SubjectExportRelationshipTraversal): string;
+/**
+ * Whether ONE field's value joins the bundle, for a given purpose.
+ *
+ * Separate from {@link SubjectExportEdgeDisposition} because the two answer different questions at
+ * different granularities: an edge decides whether a RESOURCE's rows are in scope at all, a field
+ * scope decides which COLUMNS of an in-scope row survive the Art. 20 narrowing.
+ */
+export declare enum SubjectExportFieldScope {
+    /** The field's value belongs in this bundle. */
+    INCLUDED = "included",
+    /**
+     * Excluded because the value is controller-DERIVED and this is a portability request. Never
+     * reached for `ACCESS_ART_15`, which discloses derived data.
+     */
+    EXCLUDED_DERIVED = "excluded_derived",
+    /**
+     * ⛔ NO ANSWER — the field carries no provenance declaration and none is inherited from its
+     * resource, while the export is a portability request that needs one.
+     *
+     * The export REFUSES rather than guessing, because both guesses are harmful and neither is the
+     * conservative one: excluding an undeclared field UNDER-DELIVERS a legal right the subject is
+     * owed, and including it OVER-SHARES data the controller derived. There is no safe default to
+     * fall back on, which is exactly the condition that justifies failing loud — the same reasoning
+     * that makes `SubjectErasureDisposition.UNCLASSIFIED` refuse an erasure.
+     *
+     * `ACCESS_ART_15` never produces this: access includes every field regardless of provenance, so
+     * an application can serve access requests before annotating anything.
+     */
+    UNDECLARED = "undeclared"
+}
+/** Whether a field scope must ABORT the export rather than merely omitting a value. */
+export declare function isBlockingSubjectExportFieldScope(scope: SubjectExportFieldScope): boolean;
+/**
+ * Decide whether one field's value belongs in the bundle.
+ *
+ * `provenance` is the field's EFFECTIVE provenance — its own `.portabilityProvenance()` declaration
+ * if it carries one, otherwise the resource's `portabilityPolicy.defaultProvenance`, otherwise
+ * `undefined`. Resolving that fallback chain is the factory's job (Phase 0B); this function only
+ * judges the resolved value, which keeps it pure and independently testable.
+ */
+export declare function resolveSubjectExportFieldScope(provenance: DataPortabilityProvenance | undefined, purpose: SubjectExportPurpose): SubjectExportFieldScope;
+/**
+ * Is this field withheld from EVERY subject export, whatever right is being answered?
+ *
+ * ## Why this exists at all — the layering trap it closes
+ *
+ * The export orchestrator collects rows at the REPOSITORY layer, which sits BELOW the service-layer
+ * DTO projection that normally strips `.isBackendOnly()` fields on their way to a client. Without an
+ * explicit check here, a subject export would disclose exactly the values that projection exists to
+ * hide — `passwordHash` and `backupCodesHashed` on `USER_CREDENTIALS` are the motivating case, and
+ * the config change that exposed them would have looked entirely routine.
+ *
+ * ## Why it is deliberately CONSERVATIVE
+ *
+ * This withholds every backend-only field, not only the secrets. Some backend-only fields are
+ * genuinely disclosable under Art. 15 (`passwordChangedAt`, `firstMfaPromptAt` — facts about the
+ * subject they may ask for), so this errs toward withholding.
+ *
+ * That asymmetry is intentional. Under-disclosing produces a complaint that is answerable and
+ * fixable; disclosing an authentication secret is neither, and it degrades the security of
+ * processing the framework is separately obliged to maintain (GDPR Art. 32). Between an
+ * over-cautious bundle and a leaked credential, only one is recoverable.
+ *
+ * The withheld fields are REPORTED (`SubjectExportReport.fieldsWithheldAsNonDisclosable`) so the
+ * caution is visible rather than silent. When a resource needs a specific backend-only field
+ * disclosed, the expressible extension is a per-field opt-in on this predicate — NOT loosening it
+ * wholesale.
+ *
+ * assurance-control: WILDO.PRIVACY.SUBJECT_DATA_EXPORT
+ */
+export declare function isFieldWithheldFromSubjectExport(fieldSchema: z.ZodTypeAny): boolean;
+/**
+ * Resolve ONE field's EFFECTIVE provenance by joining the two declaration levels.
+ *
+ * ## The fallback chain, and why it has exactly two rungs
+ *
+ * 1. the field's own `.portabilityProvenance()` declaration, if it carries one;
+ * 2. otherwise the resource's `portabilityPolicy.defaultProvenance`;
+ * 3. otherwise `undefined` — which {@link resolveSubjectExportFieldScope} turns into a REFUSAL for
+ *    an Art. 20 export and ignores entirely for Art. 15.
+ *
+ * Two rungs is what makes the fail-loud rule adoptable: without the resource default, every field of
+ * every resource would need a decorator before a single portability request could be answered, and a
+ * capability that expensive to adopt does not get adopted. With it, annotating a resource is one
+ * line and only the exceptions carry a decorator.
+ *
+ * ## Why the enum check lives HERE
+ *
+ * `zod-decorators` sits below this package and cannot import {@link DataPortabilityProvenance}, so
+ * it stores whatever non-empty string it was given — it can reject a BLANK but not a WRONG value.
+ * This is the first layer that knows the vocabulary, so it is where a typo'd `'subject-provided'`
+ * (hyphen, not underscore) must fail rather than silently resolving to `undefined` and turning a
+ * declared field into a refusal — or worse, into a silent omission if the caller treats unknown as
+ * derived. Mirrors how `RedactionType` validity is checked in this layer for `.impersonalizeWith()`.
+ *
+ * @param fieldSchema the field's Zod schema; the reader walks wrapper types, so a declaration made
+ *   before or after `.optional()` / `.nullish()` / `.default()` is observed either way.
+ * @param resourceDefaultProvenance the owning resource's `portabilityPolicy.defaultProvenance`.
+ *   Taken as a bare value rather than the policy object so this module stays free of the
+ *   resource-config import (which imports THIS module for the enum).
+ * @param fieldLocator `resourceType.fieldName`, used only to make a rejection actionable.
+ */
+export declare function resolveEffectiveFieldPortabilityProvenance(fieldSchema: z.ZodTypeAny, resourceDefaultProvenance: DataPortabilityProvenance | undefined, fieldLocator: string): DataPortabilityProvenance | undefined;
+/** Why a compiled leaf-field decision has its effective export meaning. */
+export declare enum SubjectExportFieldDecisionBasis {
+    FIELD_DECLARATION = "field_declaration",
+    RESOURCE_DEFAULT = "resource_default",
+    WITHHELD_NON_DISCLOSABLE = "withheld_non_disclosable",
+    UNDECLARED = "undeclared",
+    DEPTH_LIMIT = "depth_limit"
+}
+/** Canonical, runtime-effective decision for one leaf path in one export purpose. */
+export interface SubjectExportFieldDecision {
+    readonly locator: string;
+    readonly purpose: SubjectExportPurpose;
+    readonly scope: SubjectExportFieldScope | null;
+    readonly provenance: DataPortabilityProvenance | null;
+    readonly basis: SubjectExportFieldDecisionBasis;
+}
+/**
+ * Resolve an object shape through the same bounded wrapper protocol used by subject export.
+ * Returning `undefined` means the value is a leaf. Reaching the bound is handled fail-closed by
+ * {@link compileSubjectExportFieldDecisions}, never as an implicit leaf inclusion.
+ */
+export declare function resolveSubjectExportObjectShapeThroughWrappers(schema: unknown): Record<string, unknown> | undefined;
+/**
+ * Compile every runtime-effective leaf-field decision for one resource and right.
+ *
+ * Both the backend executor and application authority proof consume this function. A field-level
+ * decorator, inherited default, withheld marker, wrapper layout or depth refusal therefore changes
+ * one shared decision inventory instead of two independently maintained interpretations.
+ */
+export declare function compileSubjectExportFieldDecisions(input: {
+    readonly resourceType: ResourceType;
+    readonly mainSchema: unknown;
+    readonly defaultProvenance: DataPortabilityProvenance | undefined;
+    readonly purpose: SubjectExportPurpose;
+}): SubjectExportFieldDecision[];
+/** Per-edge outcome of an executed export — the classification plus what actually happened. */
+export interface SubjectExportEdgeOutcome extends SubjectExportEdgeClassification {
+    /**
+     * `true` when the export actually queried this edge. Note this reports that the read RAN, not
+     * that rows existed — an included edge with no rows for this subject is a legitimate empty
+     * result, and {@link recordCount} distinguishes the two.
+     */
+    collected: boolean;
+    /** How many rows this edge contributed. `0` on an included edge means the subject had none. */
+    recordCount: number;
+}
+/**
+ * What one subject export produced — the compliance artifact of an Art. 15 or Art. 20 request.
+ *
+ * Returned to the caller (rather than only logged) so the flow fronting 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. For a disclosure obligation, the record of what was DELIBERATELY
+ * LEFT OUT — and on what legal basis — matters as much as the data returned.
+ */
+export interface SubjectExportReport {
+    /** Which right this export answered. */
+    purpose: SubjectExportPurpose;
+    /** The exported subject's resource type. */
+    subjectResourceType: ResourceType;
+    /** The exported subject rows. */
+    subjectIds: string[];
+    /** Every child-direction edge of the subject, classified, in registry order. */
+    edges: SubjectExportEdgeOutcome[];
+    /**
+     * Fields omitted from the bundle as controller-DERIVED, as `resourceType.fieldName`. Populated
+     * only for `PORTABILITY_ART_20`. Recorded rather than silently dropped so the subject can see
+     * that derived data exists and request it under Art. 15 instead.
+     */
+    fieldsExcludedAsDerived: string[];
+    /**
+     * Fields withheld as NON-DISCLOSABLE regardless of purpose — see
+     * {@link isFieldWithheldFromSubjectExport}. Populated for BOTH rights, because a password hash is
+     * no more disclosable under Art. 15 than under Art. 20.
+     *
+     * Recorded rather than silently dropped for the same reason as the derived list, and one more: a
+     * reviewer auditing why an export looks thin needs to see that the framework withheld something
+     * deliberately, not that a resource was missed.
+     */
+    fieldsWithheldAsNonDisclosable: string[];
+    /** Total rows across every collected edge, including the subject's own row(s). */
+    totalRecordCount: number;
+}
+/** One resource's contribution to an export bundle. */
+export interface SubjectExportResourceSlice {
+    resourceType: ResourceType;
+    /**
+     * The rows, already narrowed to the fields in scope for the export's purpose. For
+     * `PORTABILITY_ART_20` the controller-derived columns are gone; for `ACCESS_ART_15` every column
+     * the subject is entitled to see is present.
+     */
+    rows: Record<string, unknown>[];
+}
+/**
+ * What an export ACTUALLY produced — the data, paired with the report that justifies its shape.
+ *
+ * ## Why the data and the report are one return value but two types
+ *
+ * {@link SubjectExportReport} is the compliance artifact: it survives the request, is safe to log
+ * and persist, and contains NO personal data — only per-edge dispositions and counts. The slices
+ * are the personal data itself, which must NOT be logged and whose lifetime ends when the artifact
+ * is written.
+ *
+ * Returning them together keeps the caller from having to correlate two results, while the type
+ * split keeps "safe to record" and "must be handled carefully" visibly distinct — a caller writing
+ * `logger.info({ report })` is correct, and the same line with `bundle` would be a leak. Fusing
+ * them into one flat object would erase exactly that distinction.
+ */
+export interface SubjectExportBundle {
+    report: SubjectExportReport;
+    slices: SubjectExportResourceSlice[];
+}
+//# sourceMappingURL=subject-export.shared.schemas.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"subject-export.shared.schemas.d.ts","sourceRoot":"","sources":["../../../../../src/compliance/privacy/subject-export.shared.schemas.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AAE7B,OAAO,EAEL,KAAK,oBAAoB,EAC1B,MAAM,0CAA0C,CAAC;AAElD,OAAO,KAAK,EAAE,YAAY,EAAE,MAAM,mDAAmD,CAAC;AAItF;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AACH,oBAAY,oBAAoB;IAC9B;;;;OAIG;IACH,aAAa,kBAAkB;IAE/B;;;;OAIG;IACH,kBAAkB,uBAAuB;CAC1C;AAED;;;;;;;;;;;;;;;;;;;;;;GAsBG;AACH,oBAAY,yBAAyB;IACnC;;;OAGG;IACH,gBAAgB,qBAAqB;IAErC;;;;OAIG;IACH,QAAQ,aAAa;IAErB;;;;;OAKG;IACH,OAAO,YAAY;CACpB;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;GA2BG;AACH,oBAAY,4BAA4B;IACtC;;;;OAIG;IACH,cAAc,mBAAmB;IAEjC;;;;;;;;;OASG;IACH,2BAA2B,gCAAgC;IAE3D;;;;OAIG;IACH,yBAAyB,8BAA8B;IAEvD;;;;;;;OAOG;IACH,6BAA6B,kCAAkC;IAE/D;;;;;;;;;;;;;;;;OAgBG;IACH,wBAAwB,6BAA6B;CACtD;AAED,4EAA4E;AAC5E,wBAAgB,sCAAsC,CACpD,WAAW,EAAE,4BAA4B,GACxC,OAAO,CAGT;AAED,2EAA2E;AAC3E,MAAM,WAAW,+BAA+B;IAC9C,wDAAwD;IACxD,mBAAmB,EAAE,YAAY,CAAC;IAClC,0DAA0D;IAC1D,WAAW,EAAE,4BAA4B,CAAC;IAC1C;;;;OAIG;IACH,MAAM,EAAE,MAAM,CAAC;CAChB;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA8BG;AACH,wBAAgB,gCAAgC,CAC9C,YAAY,EAAE,oBAAoB,EAClC,OAAO,EAAE,oBAAoB,GAC5B,+BAA+B,CAmEjC;AAED;;;;;GAKG;AACH,MAAM,WAAW,gCAAgC;IAC/C,QAAQ,CAAC,mBAAmB,EAAE,SAAS,oBAAoB,EAAE,CAAC;IAC9D,QAAQ,CAAC,kBAAkB,EAAE,SAAS,oBAAoB,EAAE,CAAC;IAC7D,QAAQ,CAAC,iBAAiB,EAAE,SAAS,oBAAoB,EAAE,CAAC;CAC7D;AAED,iFAAiF;AACjF,MAAM,WAAW,kCAAkC;IACjD,4FAA4F;IAC5F,QAAQ,CAAC,YAAY,EAAE,oBAAoB,CAAC;IAC5C,uFAAuF;IACvF,QAAQ,CAAC,sBAAsB,EAAE,oBAAoB,CAAC;IACtD,QAAQ,CAAC,cAAc,EAAE,+BAA+B,CAAC;CAC1D;AAED;;;;;;;;GAQG;AACH,wBAAgB,4CAA4C,CAC1D,mBAAmB,EAAE,YAAY,EACjC,aAAa,EAAE,gCAAgC,EAC/C,OAAO,EAAE,oBAAoB,GAC5B,kCAAkC,EAAE,CA8BtC;AAED,kGAAkG;AAClG,wBAAgB,qCAAqC,CAAC,SAAS,EAAE,kCAAkC,GAAG,MAAM,CAW3G;AAED;;;;;;GAMG;AACH,oBAAY,uBAAuB;IACjC,gDAAgD;IAChD,QAAQ,aAAa;IAErB;;;OAGG;IACH,gBAAgB,qBAAqB;IAErC;;;;;;;;;;;;OAYG;IACH,UAAU,eAAe;CAC1B;AAED,uFAAuF;AACvF,wBAAgB,iCAAiC,CAAC,KAAK,EAAE,uBAAuB,GAAG,OAAO,CAEzF;AAED;;;;;;;GAOG;AACH,wBAAgB,8BAA8B,CAC5C,UAAU,EAAE,yBAAyB,GAAG,SAAS,EACjD,OAAO,EAAE,oBAAoB,GAC5B,uBAAuB,CAqBzB;AAoCD;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA4BG;AACH,wBAAgB,gCAAgC,CAAC,WAAW,EAAE,CAAC,CAAC,UAAU,GAAG,OAAO,CAKnF;AAOD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA8BG;AACH,wBAAgB,0CAA0C,CACxD,WAAW,EAAE,CAAC,CAAC,UAAU,EACzB,yBAAyB,EAAE,yBAAyB,GAAG,SAAS,EAChE,YAAY,EAAE,MAAM,GACnB,yBAAyB,GAAG,SAAS,CAiBvC;AAED,2EAA2E;AAC3E,oBAAY,+BAA+B;IACzC,iBAAiB,sBAAsB;IACvC,gBAAgB,qBAAqB;IACrC,wBAAwB,6BAA6B;IACrD,UAAU,eAAe;IACzB,WAAW,gBAAgB;CAC5B;AAED,qFAAqF;AACrF,MAAM,WAAW,0BAA0B;IACzC,QAAQ,CAAC,OAAO,EAAE,MAAM,CAAC;IACzB,QAAQ,CAAC,OAAO,EAAE,oBAAoB,CAAC;IACvC,QAAQ,CAAC,KAAK,EAAE,uBAAuB,GAAG,IAAI,CAAC;IAC/C,QAAQ,CAAC,UAAU,EAAE,yBAAyB,GAAG,IAAI,CAAC;IACtD,QAAQ,CAAC,KAAK,EAAE,+BAA+B,CAAC;CACjD;AAID;;;;GAIG;AACH,wBAAgB,8CAA8C,CAAC,MAAM,EAAE,OAAO,GAAG,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,GAAG,SAAS,CASnH;AAED;;;;;;GAMG;AACH,wBAAgB,kCAAkC,CAAC,KAAK,EAAE;IACxD,QAAQ,CAAC,YAAY,EAAE,YAAY,CAAC;IACpC,QAAQ,CAAC,UAAU,EAAE,OAAO,CAAC;IAC7B,QAAQ,CAAC,iBAAiB,EAAE,yBAAyB,GAAG,SAAS,CAAC;IAClE,QAAQ,CAAC,OAAO,EAAE,oBAAoB,CAAC;CACxC,GAAG,0BAA0B,EAAE,CAmD/B;AAED,+FAA+F;AAC/F,MAAM,WAAW,wBAAyB,SAAQ,+BAA+B;IAC/E;;;;OAIG;IACH,SAAS,EAAE,OAAO,CAAC;IACnB,+FAA+F;IAC/F,WAAW,EAAE,MAAM,CAAC;CACrB;AAED;;;;;;;GAOG;AACH,MAAM,WAAW,mBAAmB;IAClC,wCAAwC;IACxC,OAAO,EAAE,oBAAoB,CAAC;IAC9B,4CAA4C;IAC5C,mBAAmB,EAAE,YAAY,CAAC;IAClC,iCAAiC;IACjC,UAAU,EAAE,MAAM,EAAE,CAAC;IACrB,gFAAgF;IAChF,KAAK,EAAE,wBAAwB,EAAE,CAAC;IAClC;;;;OAIG;IACH,uBAAuB,EAAE,MAAM,EAAE,CAAC;IAClC;;;;;;;;OAQG;IACH,8BAA8B,EAAE,MAAM,EAAE,CAAC;IACzC,kFAAkF;IAClF,gBAAgB,EAAE,MAAM,CAAC;CAC1B;AAED,uDAAuD;AACvD,MAAM,WAAW,0BAA0B;IACzC,YAAY,EAAE,YAAY,CAAC;IAC3B;;;;OAIG;IACH,IAAI,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,EAAE,CAAC;CACjC;AAED;;;;;;;;;;;;;;GAcG;AACH,MAAM,WAAW,mBAAmB;IAClC,MAAM,EAAE,mBAAmB,CAAC;IAC5B,MAAM,EAAE,0BAA0B,EAAE,CAAC;CACtC"}