@wildo-ai/saas-models 1.1.3 → 1.1.5

package/dist/esm/resources/resources-registry.shared.core.definitions.js

@@ -1,6 +1,6 @@
 import { RelationshipNature, ResourceRelationshipAccessScopeStrategy, ResourceRelationshipCardinality, ResourceParentResourceRequirement } from "./resources.shared.schemas.js";
 import { ContextPolicy_ObjectMode } from "./context-policy.shared.schemas.js";
-import { ChildLifecycleMode } from "./child-operations.shared.schemas.js";
+import { ChildLifecycleMode, ChildLifecycleStrategy } from "./child-operations.shared.schemas.js";
 import { CoreResourceOperation } from "./resources.shared.core.definitions.js";
 import { CoreResourceType } from "./resources.shared.core.definitions.js";
 // Resource configuration factory imports
@@ -20,6 +20,8 @@ import { organizationUnitResourceConfiguration_InitializationFactory } from "../
 import { organizationUnitMemberResourceConfiguration_InitializationFactory } from "../organizations/organization-unit-members.shared.resources-config.schemas.js";
 import { organizationProfileResourceConfiguration_InitializationFactory } from "../organizations/organization-profile.shared.resources-config.schemas.js";
 import { organizationPreferencesResourceConfiguration_InitializationFactory } from "../organizations/organization-preferences.shared.resources-config.schemas.js";
+import { applicationAccessGrantsResourceConfiguration_InitializationFactory } from '../security/authorizations/application-access-grants.shared.resources-config.schemas.js';
+import { systemOfRecordPartitionAssignmentsResourceConfiguration_InitializationFactory } from '../systems-of-record/system-of-record-partition-assignments.shared.resources-config.schemas.js';
 import { platformAccessGrantsResourceConfiguration_InitializationFactory } from '../security/authorizations/platform-access-grants.shared.resources-config.schemas.js';
 import { organizationNotificationsResourceConfiguration_InitializationFactory } from "../organizations/organization-notifications.shared.resources-config.schemas.js";
 import { organizationFeaturesResourceConfiguration_InitializationFactory } from "../organizations/organization-features.shared.resources-config.schemas.js";
@@ -54,6 +56,7 @@ import { applicationVersionsResourceConfiguration_InitializationFactory } from "
 import { applicationMetadataResourceConfiguration_InitializationFactory } from "../applications/application-metadata.shared.resources-config.schemas.js";
 // Queue system resources
 import { jobExecution_ResourceConfiguration_InitializationFactory, jobPayloadStorage_ResourceConfiguration_InitializationFactory } from "../queue/jobs.shared.resources-config.schemas.js";
+import { providerCallRecordsResourceConfiguration_InitializationFactory } from "../flows-actors/provider-call-records.shared.resources-config.schemas.js";
 // Flows-Actors execution resource (persisted flow/actor system executions)
 import { flowActorExecutionsPolymorphicFactories } from "../flows-actors/flows-actors-execution.shared.resources-config.schemas.js";
 import { flowActorExecutionsPolymorphicDeclaration } from "../flows-actors/flows-actors-execution.shared.schemas.js";
@@ -65,6 +68,7 @@ import { a2aTokenBudgetStatePolymorphicDeclaration } from "../flows-actors/a2a-t
 import { a2aPushDeliveryLogPolymorphicDeclaration } from "../flows-actors/a2a-push-delivery-log.shared.schemas.js";
 // Authentication resources
 import { userIdentityLinksResourceConfiguration_InitializationFactory } from "../users/user-identity-links.shared.resources-config.schemas.js";
+import { userGovernedDocumentAcceptancesResourceConfiguration_InitializationFactory } from "../compliance/documents/user-governed-document-acceptances.shared.resources-config.schemas.js";
 // Anonymous session resources (W7.3a)
 import { anonymousUsersResourceConfiguration_InitializationFactory } from "../users/anonymous-users.shared.resources-config.schemas.js";
 // Inbound contacts (Phase 0.5 — public marketing-site lead capture, Q-E=B path)
@@ -80,6 +84,8 @@ import { siemExportConfigPolymorphicFactories } from "../security/authentication
 import { siemExportConfigPolymorphicDeclaration } from "../security/authentications/siem/siem-export-config.shared.schemas.js";
 import { siemDeliveryDlqPolymorphicFactories } from "../security/authentications/siem/siem-delivery-dlq.shared.resources-config.schemas.js";
 import { siemDeliveryDlqPolymorphicDeclaration } from "../security/authentications/siem/siem-delivery-dlq.shared.schemas.js";
+import { siemDeliveryOutboxPolymorphicFactories } from "../security/authentications/siem/siem-delivery-outbox.shared.resources-config.schemas.js";
+import { siemDeliveryOutboxPolymorphicDeclaration } from "../security/authentications/siem/siem-delivery-outbox.shared.schemas.js";
 import { webhookConfigPolymorphicFactories } from "../notifications/m2m/webhook-config.shared.resources-config.schemas.js";
 import { webhookConfigPolymorphicDeclaration } from "../notifications/m2m/webhook-config.shared.schemas.js";
 import { m2mWebhookDeliveryLogPolymorphicFactories } from "../notifications/m2m/m2m-webhook-delivery-log.shared.resources-config.schemas.js";
@@ -92,6 +98,7 @@ import { scimProvisioningConfigPolymorphicDeclaration } from "../security/authen
 import { userProgressionStateResourceConfiguration_InitializationFactory, organizationProgressionStateResourceConfiguration_InitializationFactory } from "../guidance/progression-state.shared.resources-config.schemas.js";
 // Lifecycle State resources
 import { userLifecycleStateResourceConfiguration_InitializationFactory, organizationLifecycleStateResourceConfiguration_InitializationFactory } from "../guidance/lifecycle-state.shared.resources-config.schemas.js";
+import { GuidanceStateUtils } from "../guidance/guidance-state.shared.utils.js";
 export const coreSharedResourceRelationship = [
     // Core organizational relationships - Many-to-many through organization members
     // Note: No isPrimaryScope here - applications are the primary scope for users, not organizations
@@ -213,6 +220,37 @@ export const coreSharedResourceRelationship = [
         // SECURITY: Identity links contain raw IdP profiles — never fetch via context
         contextPolicy: { enabled: false }
     }),
+    // An ORGANIZATION-scoped enterprise identity link dies with its organization.
+    //
+    // Before this edge, the link's only parent was its user, and `organizationId` was a bare foreign
+    // key. The organization purge deletes by the `onParentDelete` cascade and by nothing else, so every
+    // member's enterprise link outlived the tenant. The one cleanup that did exist, the AUTH-13 postfix
+    // on SSO connection DELETE, never runs there: the cascade deletes a connection through its
+    // repository, which bypasses service-tier hooks. The dead link then read as a live membership to
+    // the cross-organization SSO guard, which refused that person's enterprise sign-in into EVERY other
+    // organization for good. Measured 2026-09-21: 19 such links on one account, and the `saml` e2e lane
+    // refused from its second run on (#1448).
+    //
+    // Non-primary and STANDALONE, the ORGANIZATION_MEMBERS teardown-anchor pattern: USERS stays the
+    // primary scope (the owner-only access filter and the subject-erasure classification are unchanged),
+    // no URL surface is added, and the link is never context-fetched. An APPLICATION-scoped link carries
+    // no `organizationId`, so this edge never selects it.
+    //
+    // Fires at PURGE, like every other organization child, never at the soft-delete mark: a restored
+    // tenant keeps its members' links.
+    //
+    // OPTIONAL parent: a social link, and an application-scoped enterprise link, carry no
+    // `organizationId`, and the schema declares it optional. The persistence converter refuses a
+    // relationship whose requirement disagrees with the schema path.
+    createResourcesRelationship(CoreResourceType.ORGANIZATIONS, CoreResourceType.USER_IDENTITY_LINKS, ResourceRelationshipCardinality.ONE, ResourceRelationshipCardinality.MANY, {
+        accessScopeStrategy: ResourceRelationshipAccessScopeStrategy.STANDALONE,
+        isPrimaryScope: false,
+        parentResourceRequirement: ResourceParentResourceRequirement.OPTIONAL,
+        nature: RelationshipNature.COMPOSITION,
+        childOperations: { lifecycle: { onParentDelete: { enabled: true, mode: ChildLifecycleMode.IMMEDIATE, maxDepth: 1 } } },
+        foreignKeyField: 'organizationId',
+        contextPolicy: { enabled: false }
+    }),
     // OIDC persistent consent grants — USER_SELF-scoped ("remember this app"). COMPOSITION so a user's
     // grants cascade-delete with the user; `isPrimaryScope: true` anchors resourcePrimaryScope to
     // USER_SELF (the owner-only READ/LIST/DELETE filter). Consent state is never context-fetched.
@@ -224,6 +262,31 @@ export const coreSharedResourceRelationship = [
         foreignKeyField: 'userId',
         contextPolicy: { enabled: false }
     }),
+    // Link Users to UserGovernedDocumentAcceptances (1:N — one row per accepted release, #1258).
+    //
+    // KEPT when the user goes, deliberately: `onParentDelete` is DISABLED, the same answer the billing
+    // family gives below and for the same reason — the row is EVIDENCE of an act, and the erasure right
+    // does not reach what is needed to establish or defend a legal claim (GDPR Art. 17(3)(e)). A
+    // contract acceptance is exactly that: the operator's answer to "did this person agree to these
+    // terms, which version, and when?".
+    // spec-cite: Regulation (EU) 2016/679, Art. 17(3)(e) (https://gdpr-info.eu/art-17-gdpr/).
+    //
+    // Why NOT `retentionPolicy` + `IMPERSONALIZE_AND_RETAIN`: the row holds no personal data of its own
+    // (every value describes the account's contractual standing, with the person as a foreign key), so
+    // there is nothing to scrub, and the retaining EDGE strategy is declared nowhere in this file — the
+    // billing note records that its one declared scrub is wired to nothing. Evidence should not rest on
+    // an unexercised path. The erased person's own identity is impersonalized on the USERS row; this row
+    // then points at a pseudonymous account, which is what makes keeping it proportionate.
+    //
+    // STANDALONE + `contextPolicy: { enabled: false }`: no URL surface and never fetched through context.
+    createResourcesRelationship(CoreResourceType.USERS, CoreResourceType.USER_GOVERNED_DOCUMENT_ACCEPTANCES, ResourceRelationshipCardinality.ONE, ResourceRelationshipCardinality.MANY, {
+        accessScopeStrategy: ResourceRelationshipAccessScopeStrategy.STANDALONE,
+        isPrimaryScope: true,
+        nature: RelationshipNature.COMPOSITION,
+        childOperations: { lifecycle: { onParentDelete: { enabled: false } } },
+        foreignKeyField: 'userId',
+        contextPolicy: { enabled: false }
+    }),
     // User Self 1:1 relationships - separated for access control
     createResourcesRelationship(CoreResourceType.USER_SELF, CoreResourceType.USER_SELF_PROFILES, ResourceRelationshipCardinality.ONE, ResourceRelationshipCardinality.ONE, {
         isPrimaryScope: true,
@@ -358,10 +421,15 @@ export const coreSharedResourceRelationship = [
     // `allowCycle: true` is only the schema-level escape hatch for declaring a
     // self-edge. The business model is still an acyclic hierarchy; re-parenting
     // is handled explicitly via the MOVE operation on organization units.
+    // REFUSE_WHILE_CHILDREN_EXIST: deleting an interior node would strand its subtree behind a dangling
+    // `parentUnitId` and a stale materialized `path`, and hard-deleting the subtree behind a single-node
+    // DELETE is a worse default than asking. The operator re-parents each child with MOVE, or deletes
+    // the subtree bottom-up. A tenant purge still removes every unit through the ORGANIZATIONS edge.
     createResourcesRelationship(CoreResourceType.ORGANIZATION_UNITS, CoreResourceType.ORGANIZATION_UNITS, ResourceRelationshipCardinality.ONE, ResourceRelationshipCardinality.MANY, {
         nature: RelationshipNature.COMPOSITION,
         foreignKeyField: 'parentUnitId',
         allowCycle: true,
+        childOperations: { lifecycle: { onParentDelete: { enabled: true, strategy: ChildLifecycleStrategy.REFUSE_WHILE_CHILDREN_EXIST } } },
         parentResourceRequirement: ResourceParentResourceRequirement.OPTIONAL,
         accessScopeStrategy: ResourceRelationshipAccessScopeStrategy.OPTIONAL_CONTEXT,
         contextPolicy: { enabled: false },
@@ -377,10 +445,10 @@ export const coreSharedResourceRelationship = [
     //     membership, so losing the membership is exactly when the assignment stops meaning
     //     anything — hence the cascade. This is the edge that stops assignments outliving the
     //     membership that justified them.
-    //  3. ORGANIZATION_UNITS → …  is what the unit DELETE dependents guard was missing. While unit
-    //     assignment lived in an embedded array it was not a registered relationship and not
-    //     portably queryable, so "assigned members" had to be EXCLUDED from that guard (it would
-    //     have failed open on PostgreSQL). As a real edge it becomes a guardable dependent.
+    //  3. ORGANIZATION_UNITS → …  makes an assignment a dependent the unit DELETE refuses on
+    //     (REFUSE_WHILE_CHILDREN_EXIST). While unit assignment lived in an embedded array it was not
+    //     a registered relationship and not portably queryable, so a dependents check would have
+    //     failed open on PostgreSQL. As a real edge it is refused on like any other.
     createResourcesRelationship(CoreResourceType.ORGANIZATIONS, CoreResourceType.ORGANIZATION_UNIT_MEMBERS, ResourceRelationshipCardinality.ONE, ResourceRelationshipCardinality.MANY, {
         isPrimaryScope: true,
         nature: RelationshipNature.COMPOSITION,
@@ -417,10 +485,10 @@ export const coreSharedResourceRelationship = [
         childOperations: { lifecycle: { onParentDelete: { enabled: true, mode: ChildLifecycleMode.IMMEDIATE, maxDepth: 1 } } },
         contextPolicy: { enabled: false },
     }),
-    // No cascade on this edge ON PURPOSE — it mirrors the unit tree's own delete policy. A unit
-    // DELETE is refused while dependents remain (the operator decides where an orphaned assignment
-    // belongs) rather than silently dropping people's roles behind a single-node delete. Tearing
-    // down the whole ORGANIZATION still removes these rows via edge 1 above.
+    // REFUSE_WHILE_CHILDREN_EXIST, mirroring the unit tree's own delete policy: a unit DELETE is
+    // refused while assignments remain (the operator decides where an orphaned assignment belongs)
+    // rather than silently dropping people's roles behind a single-node delete. Tearing down the
+    // whole ORGANIZATION still removes these rows via edge 1 above.
     // OPTIONAL_CONTEXT for the same reason as the ORGANIZATION_MEMBERS edge above — this is the
     // mirrored half. Together the two now yield the unit-scoped route as well, so "who is in this
     // unit?" is answerable, and both partial routes exist beside the fully-nested one rather than
@@ -429,6 +497,7 @@ export const coreSharedResourceRelationship = [
         nature: RelationshipNature.COMPOSITION,
         foreignKeyField: 'organizationUnitId',
         accessScopeStrategy: ResourceRelationshipAccessScopeStrategy.OPTIONAL_CONTEXT,
+        childOperations: { lifecycle: { onParentDelete: { enabled: true, strategy: ChildLifecycleStrategy.REFUSE_WHILE_CHILDREN_EXIST } } },
         contextPolicy: { enabled: false },
     }),
     createResourcesRelationship(CoreResourceType.ORGANIZATIONS, CoreResourceType.ORGANIZATION_PROFILES, ResourceRelationshipCardinality.ONE, ResourceRelationshipCardinality.ONE, {
@@ -457,6 +526,58 @@ export const coreSharedResourceRelationship = [
         childOperations: { lifecycle: { onParentDelete: { enabled: true, mode: ChildLifecycleMode.IMMEDIATE, maxDepth: 1 } } },
         foreignKeyField: 'organizationId',
     }),
+    // ── APPLICATION-WIDE grants ──────────────────────────────────────────
+    //
+    // The APPLICATION-scoped sibling. Same lifecycle, no tenant: an elevation that reaches every
+    // tenant at once cannot be a COMPOSITION child of any one of them, which is the structural fact
+    // that made a second resource type necessary rather than a `scope` field on the row above.
+    //
+    // OPTIONAL + REQUIRES_CONTEXT + `isPrimaryScope`, copied from `APPLICATION → APPLICATION_AUDIT_LOGS`
+    // and for the reason stated there: MANDATORY makes the ZodToMongoose convertor refuse the resource
+    // outright, so a Mongo-persisted deployment gets no model and INIT dies. Addressing is carried by
+    // `isPrimaryScope` + `REQUIRES_CONTEXT`, which is what the URL builder reads.
+    //
+    // REFERENCE rather than COMPOSITION, and there is no `onParentDelete`: the APPLICATION row is the
+    // deployment itself and is not purged, so a cascade here would describe an event that cannot
+    // happen. `contextPolicy` disabled for the reason the audit door disables it — an elevation record
+    // must never be fetched as ambient context.
+    createResourcesRelationship(CoreResourceType.APPLICATION, CoreResourceType.APPLICATION_ACCESS_GRANTS, ResourceRelationshipCardinality.ONE, ResourceRelationshipCardinality.MANY, {
+        isPrimaryScope: true,
+        foreignKeyField: 'applicationId',
+        parentResourceRequirement: ResourceParentResourceRequirement.OPTIONAL,
+        accessScopeStrategy: ResourceRelationshipAccessScopeStrategy.REQUIRES_CONTEXT,
+        nature: RelationshipNature.REFERENCE,
+        contextPolicy: { enabled: false },
+    }),
+    // The two PEOPLE an application-wide grant names — the operator who asked and the SECOND
+    // administrator who signed. Both are `.isForeignKey()`, so the registry must resolve each to a
+    // resource type or the frontend registry refuses to initialise.
+    //
+    // REFERENCE with `onParentDelete.enabled: false`, exactly as on the tenant grant and for the same
+    // reason: making a user the owner resolves `lifecycleModelMode` to DEPENDENT, which is the value
+    // `classifySubjectErasureDisposition` reads — a user erasure would then own the row's fate, and the
+    // one thing a privileged-access ledger must survive is the erasure of the person it monitors.
+    createResourcesRelationship(CoreResourceType.USERS, CoreResourceType.APPLICATION_ACCESS_GRANTS, ResourceRelationshipCardinality.ONE, ResourceRelationshipCardinality.MANY, {
+        accessScopeStrategy: ResourceRelationshipAccessScopeStrategy.STANDALONE,
+        nature: RelationshipNature.REFERENCE,
+        foreignKeyField: 'operatorUserId',
+        // Server-authored from the session on every grant, so the pointer is always present.
+        parentResourceRequirement: ResourceParentResourceRequirement.MANDATORY,
+        childOperations: { lifecycle: { onParentDelete: { enabled: false } } },
+        contextPolicy: { enabled: false },
+    }),
+    createResourcesRelationship(CoreResourceType.USERS, CoreResourceType.APPLICATION_ACCESS_GRANTS, ResourceRelationshipCardinality.ONE, ResourceRelationshipCardinality.MANY, {
+        accessScopeStrategy: ResourceRelationshipAccessScopeStrategy.STANDALONE,
+        nature: RelationshipNature.REFERENCE,
+        foreignKeyField: 'approvedByUserId',
+        // OPTIONAL because the field is `.optional()`: unset while the request is pending and
+        // permanently unset on a denied or revoked grant. MANDATORY would assert an approver every
+        // grant must have — true of ACTIVE ones only, which is a lifecycle fact rather than a
+        // schema one.
+        parentResourceRequirement: ResourceParentResourceRequirement.OPTIONAL,
+        childOperations: { lifecycle: { onParentDelete: { enabled: false } } },
+        contextPolicy: { enabled: false },
+    }),
     // ── The two PEOPLE a grant names ─────────────────────────────────────
     //
     // `operatorUserId` (who asked) and `approvedByUserId` (who agreed) are both `.isForeignKey()` on
@@ -500,6 +621,87 @@ export const coreSharedResourceRelationship = [
         childOperations: { lifecycle: { onParentDelete: { enabled: false } } },
         contextPolicy: { enabled: false },
     }),
+    // ── SYSTEM-OF-RECORD PARTITION ASSIGNMENTS ───────────────────────────
+    //
+    // Which organization UNIT a remote partition belongs to — the edge that makes unit narrowing
+    // reach a read-through resource. Three parents, and each is a REFERENCE for a different reason.
+    //
+    // The DEPLOYMENT, carrying the primary scope. Same shape as APPLICATION -> APPLICATION_ACCESS_GRANTS
+    // and for the same measured reason: OPTIONAL + REQUIRES_CONTEXT + `isPrimaryScope`, because
+    // declaring it MANDATORY makes the ZodToMongoose convertor refuse the resource outright and INIT
+    // dies on a Mongo-persisted deployment. Addressing is carried by `isPrimaryScope` +
+    // REQUIRES_CONTEXT, which is what the URL builder reads, so the route is identical either way.
+    // No `onParentDelete`: the APPLICATION row is the deployment itself and is not purged.
+    createResourcesRelationship(CoreResourceType.APPLICATION, CoreResourceType.SYSTEM_OF_RECORD_PARTITION_ASSIGNMENTS, ResourceRelationshipCardinality.ONE, ResourceRelationshipCardinality.MANY, {
+        isPrimaryScope: true,
+        foreignKeyField: 'applicationId',
+        parentResourceRequirement: ResourceParentResourceRequirement.OPTIONAL,
+        accessScopeStrategy: ResourceRelationshipAccessScopeStrategy.REQUIRES_CONTEXT,
+        nature: RelationshipNature.REFERENCE,
+        contextPolicy: { enabled: false },
+    }),
+    // The UNIT the partition is confined to — the first edge in this registry from a non-org-scoped
+    // resource to ORGANIZATION_UNITS, so what it does and does not buy is stated rather than assumed.
+    //
+    // STANDALONE, because the assignment is addressed under the APPLICATION and never under a unit:
+    // an operator works from the partition map, not from the org chart.
+    //
+    // ⚠️ The FK buys EXISTENCE and nothing more. No relationship factory validates scope
+    // compatibility, and an APPLICATION-scoped row written by a super-administrator resolves
+    // `writeTenantId === ''` in the write-integrity check — so this edge cannot also assert that the
+    // unit belongs to the OWNER organization or that it is ACTIVE. Both are checked in the custom
+    // implementation through the system door against the owner-organization resolver, and pinned
+    // there. Reading this edge as a tenant check is the mistake it is written to prevent.
+    //
+    // `onParentDelete.enabled: false` states the survival explicitly rather than inheriting it. A
+    // cascade would be actively wrong: deleting a unit would silently unassign its partitions, and an
+    // unassigned partition is invisible to EVERY caller — an org-chart edit would quietly remove a
+    // company from the product. The unit DELETE guard refuses instead, which is the same answer that
+    // resource already gives for its own child units.
+    createResourcesRelationship(CoreResourceType.ORGANIZATION_UNITS, CoreResourceType.SYSTEM_OF_RECORD_PARTITION_ASSIGNMENTS, ResourceRelationshipCardinality.ONE, ResourceRelationshipCardinality.MANY, {
+        accessScopeStrategy: ResourceRelationshipAccessScopeStrategy.STANDALONE,
+        nature: RelationshipNature.REFERENCE,
+        foreignKeyField: 'organizationUnitId',
+        parentResourceRequirement: ResourceParentResourceRequirement.MANDATORY,
+        /*
+         * REFUSE_WHILE_CHILDREN_EXIST — and a CASCADE here would be the worst available default.
+         *
+         * Deleting a unit that still names partitions would silently UNASSIGN them, and an
+         * unassigned partition is invisible to EVERY caller — an organization-wide administrator
+         * included, because their entitlement is "every partition the operator ASSIGNED, and no
+         * others". An ordinary org-chart edit would withdraw a company from the product, and the
+         * symptom ("the German invoices are gone") arrives far from the delete that caused it.
+         *
+         * This posture was carried by a hand-written DELETE-prefix guard until `f4175a240`
+         * replaced two such guards with this declaration — rightly, since a hand-written guard is
+         * registered on one variant and invisible to the bulk path.
+         *
+         * The declaration did not reach a REFERENCE edge until #1485: the coherence check read
+         * `enabled === true` without reading `strategy`, so the one strategy that ASSERTS the
+         * child is independent was barred from the one nature that declares it. REFERENCE stays
+         * correct here — an assignment is not composed by a unit, it is an APPLICATION-scoped row
+         * that references one — and widening the nature to reach the mechanism would have been
+         * choosing the wrong semantics.
+         */
+        childOperations: { lifecycle: { onParentDelete: { enabled: true, strategy: ChildLifecycleStrategy.REFUSE_WHILE_CHILDREN_EXIST } } },
+        contextPolicy: { enabled: false },
+    }),
+    // The OPERATOR who last assigned or moved the partition. REFERENCE with no cascade, on the
+    // access-grant precedent and for its reason: making a user the owner resolves `lifecycleModelMode`
+    // to DEPENDENT, which is the value `classifySubjectErasureDisposition` reads — a user erasure would
+    // then own the row's fate, and an operator leaving must not silently unassign the companies they
+    // configured. The row is RETAIN_AND_IMPERSONALIZE precisely so the configuration survives the
+    // person while their prose does not.
+    createResourcesRelationship(CoreResourceType.USERS, CoreResourceType.SYSTEM_OF_RECORD_PARTITION_ASSIGNMENTS, ResourceRelationshipCardinality.ONE, ResourceRelationshipCardinality.MANY, {
+        accessScopeStrategy: ResourceRelationshipAccessScopeStrategy.STANDALONE,
+        nature: RelationshipNature.REFERENCE,
+        foreignKeyField: 'assignedByUserId',
+        // OPTIONAL because the field is `.optional()`: a row seeded by a lane with no session
+        // carries none, and MANDATORY would assert an operator every assignment must have.
+        parentResourceRequirement: ResourceParentResourceRequirement.OPTIONAL,
+        childOperations: { lifecycle: { onParentDelete: { enabled: false } } },
+        contextPolicy: { enabled: false },
+    }),
     createResourcesRelationship(CoreResourceType.ORGANIZATIONS, CoreResourceType.ORGANIZATION_PREFERENCES, ResourceRelationshipCardinality.ONE, ResourceRelationshipCardinality.ONE, {
         isPrimaryScope: true,
         nature: RelationshipNature.COMPOSITION,
@@ -567,7 +769,7 @@ export const coreSharedResourceRelationship = [
         // this went unnoticed. Removed rather than commented as pending. (The sibling
         // APPLICATION_FEATURES edge records the same blocker.)
         childOperations: { lifecycle: { onParentDelete: { enabled: true, mode: ChildLifecycleMode.IMMEDIATE, maxDepth: 1 } } },
-        foreignKeyField: 'appId',
+        foreignKeyField: 'applicationId',
         // 1:1 metadata: full on READ
         contextPolicy: {
             objectMode: ContextPolicy_ObjectMode.SUMMARY,
@@ -580,7 +782,7 @@ export const coreSharedResourceRelationship = [
         isPrimaryScope: true,
         nature: RelationshipNature.COMPOSITION,
         childOperations: { lifecycle: { onParentDelete: { enabled: true, mode: ChildLifecycleMode.IMMEDIATE, maxDepth: 1 } } },
-        foreignKeyField: 'appId',
+        foreignKeyField: 'applicationId',
         // High cardinality over time: disable on LIST/SEARCH
         contextPolicy: {
             operationOverrides: {
@@ -593,16 +795,36 @@ export const coreSharedResourceRelationship = [
         isPrimaryScope: true,
         nature: RelationshipNature.COMPOSITION,
         // Deliberately NO onParentCreate — same cache-resolved-ledger rationale as the
-        // ORGANIZATION_FEATURES edge above. TWO extra APP-only blockers even if that
-        // changed: (1) APPLICATION rows are provisioned via the platform CLI / apps-manager
-        // bootstrap, not the engine handler.create → executePostOperationLogic, so the seed
-        // hook never fires on real app provisioning; (2) this edge's foreignKeyField 'appId'
-        // is NOT the APPLICATION primary-scope identifier ('applicationId'), so it is absent
-        // from CONTEXT_AUTO_POPULATED_FIELD_IDENTIFIERS — createAsSystem's name-based
-        // preserve-list would strip it and seed an orphan row (the boot seedability guard
-        // does not catch this: it probes DTO defaults, not FK persistence).
+        // ORGANIZATION_FEATURES edge above, plus one APP-only blocker: APPLICATION rows are
+        // provisioned via the platform CLI / apps-manager bootstrap, not the engine
+        // handler.create → executePostOperationLogic, so the seed hook never fires on real app
+        // provisioning.
+        //
+        // THE FK IS `applicationId`, AND IT MUST STAY THAT NAME. This edge and its two siblings
+        // (APPLICATION_METADATA, APPLICATION_VERSIONS) declared `appId` until 2026-09-18. That
+        // is not a distinct ROLE the way `assignedToUserId` is — it is the application itself,
+        // spelled differently from the APPLICATION scope's registered field identifier — and
+        // every mechanism keyed on that identifier therefore skipped these three resources:
+        //
+        //   • CONTEXT_AUTO_POPULATED_FIELD_IDENTIFIERS did not carry it, so createAsSystem's
+        //     name-based preserve-list stripped it and a seed wrote an orphan row;
+        //   • the URL builder read a non-standard FK as a custom relationship PREFIX, so the
+        //     route became `/app-applications/{appId}/application-versions` (measured: that
+        //     path answers 200 and nothing addresses it) instead of nesting under
+        //     `/applications/{applicationId}`;
+        //   • and the frontend, whose resource context carries `applicationId`, could not
+        //     satisfy a required param named `appId`. Three Administration settings panes —
+        //     General, Versions, Entitlements — issued NO REQUEST AT ALL and rendered their
+        //     failure state, which is indistinguishable from a backend outage.
+        //
+        // The last one is why this is recorded here rather than in a changelog: the divergence
+        // was noticed twice and written down twice (in this comment's previous text, and in
+        // `resources-config-operations.urls-builder.utils.ts`, which called it "7 phantom
+        // combinations […] nobody had noticed because nothing called it"). Naming an invariant
+        // is not upholding it. A non-standard `foreignKeyField` is a claim that the edge means
+        // something other than plain ownership; do not spell one differently for brevity.
         childOperations: { lifecycle: { onParentDelete: { enabled: true, mode: ChildLifecycleMode.IMMEDIATE, maxDepth: 1 } } },
-        foreignKeyField: 'appId',
+        foreignKeyField: 'applicationId',
         contextPolicy: {
             objectMode: ContextPolicy_ObjectMode.SUMMARY,
         }
@@ -642,15 +864,29 @@ export const coreSharedResourceRelationship = [
          * restricts every read to the authenticated caller's own credentials — nobody can reach
          * another person's key, structurally, rather than because a role list happens to be narrow.
          *
-         * And its COMPOSITION cascade is what stops a personal credential outliving the person. The
-         * retention policy deliberately scrubs nothing (a secret is not pseudonymised, it is
-         * destroyed), so the DELETE dispatched here IS the erasure answer for this resource. A
-         * REFERENCE edge cannot carry `onParentDelete` at all, so getting the nature wrong would
+         * And it is what destroys a person's credentials, on BOTH paths that remove a person: the
+         * delete cascade when the USERS row is deleted, and a subject erasure, which KEEPS the
+         * (scrubbed) USERS row and so reads this edge's `strategy` instead. A secret is not
+         * pseudonymised, it is destroyed.
+         *
+         * `strategy: DELETE` is AUTHORED, not left to the default, and that is the fix for #1569.
+         * The credential resource used to declare `retentionPolicy: RETAIN_ONLY`; once #1279 made a
+         * silent edge honour the child's retention declaration, every erasure kept the person's
+         * third-party tokens in place and reported them "retained by declaration". The retention
+         * policy is gone, and naming DELETE here means that if anyone re-adds one, the erasure
+         * refuses the contradiction loudly (`findSubjectErasureRetentionContradictedEdges`) instead
+         * of quietly keeping the credentials again.
+         *
+         * A REFERENCE edge cannot carry `onParentDelete` at all, so getting the nature wrong would
          * leave a live third-party credential belonging to somebody who asked to be forgotten.
          */
         isPrimaryScope: true,
         nature: RelationshipNature.COMPOSITION,
-        childOperations: { lifecycle: { onParentDelete: { enabled: true, mode: ChildLifecycleMode.IMMEDIATE, maxDepth: 1 } } },
+        childOperations: {
+            lifecycle: {
+                onParentDelete: { enabled: true, mode: ChildLifecycleMode.IMMEDIATE, maxDepth: 1, strategy: ChildLifecycleStrategy.DELETE },
+            },
+        },
         // SECURITY: as the organization-owned sibling — a row holding a secret must never ride in a
         // context DTO the client receives.
         contextPolicy: { enabled: false }
@@ -703,12 +939,11 @@ export const coreSharedResourceRelationship = [
         childOperations: {
             lifecycle: { onParentDelete: { enabled: false } },
         },
-        contextPolicy: {
-            operationOverrides: {
-                [CoreResourceOperation.LIST]: { enabled: false },
-                [CoreResourceOperation.SEARCH]: { enabled: false },
-            },
-        },
+        // Off the context surface entirely (#583), as on the APPLICATION and USERS edges above. With
+        // READ still enabled, an organization context read embedded the tenant's WHOLE audit history
+        // — 143 rows on a two-week-old dogfood tenant, monotonically growing, on an interactive
+        // path. An audit row is not ambient context; the Audit Log Viewer pages this edge's LIST.
+        contextPolicy: { enabled: false },
     }),
     // parentResourceRequirement=OPTIONAL because AuditableEvent_BaseSchema.userId is optional —
     // audit logs can be application-level events with no associated user (e.g. system events).
@@ -767,7 +1002,11 @@ export const coreSharedResourceRelationship = [
         isPrimaryScope: true,
         foreignKeyField: 'userId',
         nature: RelationshipNature.COMPOSITION,
-        childOperations: { lifecycle: { onParentDelete: { enabled: true, mode: ChildLifecycleMode.IMMEDIATE, maxDepth: 1 } } },
+        // `strategy: DELETE` is AUTHORED (#1569): a subject erasure keeps the scrubbed USERS row and
+        // reads this strategy, so an erased person's unread counters are destroyed. Naming it means a
+        // retention policy re-added to the badge resource is refused as a contradiction
+        // (`findSubjectErasureRetentionContradictedEdges`) instead of quietly keeping the rows.
+        childOperations: { lifecycle: { onParentDelete: { enabled: true, mode: ChildLifecycleMode.IMMEDIATE, maxDepth: 1, strategy: ChildLifecycleStrategy.DELETE } } },
         // Notifications: ephemeral, accessed via dedicated service
         contextPolicy: { enabled: false }
     }),
@@ -792,6 +1031,14 @@ export const coreSharedResourceRelationship = [
         // Internal resource: never fetch via context, accessed via dedicated services
         contextPolicy: { enabled: false }
     }),
+    // Provider-call records: the same internal, application-primary shape as the queue records above.
+    // STANDALONE keeps them off URL routing; nothing reaches them except the recorder and the evidence door.
+    createResourcesRelationship(CoreResourceType.APPLICATION, CoreResourceType.PROVIDER_CALL_RECORDS, ResourceRelationshipCardinality.ONE, ResourceRelationshipCardinality.MANY, {
+        accessScopeStrategy: ResourceRelationshipAccessScopeStrategy.STANDALONE,
+        isPrimaryScope: true,
+        nature: RelationshipNature.REFERENCE,
+        contextPolicy: { enabled: false }
+    }),
     createResourcesRelationship(CoreResourceType.APPLICATION, CoreResourceType.JOB_PAYLOAD_STORAGE, ResourceRelationshipCardinality.ONE, ResourceRelationshipCardinality.MANY, {
         accessScopeStrategy: ResourceRelationshipAccessScopeStrategy.STANDALONE,
         isPrimaryScope: true,
@@ -961,11 +1208,11 @@ export const coreSharedResourceRelationship = [
     // account genuinely belongs to its scope); only the dies-with-parent behaviour is declined.
     //
     // With this cascade disabled, a DIRECT hard delete of the account became the only remaining path
-    // into the forbidden half-state described below. That path is now closed at runtime: the billing
-    // account's DELETE carries a fail-closed dependents guard that refuses with 409
-    // `BILLING_ACCOUNT_HAS_DEPENDENTS` while any retained child still references the account
-    // (`assertNoBillingAccountDependents`, wired as a DELETE prefix custom implementation). Keep that
-    // guard's family list in lock-step with the retained edges declared here.
+    // into the forbidden half-state described below. That path is closed at runtime by declaration:
+    // each `BillingAccounts → <child>` edge below declares `onParentDelete.strategy:
+    // REFUSE_WHILE_CHILDREN_EXIST`, so the service tier refuses the account's DELETE with 409
+    // `RESOURCE_HAS_DEPENDENTS` while any retained child still references it, before anything is
+    // written. The scope edges stay `enabled: false`: those rows must outlive their scope.
     ...createPolymorphicScopeRelationships(billingAccountsPolymorphicDeclaration, {
         nature: RelationshipNature.COMPOSITION,
         childOperations: { lifecycle: { onParentDelete: { enabled: false } } }, // RETAIN (compliance decision 2026-07-29) — see the note above.
@@ -982,7 +1229,7 @@ export const coreSharedResourceRelationship = [
     // userBillingAccounts → userSubscriptions
     ...createPolymorphicRelationships(billingAccountsPolymorphicDeclaration, billingSubscriptionsPolymorphicDeclaration, ResourceRelationshipCardinality.ONE, ResourceRelationshipCardinality.MANY, {
         nature: RelationshipNature.COMPOSITION,
-        childOperations: { lifecycle: { onParentDelete: { enabled: false } } }, // RETAIN (compliance decision 2026-07-29) — see the billing-retention note above.
+        childOperations: { lifecycle: { onParentDelete: { enabled: true, strategy: ChildLifecycleStrategy.REFUSE_WHILE_CHILDREN_EXIST } } }, // RESTRICT: the account may not be deleted while these retained rows reference it — see the billing-retention note above.
         contextPolicy: {},
     }),
     // ── Polymorphic Billing Children ─────────────────────────────────────
@@ -990,16 +1237,59 @@ export const coreSharedResourceRelationship = [
     // ⚠️ BILLING RETENTION (compliance decision, Paul — 2026-07-29): subscriptions / invoiceRefs /
     // usageRecords / creditPools are RETAINED, never cascade-deleted. The financial audit trail must
     // survive the deletion of the scope or the billing account that produced it (tax / SOX retention),
-    // so every `onParentDelete` below is DISABLED — 16 edges in total (4 families × 2 parents × 2 scope
-    // variants). These are the entries formerly tracked as `KNOWN_CASCADE_DELETABILITY_GAPS`.
+    // so none of the 16 edges below cascades (4 families × 2 parents × 2 scope variants): the scope
+    // edges DISABLE `onParentDelete`, and the billing-account edges declare REFUSE_WHILE_CHILDREN_EXIST
+    // so the account cannot be deleted out from under them. These are the entries formerly tracked as
+    // `KNOWN_CASCADE_DELETABILITY_GAPS`.
     //
     // Why NOT `retentionPolicy` + `IMPERSONALIZE_AND_RETAIN`: that machinery also HIDES and FREEZES the
     // row (reachable only through the audited see-through path), and these invoices must stay visible
-    // for ordinary accounting. It is also the wrong tool semantically — a billing row holds no personal
-    // data of its own (no name, email or address; the person is a foreign key), so there is nothing on
-    // it to scrub. The PII lives on the linked USER, which is where impersonalization belongs: erasing
-    // a subject scrubs the user row and keeps it, so these financial rows keep resolving to an
-    // anonymized subject.
+    // for ordinary accounting.
+    //
+    // ## DECIDED 2026-09-17 (#1208), and the SECOND reason this used to give is now FALSE
+    //
+    // It said "a billing row holds no personal data of its own (no name, email or address; the person
+    // is a foreign key), so there is nothing on it to scrub". That has not been true since
+    // `invoice-ref.shared.schemas.ts` gained `hostedInvoiceUrl` and `invoicePdfUrl`, which
+    // `addImpersonalizeWith(..., REMOVE)` marks precisely BECAUSE they address provider-hosted
+    // documents carrying the person's name and billing address. A blanket "no personal data here" is
+    // the kind of claim that stops being checked once it is written down.
+    //
+    // The conclusion survives on the FIRST reason alone, and the external norms point the same way:
+    //
+    //  - The erasure right does not reach these records. GDPR Art. 17(3)(b) excepts processing
+    //    "necessary for compliance with a legal obligation which requires processing by Union or
+    //    Member State law to which the controller is subject", which is what a statutory invoice
+    //    retention period is.
+    //    spec-cite: Regulation (EU) 2016/679, Art. 17(3)(b) (https://gdpr-info.eu/art-17-gdpr/).
+    //  - The record must stay COMPLETE, not scrubbed. An invoice is legally required to carry "the
+    //    full name and address of the taxable person and of the customer", so the identifying data is
+    //    mandated CONTENT rather than something incidental that may be removed; and every taxable
+    //    person must store their invoices for a period each Member State sets.
+    //    spec-cite: Council Directive 2006/112/EC, Art. 226 (invoice content) and Arts. 244/247
+    //    (storage and period).
+    //  - Scrubbing our URL removes a POINTER, never the document. The invoice itself lives at the
+    //    payment provider, which retains it under its own obligation and offers its own redaction —
+    //    so dropping the link costs the operator the ability to open their own invoice and gains the
+    //    data subject nothing the controller does not still hold.
+    //
+    // Storage limitation is therefore satisfied by the retention SCHEDULE (the period a class
+    // declares), not by an erasure — which is the split `retention-schedule.shared.schemas.ts` already
+    // draws between WHAT erasure does to a row and HOW LONG a row is kept.
+    //
+    // ## The declared treatments are currently UNREACHABLE, which is the live half of #1208
+    //
+    // `retentionPolicy` is the RESOURCE-level opt-in; the per-EDGE trigger is
+    // `onParentDelete.strategy: IMPERSONALIZE_AND_RETAIN`, and the ONLY occurrence of that member in
+    // this file is the sentence above explaining why it is not used. So no billing row is ever marked
+    // RETAINED and the invoice-ref scrub never runs: after an erasure those two URLs are intact.
+    //
+    // That is the opposite of what #1208 feared — the risk was never that an erased customer's
+    // invoices would vanish from accounting, it is that a scrub was declared, reasoned about, and
+    // wired to nothing. Removing `retentionPolicy` from the five billing resources is the follow-
+    // through; it is left out of this change because it also withdraws derived `seeRetained` grants
+    // and would orphan the `addImpersonalizeWith` treatments, which is a config-build question rather
+    // than a documentation one.
     //
     // A COMPOSITION without `onParentDelete` is an explicitly supported combination — it leaves the
     // children behind by design choice (see `validateCompositionCascadeDeletability`). The nature stays
@@ -1007,7 +1297,7 @@ export const coreSharedResourceRelationship = [
     // behaviour is declined.
     //
     // The `Scope → BillingAccounts` edge above was RETAINED on the same day as a coherence follow-up
-    // (18 disabled billing cascades in total). Without it these 16 edges kept rows whose owning account
+    // (18 billing edges, none of which cascades). Without it these 16 edges kept rows whose owning account
     // had been deleted — see the rationale block at that declaration. Do not re-enable either half in
     // isolation: retaining the children while deleting the account strands the provider-customer
     // mapping, and deleting the children while retaining the account discards the audit trail.
@@ -1019,7 +1309,7 @@ export const coreSharedResourceRelationship = [
     // BillingAccounts → InvoiceRefs (variant-matched, 1:N)
     ...createPolymorphicRelationships(billingAccountsPolymorphicDeclaration, invoiceRefsPolymorphicDeclaration, ResourceRelationshipCardinality.ONE, ResourceRelationshipCardinality.MANY, {
         nature: RelationshipNature.COMPOSITION,
-        childOperations: { lifecycle: { onParentDelete: { enabled: false } } }, // RETAIN (compliance decision 2026-07-29) — see the billing-retention note above.
+        childOperations: { lifecycle: { onParentDelete: { enabled: true, strategy: ChildLifecycleStrategy.REFUSE_WHILE_CHILDREN_EXIST } } }, // RESTRICT: the account may not be deleted while these retained rows reference it — see the billing-retention note above.
         contextPolicy: {},
     }),
     // Usage Records — scope relationships (2 variants: ORG, USER)
@@ -1030,7 +1320,7 @@ export const coreSharedResourceRelationship = [
     // BillingAccounts → UsageRecords (variant-matched, 1:N)
     ...createPolymorphicRelationships(billingAccountsPolymorphicDeclaration, usageRecordsPolymorphicDeclaration, ResourceRelationshipCardinality.ONE, ResourceRelationshipCardinality.MANY, {
         nature: RelationshipNature.COMPOSITION,
-        childOperations: { lifecycle: { onParentDelete: { enabled: false } } }, // RETAIN (compliance decision 2026-07-29) — see the billing-retention note above.
+        childOperations: { lifecycle: { onParentDelete: { enabled: true, strategy: ChildLifecycleStrategy.REFUSE_WHILE_CHILDREN_EXIST } } }, // RESTRICT: the account may not be deleted while these retained rows reference it — see the billing-retention note above.
         contextPolicy: { enabled: false },
     }),
     // Credit Pools — scope relationships (2 variants: ORG, USER)
@@ -1041,7 +1331,7 @@ export const coreSharedResourceRelationship = [
     // BillingAccounts → CreditPools (variant-matched, 1:N)
     ...createPolymorphicRelationships(billingAccountsPolymorphicDeclaration, creditPoolsPolymorphicDeclaration, ResourceRelationshipCardinality.ONE, ResourceRelationshipCardinality.MANY, {
         nature: RelationshipNature.COMPOSITION,
-        childOperations: { lifecycle: { onParentDelete: { enabled: false } } }, // RETAIN (compliance decision 2026-07-29) — see the billing-retention note above.
+        childOperations: { lifecycle: { onParentDelete: { enabled: true, strategy: ChildLifecycleStrategy.REFUSE_WHILE_CHILDREN_EXIST } } }, // RESTRICT: the account may not be deleted while these retained rows reference it — see the billing-retention note above.
         contextPolicy: {},
     }),
     // Referrals keep shared FK field names (`referrerBillingAccountId`, `referredBillingAccountId`)
@@ -1130,7 +1420,10 @@ export const coreSharedResourceRelationship = [
         // (ORGANIZATION_FEATURES / APPLICATION_FEATURES both declared the cascade) →
         // orphan-on-user-delete risk; now aligned. Deliberately NO onParentCreate: the
         // scope-features ledger is cache-resolved (see the ORGANIZATION_FEATURES note).
-        childOperations: { lifecycle: { onParentDelete: { enabled: true, mode: ChildLifecycleMode.IMMEDIATE, maxDepth: 1 } } },
+        // `strategy: DELETE` is AUTHORED (#1569): an erasure keeps the scrubbed USERS row and reads
+        // this strategy, so an erased person's entitlement overrides are destroyed; a retention
+        // policy re-added to USER_FEATURES is then refused as a contradiction rather than obeyed.
+        childOperations: { lifecycle: { onParentDelete: { enabled: true, mode: ChildLifecycleMode.IMMEDIATE, maxDepth: 1, strategy: ChildLifecycleStrategy.DELETE } } },
         contextPolicy: { enabled: false },
     }),
     createResourcesRelationship(CoreResourceType.APPLICATION, CoreResourceType.FILES, ResourceRelationshipCardinality.ONE, ResourceRelationshipCardinality.MANY, {
@@ -1203,15 +1496,78 @@ export const coreSharedResourceRelationship = [
         nature: RelationshipNature.COMPOSITION,
         // onParentCreate: eager-seed the lifecycle-state row on user creation — the
         // genuine latent gap (no READ self-heal); the evaluator read-then-creates so no dup.
-        childOperations: { lifecycle: { onParentDelete: { enabled: true, mode: ChildLifecycleMode.IMMEDIATE, maxDepth: 1 }, onParentCreate: { enabled: true } } },
+        //
+        // `initialData.override` because the SHAPE the two doors produce must match, and the
+        // schema defaults alone cannot produce it. The lazy doors persist
+        // `createInitialScopedLifecycleState` — `stageHistory: [{ SIGNED_UP, … }]`,
+        // `stagesVisited: [SIGNED_UP]` — while this eager door wrote the schema defaults,
+        // `[]` and `[]`. The eager door is the one that runs in production, so the lazy pair's
+        // shape was only ever written when THIS one had failed.
+        //
+        // The consequence is `hasReachedStage`, whose own JSDoc says it exists "for reliable
+        // stage visitation checks": after the first transition `stagesVisited` read
+        // `[ACTIVATED]`, so it answered FALSE for SIGNED_UP — a stage the subject demonstrably
+        // passed — and the transition audit trail started one entry short.
+        //
+        // The values come from the same named source the lazy doors use, so there is still one
+        // shape. It is NOT moved into the schema defaults: `stageHistory` carries
+        // `RedactionType.RESET`, so a dynamic default would be written BY an erasure — the
+        // hazard `lastActiveAt` names one field below — re-asserting a SIGNED_UP entry stamped
+        // at erasure time. Seeding and the erasure default are different questions.
+        childOperations: {
+            lifecycle: {
+                onParentDelete: { enabled: true, mode: ChildLifecycleMode.IMMEDIATE, maxDepth: 1 },
+                onParentCreate: {
+                    enabled: true,
+                    initialData: {
+                        override: () => {
+                            const initial = GuidanceStateUtils.createInitialLifecycleState();
+                            return { stageHistory: initial.stageHistory, stagesVisited: initial.stagesVisited };
+                        },
+                    },
+                },
+            },
+        },
         contextPolicy: { enabled: false }
     }),
     createResourcesRelationship(CoreResourceType.ORGANIZATIONS, CoreResourceType.ORGANIZATION_LIFECYCLE_STATE, ResourceRelationshipCardinality.ONE, ResourceRelationshipCardinality.ONE, {
         isPrimaryScope: true,
         foreignKeyField: 'organizationId',
         nature: RelationshipNature.COMPOSITION,
-        // onParentCreate: eager-seed the lifecycle-state row on org creation (latent gap).
-        childOperations: { lifecycle: { onParentDelete: { enabled: true, mode: ChildLifecycleMode.IMMEDIATE, maxDepth: 1 }, onParentCreate: { enabled: true } } },
+        // onParentCreate: eager-seed the lifecycle-state row on org creation — the
+        // genuine latent gap (no READ self-heal); the evaluator read-then-creates so no dup.
+        //
+        // `initialData.override` because the SHAPE the two doors produce must match, and the
+        // schema defaults alone cannot produce it. The lazy doors persist
+        // `createInitialScopedLifecycleState` — `stageHistory: [{ SIGNED_UP, … }]`,
+        // `stagesVisited: [SIGNED_UP]` — while this eager door wrote the schema defaults,
+        // `[]` and `[]`. The eager door is the one that runs in production, so the lazy pair's
+        // shape was only ever written when THIS one had failed.
+        //
+        // The consequence is `hasReachedStage`, whose own JSDoc says it exists "for reliable
+        // stage visitation checks": after the first transition `stagesVisited` read
+        // `[ACTIVATED]`, so it answered FALSE for SIGNED_UP — a stage the subject demonstrably
+        // passed — and the transition audit trail started one entry short.
+        //
+        // The values come from the same named source the lazy doors use, so there is still one
+        // shape. It is NOT moved into the schema defaults: `stageHistory` carries
+        // `RedactionType.RESET`, so a dynamic default would be written BY an erasure — the
+        // hazard `lastActiveAt` names one field below — re-asserting a SIGNED_UP entry stamped
+        // at erasure time. Seeding and the erasure default are different questions.
+        childOperations: {
+            lifecycle: {
+                onParentDelete: { enabled: true, mode: ChildLifecycleMode.IMMEDIATE, maxDepth: 1 },
+                onParentCreate: {
+                    enabled: true,
+                    initialData: {
+                        override: () => {
+                            const initial = GuidanceStateUtils.createInitialLifecycleState();
+                            return { stageHistory: initial.stageHistory, stagesVisited: initial.stagesVisited };
+                        },
+                    },
+                },
+            },
+        },
         contextPolicy: { enabled: false }
     }),
     // ── Inbound Contacts (Phase 0.5, Q-E=B) ──────────────────────────────
@@ -1317,16 +1673,22 @@ export const coreSharedResourceRelationship = [
             },
         },
     }),
-    // SIEM Delivery DLQ — collection (MANY per scope)
+    // SIEM Delivery DLQ — collection (MANY per scope). Off the context surface (#583): a dead-letter
+    // queue is append-only and grows without bound during a SIEM outage, exactly when a scope's context
+    // read must stay cheap. Operators page it through its own LIST.
     ...createPolymorphicScopeRelationships(siemDeliveryDlqPolymorphicDeclaration, {
         nature: RelationshipNature.COMPOSITION,
         childOperations: { lifecycle: { onParentDelete: { enabled: true, mode: ChildLifecycleMode.IMMEDIATE, maxDepth: 1 } } },
-        contextPolicy: {
-            operationOverrides: {
-                [CoreResourceOperation.LIST]: { enabled: false },
-                [CoreResourceOperation.SEARCH]: { enabled: false },
-            },
-        },
+        contextPolicy: { enabled: false },
+    }),
+    // SIEM Delivery Outbox — collection (MANY per scope). Off the context surface for the SAME reason
+    // as the DLQ above and one more: these rows are machinery in flight, claimed and deleted by the
+    // collector within a window, so a context read would carry a set that is stale by the time it is
+    // read. Cascades on scope delete like its sibling — a tenant that is gone has nothing left to export.
+    ...createPolymorphicScopeRelationships(siemDeliveryOutboxPolymorphicDeclaration, {
+        nature: RelationshipNature.COMPOSITION,
+        childOperations: { lifecycle: { onParentDelete: { enabled: true, mode: ChildLifecycleMode.IMMEDIATE, maxDepth: 1 } } },
+        contextPolicy: { enabled: false },
     }),
     // SCIM Tokens — collection (MANY per scope)
     ...createPolymorphicScopeRelationships(scimTokensPolymorphicDeclaration, {
@@ -1363,18 +1725,13 @@ export const coreSharedResourceRelationship = [
             },
         },
     }),
-    // M2M Webhook Delivery Log — collection (MANY per scope). LIST/SEARCH stay
-    // off the context surface (high-volume noise — admin queries them via the
-    // dedicated UI, not via implicit context inclusion). Mirrors SIEM DLQ wiring.
+    // M2M Webhook Delivery Log — collection (MANY per scope). Off the context surface entirely (#583):
+    // one row per delivery attempt, unbounded, and READ used to embed all of them. Admins query it via
+    // the dedicated UI, not via implicit context inclusion. Mirrors SIEM DLQ wiring.
     ...createPolymorphicScopeRelationships(m2mWebhookDeliveryLogPolymorphicDeclaration, {
         nature: RelationshipNature.COMPOSITION,
         childOperations: { lifecycle: { onParentDelete: { enabled: true, mode: ChildLifecycleMode.IMMEDIATE, maxDepth: 1 } } },
-        contextPolicy: {
-            operationOverrides: {
-                [CoreResourceOperation.LIST]: { enabled: false },
-                [CoreResourceOperation.SEARCH]: { enabled: false },
-            },
-        },
+        contextPolicy: { enabled: false },
     }),
 ];
 export const coreShared_ResourcesConfigurations_FactoryMap = {
@@ -1392,6 +1749,8 @@ export const coreShared_ResourcesConfigurations_FactoryMap = {
     [CoreResourceType.ORGANIZATION_PROFILES]: organizationProfileResourceConfiguration_InitializationFactory,
     [CoreResourceType.ORGANIZATION_PREFERENCES]: organizationPreferencesResourceConfiguration_InitializationFactory,
     [CoreResourceType.PLATFORM_ACCESS_GRANTS]: platformAccessGrantsResourceConfiguration_InitializationFactory,
+    [CoreResourceType.APPLICATION_ACCESS_GRANTS]: applicationAccessGrantsResourceConfiguration_InitializationFactory,
+    [CoreResourceType.SYSTEM_OF_RECORD_PARTITION_ASSIGNMENTS]: systemOfRecordPartitionAssignmentsResourceConfiguration_InitializationFactory,
     [CoreResourceType.ORGANIZATION_NOTIFICATIONS]: organizationNotificationsResourceConfiguration_InitializationFactory,
     [CoreResourceType.ORGANIZATION_FEATURES]: organizationFeaturesResourceConfiguration_InitializationFactory,
     [CoreResourceType.USER_FEATURES]: userFeaturesResourceConfiguration_InitializationFactory,
@@ -1433,6 +1792,7 @@ export const coreShared_ResourcesConfigurations_FactoryMap = {
     // Queue System Resources (internal infrastructure)
     [CoreResourceType.JOB_EXECUTIONS]: jobExecution_ResourceConfiguration_InitializationFactory,
     [CoreResourceType.JOB_PAYLOAD_STORAGE]: jobPayloadStorage_ResourceConfiguration_InitializationFactory,
+    [CoreResourceType.PROVIDER_CALL_RECORDS]: providerCallRecordsResourceConfiguration_InitializationFactory,
     // Flows-Actors Execution Resource (persisted flow/actor system executions)
     ...flowActorExecutionsPolymorphicFactories,
     // Flows-Actors Task Resource (the WORK plane behind the A2A `Task` object)
@@ -1442,6 +1802,7 @@ export const coreShared_ResourcesConfigurations_FactoryMap = {
     // Authentication Resources
     [CoreResourceType.USER_IDENTITY_LINKS]: userIdentityLinksResourceConfiguration_InitializationFactory,
     [CoreResourceType.OAUTH_CONSENT_GRANTS]: oauthConsentGrantsResourceConfiguration_InitializationFactory,
+    [CoreResourceType.USER_GOVERNED_DOCUMENT_ACCEPTANCES]: userGovernedDocumentAcceptancesResourceConfiguration_InitializationFactory,
     // Anonymous Session Resources (W7.3a)
     [CoreResourceType.ANONYMOUS_USERS]: anonymousUsersResourceConfiguration_InitializationFactory,
     // Inbound Contacts (Phase 0.5 — public marketing-site lead capture, Q-E=B)
@@ -1460,6 +1821,7 @@ export const coreShared_ResourcesConfigurations_FactoryMap = {
     ...ssoConnectionPolymorphicFactories,
     ...siemExportConfigPolymorphicFactories,
     ...siemDeliveryDlqPolymorphicFactories,
+    ...siemDeliveryOutboxPolymorphicFactories,
     ...scimTokensPolymorphicFactories,
     ...scimProvisioningConfigPolymorphicFactories,
     // M2M Outbound Webhook Resources — polymorphic dual-scope (2 × 2 = 4 entries)