@wildo-ai/saas-models 1.0.1 → 1.1.0

package/dist/esm/compliance/audit-trails/auditable-events.shared.schema.js

@@ -1,5 +1,11 @@
 import { z } from "zod";
-import { ResourceOperationRiskLevel } from "../../resources/resources.shared.schemas.js";
+import { PersonalDataCategory } from "../privacy/personal-data-category.shared.schemas.js";
+import { ResourceOperationRiskLevel, ResourceOperationVariantType } from "../../resources/resources.shared.schemas.js";
+import { CoreResourceOperation } from "../../resources/resources.shared.core.definitions.js";
+import { PlatformAccessGrantAutoApprovalReason, PlatformAccessGrantLifecycleTransition, PlatformAccessGrantStatus, } from "../../security/authorizations/platform-access-grants.shared.schemas.js";
+import { ExecutionContext_ExecutionType } from "../../runtime/execution-context.shared.schemas.js";
+import { AuthScopeType, SsoConnectionType, } from "../../security/authentications/authentication.shared.schemas.js";
+import { WebhookEndpointProbeOutcome } from "../../notifications/m2m/webhook-config.shared.schemas.js";
 export var CoreAuditableEventType;
 (function (CoreAuditableEventType) {
     // Authentication Events
@@ -8,28 +14,139 @@ export var CoreAuditableEventType;
     CoreAuditableEventType["USER_LOGIN_FAILED"] = "user_login_failed";
     CoreAuditableEventType["USER_ACCOUNT_LOCKED"] = "user_account_locked";
     CoreAuditableEventType["USER_PASSWORD_CHANGED"] = "user_password_changed";
+    // audit-event-unemitted: superseded by the per-METHOD events, which is what the MFA services
+    // actually emit — `USER_MFA_SETUP_STARTED` / `USER_MFA_SETUP_COMPLETED` on enrolment and
+    // `USER_TOTP_DISABLED` on removal. A coarse "MFA enabled/disabled" pair cannot say WHICH factor
+    // changed, and a user with TOTP plus a passkey makes that distinction the whole question. Kept
+    // rather than deleted because a future factor-agnostic rollup is a plausible SIEM convenience;
+    // it must not be emitted ALONGSIDE the per-method events without deciding which is canonical.
     CoreAuditableEventType["USER_MFA_ENABLED"] = "user_mfa_enabled";
+    // audit-event-unemitted: see USER_MFA_ENABLED — `USER_TOTP_DISABLED` is the emitted event.
     CoreAuditableEventType["USER_MFA_DISABLED"] = "user_mfa_disabled";
+    // audit-event-unemitted: expiry is PASSIVE — a token simply ages out, so there is no moment for
+    // anyone to observe. Emitting it would require polling every live session, and would produce one
+    // row per session per lifetime: the highest-volume, lowest-signal stream in the trail. The
+    // session endings that carry intent are already covered (`USER_LOGOUT`, and the token-revocation
+    // events). Deliberately declared-and-unwired rather than deleted, because a future
+    // idle-timeout/forced-expiry feature — where expiry IS an act someone triggers — is exactly what
+    // it should name.
     CoreAuditableEventType["USER_SESSION_EXPIRED"] = "user_session_expired";
+    // Machine (non-human) Authentication Events — api-key / OAuth-client / exchanged client-credentials
+    // token resolving to an ORGANIZATION_MACHINE / APPLICATION_MACHINE principal. The credential
+    // provenance (authMethod + credentialId) + scope ride the typed eventData.
+    CoreAuditableEventType["MACHINE_AUTH_SUCCESS"] = "machine_auth_success";
+    CoreAuditableEventType["MACHINE_AUTH_FAILED"] = "machine_auth_failed";
+    // Machine RESOURCE-ACCESS event — the token-USE twin of MACHINE_AUTH_SUCCESS (token-MINT). Emitted
+    // per external request when a machine principal exercises an audience-bound resource-server surface
+    // (A2A `message/send`, MCP `tools/call`, …). MACHINE_AUTH_SUCCESS fires once at `/oauth/token` and
+    // is low-volume; MACHINE_ACCESS lets an org SIEM see WHAT a machine did, not just that it authed.
+    CoreAuditableEventType["MACHINE_ACCESS"] = "machine_access";
     // User Lifecycle Events
+    // audit-event-unemitted: this operation now leaves evidence as a generic
+    // `RESOURCE_OPERATION_PERFORMED` row, which carries strictly MORE than this member could — the
+    // operation identity triple, the actor's roles as they stood, the top-level `correlationId` that
+    // groups a cascade, and before/after values for `.isAuditEvidence()` fields. Wiring this one too would
+    // write two rows for one action. Kept rather than deleted: a purpose-built event is still the
+    // right shape if this verb ever needs a payload the generic row cannot reconstruct (the standing
+    // precedent is `USER_APP_ROLES_CHANGED`, which carries the `requestedRoles` set the role-ceiling
+    // gate measured — something a before/after diff cannot recover).
     CoreAuditableEventType["USER_CREATED"] = "user_created";
+    // audit-event-unemitted: covered by the generic `RESOURCE_OPERATION_PERFORMED` row — see USER_CREATED.
     CoreAuditableEventType["USER_UPDATED"] = "user_updated";
     CoreAuditableEventType["USER_DELETED"] = "user_deleted";
+    // Application-Role Administration — the APPLICATION-scope twin of
+    // ORGANIZATION_MEMBER_ROLE_CHANGED. `User.appRoles` IS the principal's live application authority
+    // (it is read back into `initiatorRoles` on their very next request), so every change to it is an
+    // access-control decision that must leave evidence. Emitted by the USERS role-administration write
+    // paths (assign_roles / revoke_roles and the core CREATE/UPDATE that can rewrite the array), never
+    // for an update that leaves `appRoles` untouched.
+    // assurance-control: WILDO.ACCESS.PRIVILEGE_EVIDENCE — evidence of privilege grant/revocation.
+    CoreAuditableEventType["USER_APP_ROLES_CHANGED"] = "user_app_roles_changed";
+    // The application booted with NO administratively usable super-administrator — a state the write
+    // guards refuse to create, so its presence means it arrived some other way: a direct database
+    // edit, a restore from a backup taken mid-erasure, a seed that authored no administrator, or a
+    // role-table reconfiguration that changed which roles confer super-admin under an existing
+    // population. Reported at startup, never fatal (a fresh application legitimately boots with no
+    // users at all before its first administrator is seeded or registers).
+    // assurance-control: WILDO.ACCESS.ADMINISTRATIVE_CONTINUITY — evidence that the application has no
+    // accountable administrative principal, which is unrecoverable in-product once reached.
+    CoreAuditableEventType["APPLICATION_SUPER_ADMIN_FLOOR_BREACHED"] = "application_super_admin_floor_breached";
+    /**
+     * A tenant was left with no administratively usable owner by an action that was ALLOWED to proceed.
+     *
+     * The organization-scope twin of {@link APPLICATION_SUPER_ADMIN_FLOOR_BREACHED}, and unlike it this
+     * one HAS an actor: it is emitted when a user lifecycle transition (typically a suspension) removes
+     * the last usable owner of a tenant. That write is deliberately not refused — suspension is usually
+     * incident response, and blocking it would mean an operator cannot lock out a compromised owner
+     * without first transferring ownership using the tenant the attacker controls.
+     *
+     * Because the action proceeds, this record is the ENTIRE control. It is not decoration.
+     */
+    CoreAuditableEventType["ORGANIZATION_OWNER_FLOOR_BREACHED"] = "organization_owner_floor_breached";
     // Organization Lifecycle Events
+    // audit-event-unemitted: covered by the generic `RESOURCE_OPERATION_PERFORMED` row — see USER_CREATED.
     CoreAuditableEventType["ORGANIZATION_CREATED"] = "organization_created";
+    // audit-event-unemitted: covered by the generic `RESOURCE_OPERATION_PERFORMED` row — see USER_CREATED.
     CoreAuditableEventType["ORGANIZATION_UPDATED"] = "organization_updated";
     CoreAuditableEventType["ORGANIZATION_DELETED"] = "organization_deleted";
+    /** The tenant was MARKED for deletion (soft-delete). Its access dies here; its data dies at the purge. */
+    CoreAuditableEventType["ORGANIZATION_DELETION_REQUESTED"] = "organization_deletion_requested";
+    /** A pending tenant deletion was cancelled inside the retention window. */
+    CoreAuditableEventType["ORGANIZATION_RESTORED"] = "organization_restored";
+    /** The tenant was administratively HALTED. Confers no authority while suspended. */
+    CoreAuditableEventType["ORGANIZATION_SUSPENDED"] = "organization_suspended";
+    /** A halted or expired tenant was returned to normal operation. */
+    CoreAuditableEventType["ORGANIZATION_ACTIVATED"] = "organization_activated";
+    /**
+     * A governed lifecycle transition changed a subject's `status` — membership suspension and
+     * reactivation, administrative user suspension, self-service account deactivation.
+     *
+     * ONE event type rather than five near-identical ones, because the five verbs it serves share an
+     * identical data shape: a subject, a from→to status pair, an optional caller reason, and an
+     * optional automatic-reactivation deadline. `resourceType` + `operationIdentifier` fully
+     * discriminate which verb ran, so splitting would produce five schemas differing only in their
+     * literal and force a reviewer asking "show me every suspension" to union five queries.
+     *
+     * Deliberately distinct from {@link ORGANIZATION_SUSPENDED} / {@link ORGANIZATION_ACTIVATED},
+     * which are NOT collapsed into this: tenant transitions carry domain facts these do not
+     * (`revokedUserTypeCount` / `regrantedUserTypeCount` — the platform-wide reach of halting a
+     * tenant), so they are genuinely different events rather than the same event on another resource.
+     */
+    CoreAuditableEventType["RESOURCE_STATUS_TRANSITION_PERFORMED"] = "resource_status_transition_performed";
     // Organization Member Events
+    // audit-event-unemitted: covered by the generic `RESOURCE_OPERATION_PERFORMED` row — see USER_CREATED.
     CoreAuditableEventType["ORGANIZATION_MEMBER_INVITED"] = "organization_member_invited";
+    // audit-event-unemitted: covered by the generic `RESOURCE_OPERATION_PERFORMED` row — see USER_CREATED.
     CoreAuditableEventType["ORGANIZATION_MEMBER_JOINED"] = "organization_member_joined";
+    // audit-event-unemitted: covered by the generic `RESOURCE_OPERATION_PERFORMED` row — see USER_CREATED.
     CoreAuditableEventType["ORGANIZATION_MEMBER_UPDATED"] = "organization_member_updated";
     CoreAuditableEventType["ORGANIZATION_MEMBER_ROLE_CHANGED"] = "organization_member_role_changed";
+    // audit-event-unemitted: covered by the generic `RESOURCE_OPERATION_PERFORMED` row — see USER_CREATED.
     CoreAuditableEventType["ORGANIZATION_MEMBER_STATUS_CHANGED"] = "organization_member_status_changed";
     CoreAuditableEventType["ORGANIZATION_MEMBER_REMOVED"] = "organization_member_removed";
+    // audit-event-unemitted: covered by the generic `RESOURCE_OPERATION_PERFORMED` row — see USER_CREATED.
     CoreAuditableEventType["ORGANIZATION_NOTIFICATIONS_UPDATED"] = "organization_notifications_updated";
+    // audit-event-unemitted: covered by the generic `RESOURCE_OPERATION_PERFORMED` row — see USER_CREATED.
     CoreAuditableEventType["ORGANIZATION_PREFERENCES_UPDATED"] = "organization_preferences_updated";
+    // audit-event-unemitted: covered by the generic `RESOURCE_OPERATION_PERFORMED` row — see USER_CREATED.
     CoreAuditableEventType["ORGANIZATION_PROFILE_UPDATED"] = "organization_profile_updated";
+    // audit-event-unemitted: covered by the generic `RESOURCE_OPERATION_PERFORMED` row — see USER_CREATED.
     CoreAuditableEventType["ORGANIZATION_UNIT_UPDATED"] = "organization_unit_updated";
+    // Per-unit role assignment — the NARROWED twin of ORGANIZATION_MEMBER_ROLE_CHANGED.
+    // `OrganizationUnitMember.role` became live authority when `appendUnitScopedRoles` began emitting
+    // it into `initiatorRoles` as a unit-narrowed entry, so assigning or re-assigning it is an
+    // access-control decision on the same footing as the organization-wide array — it just confers
+    // inside ONE unit rather than across the tenant. Distinct from ORGANIZATION_UNIT_UPDATED, which is
+    // ORG_MANAGEMENT record-keeping about the unit itself and confers nothing.
+    // assurance-control: WILDO.ACCESS.PRIVILEGE_EVIDENCE — evidence of privilege grant/revocation.
+    CoreAuditableEventType["ORGANIZATION_UNIT_MEMBER_ROLE_CHANGED"] = "organization_unit_member_role_changed";
+    // Revocation of a per-unit role assignment — the closing half of
+    // ORGANIZATION_UNIT_MEMBER_ROLE_CHANGED. Deleting an assignment row IS the revocation: the row
+    // exists only to confer a role, so unlike ORGANIZATION_MEMBER_REMOVED (where losing authority is a
+    // consequence of leaving the directory) there is no non-authorization reading of this event.
+    // Without it the trail shows unit privileges being granted and never removed.
+    // assurance-control: WILDO.ACCESS.PRIVILEGE_EVIDENCE — evidence of privilege revocation.
+    CoreAuditableEventType["ORGANIZATION_UNIT_MEMBER_REMOVED"] = "organization_unit_member_removed";
     // SSO Authentication Events
     CoreAuditableEventType["USER_SSO_LOGIN"] = "user_sso_login";
     CoreAuditableEventType["USER_SSO_LOGIN_FAILED"] = "user_sso_login_failed";
@@ -38,7 +155,28 @@ export var CoreAuditableEventType;
     // Organization Security Management Events
     CoreAuditableEventType["ORGANIZATION_SSO_CONFIGURATION_CHANGED"] = "organization_sso_configuration_changed";
     CoreAuditableEventType["ORGANIZATION_SIEM_EXPORT_CONFIGURED"] = "organization_siem_export_configured";
+    // Application Security Configuration Events
+    // The per-user-type authentication policy (`userTypes.<type>.auth` — MFA, password, and lockout
+    // requirements) is STATIC application configuration authored in code and taken into effect at
+    // backend startup. A change to it — most consequentially a WEAKENING such as turning MFA off — is
+    // a security-posture decision that otherwise leaves no product-side record (only source history).
+    // Emitted at boot, by the system, when the resolved policy snapshot differs from the last one the
+    // trail recorded for the application. Distinct from ORGANIZATION_SSO_CONFIGURATION_CHANGED, which
+    // is a per-tenant runtime edit by a human admin; this is the application-wide authored baseline
+    // and has no human actor at boot (the "who" lives in the deployment/source history).
+    // assurance-control: WILDO.IDENTITY.SESSION_ASSURANCE — a change to the authentication assurance
+    // requirements (MFA / password / lockout) must be attributable and evidenced.
+    CoreAuditableEventType["APPLICATION_AUTH_POLICY_CHANGED"] = "application_auth_policy_changed";
+    // Outbound M2M Webhook Events
+    // An admin firing `webhookConfig.testEndpoint` makes the platform emit a signed HTTP
+    // request to an operator-supplied URL. That is an outbound-traffic primitive reachable
+    // from an authenticated admin surface, so every attempt — reachable or not — is recorded
+    // with the actor, the scope, and the destination host.
+    // assurance-control: WILDO.INTEGRATION.OUTBOUND_ACTIVITY_AUDIT — outbound connection initiated from an
+    // administrative surface is attributable and monitorable.
+    CoreAuditableEventType["WEBHOOK_ENDPOINT_TEST_DISPATCHED"] = "webhook_endpoint_test_dispatched";
     // SCIM Directory Provisioning Events
+    // audit-event-unemitted: covered by the generic `RESOURCE_OPERATION_PERFORMED` row — see USER_CREATED.
     CoreAuditableEventType["SCIM_TOKEN_CREATED"] = "scim_token_created";
     CoreAuditableEventType["SCIM_TOKEN_REVOKED"] = "scim_token_revoked";
     CoreAuditableEventType["SCIM_TOKEN_GENERATED"] = "scim_token_generated";
@@ -51,6 +189,15 @@ export var CoreAuditableEventType;
     // Password Reset Events (H5)
     CoreAuditableEventType["USER_PASSWORD_RESET_REQUESTED"] = "user_password_reset_requested";
     CoreAuditableEventType["USER_PASSWORD_RESET_COMPLETED"] = "user_password_reset_completed";
+    /**
+     * An ADMINISTRATOR compelled a credential reset on another user's account.
+     *
+     * Deliberately distinct from `USER_PASSWORD_RESET_REQUESTED`, which records a SELF-SERVICE
+     * request and carries no actor: reusing it for an admin action would attribute the reset to
+     * the account owner, so the audit trail would name the wrong human for a privileged act. This
+     * event names both the actor and the target, and records the operator's documented reason.
+     */
+    CoreAuditableEventType["USER_PASSWORD_RESET_FORCED"] = "user_password_reset_forced";
     // Registration & Verification Events (H5)
     CoreAuditableEventType["USER_REGISTERED"] = "user_registered";
     CoreAuditableEventType["USER_EMAIL_VERIFIED"] = "user_email_verified";
@@ -94,11 +241,248 @@ export var CoreAuditableEventType;
     // One-Off Session Events (W7.3b)
     CoreAuditableEventType["ONE_OFF_TOKEN_CREATED"] = "one_off_token_created";
     CoreAuditableEventType["ONE_OFF_TOKEN_EXCHANGED"] = "one_off_token_exchanged";
+    /** revocation-B1: a super-admin cancelled an un-exchanged one-off (impersonation) session token. */
+    CoreAuditableEventType["ONE_OFF_TOKEN_REVOKED"] = "one_off_token_revoked";
+    // Cross-Frontend Handoff Events (cross-app-jwt-propagation Step 2)
+    CoreAuditableEventType["USER_CROSS_FRONTEND_HANDOFF_ISSUED"] = "user_cross_frontend_handoff_issued";
     // Emergency Access Events
     CoreAuditableEventType["EMERGENCY_ACCESS_USED"] = "emergency_access_used";
     // Field Access Events
     CoreAuditableEventType["FIELD_ACCESS"] = "field_access";
+    // Resource-Operation Events — the OPERATION-triggered twin of FIELD_ACCESS.
+    //
+    // FIELD_ACCESS answers "a decorated field left the system"; it is triggered by a RESPONSE FIELD,
+    // so an operation whose response carries no decorated field is invisible to it. Repo-wide, that
+    // trigger is declared on FOUR fields (three secret families, CREATE-only), which left every other
+    // operation in an 83-resource catalogue emitting nothing at all — including role changes,
+    // suspensions, credential deletion and tenant deletion.
+    //
+    // This event answers the different question: "this OPERATION was performed, by whom, on what,
+    // with what effect". It is emitted for every HIGH / CRITICAL operation variant automatically
+    // (`riskLevel` is already the framework's canonical danger axis — it drives MCP destructive
+    // hints, frontend danger-zone placement and CRITICAL typed-confirmation), and for any variant
+    // that opts in declaratively via `auditableEvent`.
+    //
+    // It is the FLOOR beneath the purpose-built events, never their replacement: a verb with its own
+    // event (e.g. USER_APP_ROLES_CHANGED, which carries the `requestedRoles` set the role-ceiling
+    // gate was measured against — something a generic before/after diff cannot reconstruct) emits
+    // that one and suppresses this.
+    //
+    // assurance-control: WILDO.AUDIT.SECURITY_EVENT — privileged actions on
+    // resources are attributable, and the authorization effect of each is reconstructable.
+    CoreAuditableEventType["RESOURCE_OPERATION_PERFORMED"] = "resource_operation_performed";
+    // The REFUSAL twin of RESOURCE_OPERATION_PERFORMED — the other half of "record access decisions".
+    //
+    // Emitted PRE-DISPATCH from the authorizer, not from the post-commit lane, because a refused
+    // operation never reaches that lane. Without this event a refused HIGH/CRITICAL action — a denied
+    // role change, a blocked suspension, a rejected credential rotation — leaves NO evidence at all,
+    // so an auditor cannot distinguish "nobody attempted it" from "someone attempted it and was
+    // stopped". Repeated denials are also the signature of an attack in progress.
+    //
+    // ## Not an authentication failure
+    //
+    // USER_LOGIN_FAILED / MACHINE_AUTH_FAILED answer "you are not who you claim to be" (AUTHENTICATION).
+    // This answers "you are who you claim to be, and you may not do this" (AUTHORIZATION). The two are
+    // deliberately distinct event types in distinct categories; neither is overloaded onto the other.
+    //
+    // ## No risk floor, unlike the success twin
+    //
+    // RESOURCE_OPERATION_PERFORMED fires only at HIGH/CRITICAL because a SUCCESSFUL low-risk read is
+    // routine business (371 of the 551 API-reachable variants are reads). A DENIED read is never
+    // routine — it is the canonical reconnaissance signal. A risk floor here would exclude 100% of
+    // denied reads while not bounding attacker volume at all (the attacker picks the endpoint, so a
+    // HIGH verb is exactly as cheap to hammer as a LOW one). Volume is bounded by per-principal
+    // dedup instead — see `AuditableEvent_ResourceOperationDenied_EventDataSchema`.
+    //
+    // Severity is WARNING, matching its AUTHENTICATION twins rather than varying with `riskLevel`:
+    // severity is a pure function of event type everywhere in this map (and is re-derived
+    // independently by the SIEM dispatcher), so danger grading rides the row's `riskLevel` field.
+    //
+    // assurance-control: WILDO.ACCESS.AUTHORIZATION_DECISION_AUDIT — access-control decisions are
+    // recorded, including the negative decisions, and repeated refusals are detectable.
+    CoreAuditableEventType["RESOURCE_OPERATION_DENIED"] = "resource_operation_denied";
+    CoreAuditableEventType["CROSS_TENANT_ADMINISTRATIVE_ACCESS"] = "cross_tenant_administrative_access";
+    CoreAuditableEventType["PLATFORM_ACCESS_GRANT_LIFECYCLE"] = "platform_access_grant_lifecycle";
+    /**
+     * An operator enumerated an APPLICATION-WIDE directory — a collection read that is deliberately
+     * not confined to any one tenant.
+     *
+     * ## Why this is not {@link CROSS_TENANT_ADMINISTRATIVE_ACCESS}
+     *
+     * That event answers "an operator reached a ROW belonging to a tenant they are not a member of",
+     * and it is emitted after comparing a FETCHED row's organization against the caller's role
+     * entries. A directory read has no row and no target tenant — the whole point is that it spans
+     * all of them — so there is nothing for that comparison to consume. Merging the two would put
+     * two different questions behind one event type and make the existing one's `targetOrganizationId`
+     * meaningless on half its rows. Closed vocabularies do not merge.
+     *
+     * ## Why it exists at all
+     *
+     * The reach is INTENDED and declared (`users | list | admin` is documented as "admin-gated global
+     * user listing"), and it cannot be governed by the platform-access-grant mechanism: that admission
+     * requires a usable grant for a TARGET tenant, and a collection call has none. So prevention is
+     * structurally unavailable and EVIDENCE is the control that remains — which is exactly what
+     * `.claude/rules/administrative-continuity-floors.md` asks for on a sanctioned reach: "every
+     * crossing is NAMED in the trail". Before this event, an operator could enumerate every user's
+     * email across every tenant and leave nothing behind.
+     *
+     * INFO, not WARNING: unlike its cross-tenant sibling this is an ordinary, expected administrative
+     * read on a surface built for it. The subset worth escalating is selected by a SIEM rule on
+     * `resourceType` + `returnedCount`, both of which ride the payload.
+     *
+     * assurance-control: WILDO.ACCESS.AUTHORIZATION_DECISION_AUDIT — an unconfined administrative read
+     * of application-wide data is recorded with its actor, surface and size.
+     */
+    CoreAuditableEventType["PLATFORM_DIRECTORY_ACCESS"] = "platform_directory_access";
+    // System-Context (ACL-bypassing) Access Events
+    // Emitted whenever a server-internal `readAsSystem` / `listAsSystem` call
+    // reads a resource with a synthesised super-admin context, bypassing the
+    // caller's scope + role ACL. Classified by default as DATA_ACCESS / INFO
+    // (an expected, authorized internal read — not an anomaly).
+    // USERLESS BUT NOT UNATTRIBUTED (since 2026-07-31): there is no human to name —
+    // the door synthesises its own super-admin context — but `eventData.performedByRuntime`
+    // records WHICH RUNTIME exercised it (the application backend, a named minion, …).
+    // Without that, a cross-tenant read by a background digital worker is indistinguishable
+    // from a data seed or a lifecycle batch. Runtime attribution is deliberately a weaker,
+    // honest claim than user attribution and must never be read as one.
+    CoreAuditableEventType["SYSTEM_CONTEXT_READ"] = "system_context_read";
+    // The MUTATION twin: emitted whenever a server-internal `createAsSystem` /
+    // `updateAsSystem` / `updateManyAsSystem` call writes a resource with a
+    // synthesised super-admin context, bypassing the caller's scope + role ACL
+    // (e.g. registration persisting credentials). A MUTATION under an ACL bypass
+    // is more sensitive than a read, so it is audited as its own distinct event
+    // rather than folded into SYSTEM_CONTEXT_READ.
+    CoreAuditableEventType["SYSTEM_CONTEXT_WRITE"] = "system_context_write";
+    // Retained-Data (Impersonalization) Access Events
+    // Emitted when a privileged SEE-THROUGH read reveals RETAINED (impersonalized-and-retained) records
+    // that the default retention hide-predicate keeps hidden. SYSTEM_CONTEXT_READ names only the RUNTIME
+    // that acted; this read is HUMAN-ATTRIBUTED (a super-admin / COMPLIANCE_AUDITOR) and carries a REQUIRED reason —
+    // a compliance-grade access record over scrubbed personal data. Strictly read-only. Classified
+    // DATA_ACCESS / WARNING (an authorized-but-elevated privileged access, not an anomaly ⇒ not CRITICAL).
+    CoreAuditableEventType["RETAINED_DATA_ACCESS"] = "retained_data_access";
+    // A DATA SUBJECT EXPORT was assembled and handed out — everything the framework holds about one
+    // person, gathered across their whole relationship graph (GDPR Art. 15 access / Art. 20
+    // portability). Deliberately NOT folded into SYSTEM_CONTEXT_READ: that event names only the
+    // RUNTIME that acted and carries no notion of a subject, a purpose, or what a bundle contained,
+    // so it cannot answer the question a regulator actually asks — "who exported whose data, when,
+    // and what was in it?". The four routed export operations this capability replaced emitted
+    // NOTHING at all, which is the gap this closes. Classified DATA_ACCESS / WARNING: an authorized
+    // but maximally-sensitive disclosure, not an anomaly.
+    CoreAuditableEventType["SUBJECT_DATA_EXPORT"] = "subject_data_export";
+    // A resource LISTING was exported to a file (CSV/JSON) by an operator. Distinct from
+    // SUBJECT_DATA_EXPORT, which answers a data subject's own right over their own data: this one is
+    // an authorized operator taking rows they can already read and carrying them OUT of the system, so
+    // the questions it must answer are "which resource, how many rows, and was it the page they were
+    // looking at or the whole table". Classified DATA_ACCESS / INFO with a per-emit `riskLevel` — see
+    // the eventData schema for why the severity is static and the risk is not.
+    CoreAuditableEventType["COLLECTION_DATA_EXPORT"] = "collection_data_export";
+    // Rows were read THROUGH an HTTP-API resource binding — data left an EXTERNAL system
+    // (an enterprise's Odoo/SAP/…) via the engine's read-through repository (ETL plan, D8/R6).
+    // Deliberately NOT folded into the neighbors: SYSTEM_CONTEXT_READ names a runtime acting on
+    // WILDO-owned rows and knows nothing of a foreign system; COLLECTION_DATA_EXPORT is rows
+    // CARRIED OUT of the system by an operator, while this is rows BROUGHT IN from a system the
+    // platform does not own — the question a reviewer asks is "who reached into which external
+    // system, through which provider, for which entity, and how much came back". Attribution
+    // carries the REAL initiating user even under a SERVICE_PRINCIPAL binding (R12 — the
+    // credential-sharing-as-a-service failure this vocabulary exists to prevent). One event per
+    // read-family OPERATION execution (a paginated list and its count are ONE access), emitted at
+    // the adapter — the only tier that witnesses EVERY remote access, including repository-direct
+    // probes the services tier never sees. Classified DATA_ACCESS / INFO: routine, authorized
+    // operation — the value is the queryable trail, not an alarm.
+    CoreAuditableEventType["HTTP_API_READ_THROUGH_ACCESS"] = "http_api_read_through_access";
+    // A subject erasure INVOKED the declared external-erasure operation of an HTTP_API-bound
+    // resource (ETL D6 stance 6b) — rows linked to the erased subject were DELETED in a system the
+    // platform does not own (OData canonical DELETE / Odoo `unlink` / a declared REST_JSON call).
+    // The first OUTBOUND WRITE on the read-through plane, landing WITH its mechanism per the D8
+    // narrowing. Distinct from HTTP_API_READ_THROUGH_ACCESS (rows brought IN) and from
+    // SYSTEM_CONTEXT_WRITE (a trusted write to WILDO-owned rows): the reviewer question here is
+    // "which subject's rows were deleted in which external system, through which provider, and how
+    // many". Classified USER_LIFECYCLE / INFO: the sanctioned mechanics of a data-protection
+    // request, not an anomaly — the erasure report is the receipt; this is the queryable trail.
+    CoreAuditableEventType["HTTP_API_EXTERNAL_ERASURE"] = "http_api_external_erasure";
+    // A subject erasure COMPLETED while rows linked to the subject remain LIVE in an HTTP_API-bound
+    // external system, on the controller's explicit per-request acknowledgement (ETL D6 stance 6c,
+    // `acknowledgeHttpApiNonErasure`). The record IS the control (the same doctrine as the two
+    // administrative floors): no downstream check can second-guess a controller acting within GDPR
+    // Art. 17(3) grounds, so what the framework owes is a loud, queryable record of the hole — the
+    // subject, the resource, the provider, and how many rows remained (when countable). Classified
+    // USER_LIFECYCLE / CRITICAL: one event per acknowledged resource per erasure, never a standing
+    // posture.
+    CoreAuditableEventType["HTTP_API_NON_ERASURE_ACKNOWLEDGED"] = "http_api_non_erasure_acknowledged";
+    // ── OAuth2 / OIDC Provider Events (Wildo AS the authorization server) ──
+    // Distinct from the `OAUTH2_*` family above, which records Wildo CONSUMING an
+    // EXTERNAL social OAuth provider. These record the app-issued OAuth2/OIDC provider
+    // surface (`/oauth/authorize`, `/oauth/token`, `/oauth/authorize/decision`,
+    // `/oauth/revoke`) — a third party gaining, or being refused, user-acting access.
+    // Each maps to a Wildo assurance objective at the emit site (`assurance-control:` marker).
+    /** A user-delegated `authorization_code` access token was minted for a third-party client
+     *  (the client may now act AS the user at the bound A2A/MCP resource) — the flagship grant. */
+    CoreAuditableEventType["OAUTH_DELEGATED_TOKEN_ISSUED"] = "oauth_delegated_token_issued";
+    /** A user APPROVED an interactive consent request — the client is authorized for this authorize flow. */
+    CoreAuditableEventType["OAUTH_CONSENT_GRANTED"] = "oauth_consent_granted";
+    /** A user DENIED an interactive consent request — access refused (protective, benign). */
+    CoreAuditableEventType["OAUTH_CONSENT_DENIED"] = "oauth_consent_denied";
+    /** A durable "remember this app" consent grant was created/updated — persistent delegated authority. */
+    CoreAuditableEventType["OAUTH_CONSENT_GRANT_PERSISTED"] = "oauth_consent_grant_persisted";
+    /**
+     * An ANONYMOUS caller created an OAuth client identity through RFC 7591 dynamic registration.
+     * The only write in this application reachable without any credential, so every occurrence is
+     * evidence: the row it creates is durable, and the population of these rows is what an operator
+     * needs to be able to review and revoke.
+     */
+    CoreAuditableEventType["OAUTH_DYNAMIC_CLIENT_REGISTERED"] = "oauth_dynamic_client_registered";
+    /**
+     * A URL-formatted `client_id` (CIMD) was REFUSED at the authorize endpoint.
+     *
+     * Auditable because the refusal reasons are not all equal: `HOST_NOT_ALLOWED` is a
+     * misconfiguration, while `SSRF_TARGET_REFUSED` is an unauthenticated stranger trying to make
+     * this server fetch an address only it can reach. Both arrive at the same endpoint from the same
+     * kind of caller, so only the reason distinguishes them — and a spike in either is a thing an
+     * operator must be able to alert on.
+     */
+    CoreAuditableEventType["OAUTH_CIMD_CLIENT_REFUSED"] = "oauth_cimd_client_refused";
+    /** A user token was rotated via the provider `refresh_token` grant (`/oauth/token`). */
+    CoreAuditableEventType["OAUTH_TOKEN_REFRESHED"] = "oauth_token_refreshed";
+    /** A token was revoked via `/oauth/revoke` (RFC 7009). */
+    CoreAuditableEventType["OAUTH_TOKEN_REVOKED"] = "oauth_token_revoked";
+    /** An OIDC RP-Initiated Logout terminated the End-User's OP session at `/oauth/end-session`
+     *  (revocation-C). Distinct from `USER_LOGOUT` (first-party self-logout) and `OAUTH_TOKEN_REVOKED`
+     *  (RFC 7009 token revocation): this ends a SESSION on a relying party's behalf. */
+    CoreAuditableEventType["OAUTH_RP_INITIATED_LOGOUT"] = "oauth_rp_initiated_logout";
+    /** An `authorization_code` exchange was REJECTED (replay / PKCE failure / redirect mismatch / …) —
+     *  a potential attack signal. The specific cause rides `eventData.reason`. */
+    CoreAuditableEventType["OAUTH_CODE_EXCHANGE_FAILED"] = "oauth_code_exchange_failed";
+    /** A consent DECISION was attempted by a user who is NOT the consent request's bound user (403) —
+     *  a textbook cross-user authorization-abuse signal. */
+    CoreAuditableEventType["OAUTH_CONSENT_BINDING_VIOLATION"] = "oauth_consent_binding_violation";
+    /** Refresh-token REUSE detected → the whole token family was revoked (possible theft). Emitted by the
+     *  refresh CALLERS (the token issuer stays audit-free by design — it surfaces a reuse signal instead). */
+    CoreAuditableEventType["USER_REFRESH_TOKEN_REUSE_DETECTED"] = "user_refresh_token_reuse_detected";
 })(CoreAuditableEventType || (CoreAuditableEventType = {}));
+/**
+ * Closed vocabulary of `OAUTH_CODE_EXCHANGE_FAILED` failure causes (RFC 6749 / OAuth 2.1 / RFC 7636).
+ * A dedicated enum (not an inline literal union) so the emit sites, the schema, and any SIEM
+ * consumer share one runtime source — the project's closed-vocabulary rule.
+ */
+export var OAuthCodeExchangeFailureReason;
+(function (OAuthCodeExchangeFailureReason) {
+    /** The single-use code did not atomically consume — replayed, expired, or never issued. */
+    OAuthCodeExchangeFailureReason["CODE_REPLAY_OR_INVALID"] = "code_replay_or_invalid";
+    /** The consumed token was of a different consumable-token type (not an authorization code). */
+    OAuthCodeExchangeFailureReason["NOT_AUTHORIZATION_CODE"] = "not_authorization_code";
+    /** The decoded code carried no subject (userId). */
+    OAuthCodeExchangeFailureReason["NO_SUBJECT"] = "no_subject";
+    /** The redeeming `client_id` differs from the client the code was issued to. */
+    OAuthCodeExchangeFailureReason["CLIENT_MISMATCH"] = "client_mismatch";
+    /** The redeeming `redirect_uri` differs from the one bound at authorize. */
+    OAuthCodeExchangeFailureReason["REDIRECT_URI_MISMATCH"] = "redirect_uri_mismatch";
+    /** The PKCE `code_verifier` failed the bound S256 challenge (or was malformed). */
+    OAuthCodeExchangeFailureReason["PKCE_VERIFICATION_FAILED"] = "pkce_verification_failed";
+    /** The client was deactivated between authorize and redemption (redemption-window re-check). */
+    OAuthCodeExchangeFailureReason["CLIENT_INACTIVE"] = "client_inactive";
+    /** The client lost the `authorization_code` grant between authorize and redemption. */
+    OAuthCodeExchangeFailureReason["GRANT_TYPE_LOST"] = "grant_type_lost";
+})(OAuthCodeExchangeFailureReason || (OAuthCodeExchangeFailureReason = {}));
 /** Canonical event categories — used by auditable-events, security-envelope, audit-logs. */
 export var AuditEventCategory;
 (function (AuditEventCategory) {
@@ -115,12 +499,68 @@ export var AuditEventSeverity;
     AuditEventSeverity["WARNING"] = "warning";
     AuditEventSeverity["CRITICAL"] = "critical";
 })(AuditEventSeverity || (AuditEventSeverity = {}));
-/** SSO connection type — shared with user-identity-links. */
-export var SsoConnectionType;
-(function (SsoConnectionType) {
-    SsoConnectionType["SOCIAL"] = "social";
-    SsoConnectionType["ENTERPRISE"] = "enterprise";
-})(SsoConnectionType || (SsoConnectionType = {}));
+/**
+ * Why the authorizer refused an operation. A CLOSED vocabulary — the authorizer resolves exactly
+ * one of these per refusal, and a SOC dashboard groups by it.
+ *
+ * The distinction that matters most operationally is {@link SUBJECT_NOT_RESOLVABLE} vs. the rest:
+ * every other member is a caller who reached a real, visible row and was refused on roles or scope,
+ * whereas that one is a caller who named a row they cannot see at all — the shape of tenant
+ * enumeration.
+ */
+export var ResourceOperationDenialReason;
+(function (ResourceOperationDenialReason) {
+    /**
+     * No initiator identity or roles on the execution context. Fail-closed: the authorizer refuses
+     * rather than assuming an anonymous caller.
+     *
+     * **A backstop, not a live path — verified.** The execution context fails closed earlier and
+     * harder: every execution type that reaches the authorizer refuses to CONSTRUCT without
+     * `initiatorIds`, and the one type that permits null (`WEBHOOK_CALLBACK`) is skipped before the
+     * guard, since signature verification already established trust. The roles half cannot fire
+     * either — the context spreads `initiatorRoles`, so the only accepted value is an array.
+     *
+     * A row carrying this reason therefore means something bypassed context construction. Treat it as
+     * a defect signal, not routine refusal traffic.
+     */
+    ResourceOperationDenialReason["MISSING_INITIATOR"] = "missing_initiator";
+    /**
+     * The caller's organization-wide roles did not satisfy the operation's required role set, after
+     * role-hierarchy expansion. The everyday "you are not an admin" refusal.
+     */
+    ResourceOperationDenialReason["INSUFFICIENT_ROLES"] = "insufficient_roles";
+    /**
+     * The caller was refused against the target row's PRIMARY SCOPE — the row belongs to another
+     * user, organization or application than the caller is entitled to. Distinct from
+     * {@link INSUFFICIENT_ROLES}: the caller may hold the right role, but in the wrong tenant.
+     */
+    ResourceOperationDenialReason["SCOPE_MISMATCH"] = "scope_mismatch";
+    /**
+     * The caller reached the resource through a foreign-key path (`/assigned-to-users/{userId}/todos`)
+     * whose owning entity they do not control.
+     */
+    ResourceOperationDenialReason["FK_RELATIONSHIP_DENIED"] = "fk_relationship_denied";
+    /**
+     * A collection operation was refused on its PARENT scope — the caller has no access to the
+     * organization / application whose collection they addressed.
+     */
+    ResourceOperationDenialReason["PARENT_SCOPE_DENIED"] = "parent_scope_denied";
+    /**
+     * The named row could not be resolved for the caller: it does not exist, OR it exists and is
+     * invisible to the caller's scope. The authorizer **cannot distinguish these two** — and that is
+     * deliberate, because reporting them differently would leak the existence of out-of-scope rows.
+     * The refusal surfaces to the caller as NOT_FOUND (404) and that response is unchanged by this
+     * event; only the audit trail records that a refusal occurred.
+     *
+     * Consequently this reason is AMBIGUOUS BY CONSTRUCTION and a single occurrence proves nothing —
+     * a 404 for a genuinely deleted record lands here too. Its value is in the aggregate: a principal
+     * accumulating these against ids they never successfully read is enumerating.
+     *
+     * assurance-control: WILDO.ACCESS.AUTHORIZATION_DECISION_AUDIT — refusals are recorded without the record itself
+     * becoming an existence oracle.
+     */
+    ResourceOperationDenialReason["SUBJECT_NOT_RESOLVABLE"] = "subject_not_resolvable";
+})(ResourceOperationDenialReason || (ResourceOperationDenialReason = {}));
 /** SSO configuration change type. */
 export var SsoConfigChangeType;
 (function (SsoConfigChangeType) {
@@ -138,6 +578,56 @@ export var SiemExportChangeType;
     SiemExportChangeType["DISABLED"] = "disabled";
     SiemExportChangeType["UPDATED"] = "updated";
 })(SiemExportChangeType || (SiemExportChangeType = {}));
+/**
+ * Normalised MACHINE_ACCESS operation vocabulary. Transport-native method names (A2A JSON-RPC
+ * `message/send`, MCP `tools/call`, …) are mapped to these stable, transport-prefixed audit
+ * identifiers so an org SIEM reads ONE vocabulary across every external resource-server surface.
+ * The `<transport>_<method>` shape keeps A2A and MCP operations disambiguated in a flat stream.
+ */
+export var MachineAccessOperation;
+(function (MachineAccessOperation) {
+    MachineAccessOperation["A2A_MESSAGE_SEND"] = "a2a_message_send";
+    MachineAccessOperation["A2A_MESSAGE_STREAM"] = "a2a_message_stream";
+    /** Reading one task's state. Externally triggered and tenant-actionable, so it audits. */
+    MachineAccessOperation["A2A_TASKS_GET"] = "a2a_tasks_get";
+    /** Requesting cancellation of a task — a MUTATION of tenant work, audited as such. */
+    MachineAccessOperation["A2A_TASKS_CANCEL"] = "a2a_tasks_cancel";
+    /**
+     * Re-attaching to a task's update stream after a dropped connection.
+     *
+     * Audited like `A2A_TASKS_GET` and for the same reason: it is a READ of tenant work by an external
+     * principal. It deserves its own member rather than borrowing the get — a resubscribe holds a
+     * connection open for as long as the task runs, so in a trail the two have very different shapes,
+     * and collapsing them would hide a caller camping on a stream behind ordinary polling.
+     */
+    MachineAccessOperation["A2A_TASKS_RESUBSCRIBE"] = "a2a_tasks_resubscribe";
+    /**
+     * Registering a webhook the agent will POST this task's updates to.
+     *
+     * The most security-relevant of the push-notification operations and the reason all four get their
+     * own members: the caller is directing OUR server to make outbound requests to an address IT
+     * chooses, carrying credentials IT supplies. In a trail that is a different act from reading a
+     * task, and an operator reviewing egress needs to find every one of them without inferring it from
+     * a generic access row.
+     */
+    MachineAccessOperation["A2A_PUSH_NOTIFICATION_CONFIG_SET"] = "a2a_push_notification_config_set";
+    /** Reading back one registered webhook target. Secrets are redacted, but the URL is disclosed. */
+    MachineAccessOperation["A2A_PUSH_NOTIFICATION_CONFIG_GET"] = "a2a_push_notification_config_get";
+    /** Enumerating every webhook target registered against a task. */
+    MachineAccessOperation["A2A_PUSH_NOTIFICATION_CONFIG_LIST"] = "a2a_push_notification_config_list";
+    /** Removing a webhook target — a MUTATION, and the act that silently stops an operator's alerting. */
+    MachineAccessOperation["A2A_PUSH_NOTIFICATION_CONFIG_DELETE"] = "a2a_push_notification_config_delete";
+    /**
+     * Enumerating an owner's tasks (A2A 1.0 `ListTasks`).
+     *
+     * Its own member rather than borrowing `A2A_TASKS_GET`: a LIST discloses the existence and shape
+     * of work the caller did not name, which in a trail is a different act from reading one task an
+     * operator already knows about. Collapsing them would hide enumeration behind ordinary polling.
+     */
+    MachineAccessOperation["A2A_TASKS_LIST"] = "a2a_tasks_list";
+    MachineAccessOperation["MCP_TOOLS_LIST"] = "mcp_tools_list";
+    MachineAccessOperation["MCP_TOOLS_CALL"] = "mcp_tools_call";
+})(MachineAccessOperation || (MachineAccessOperation = {}));
 export const AuditableEventTypeSchema = z.union([
     z.enum(CoreAuditableEventType),
     z.string()
@@ -167,6 +657,18 @@ export const AuditableEvent_User_LoginFailedEventDataSchema = z.object({
     attemptsRemaining: z.number().optional(),
     sessionId: z.string(),
 });
+/**
+ * Which lockout mechanism tripped a `USER_ACCOUNT_LOCKED` audit — so a SOC can distinguish the two
+ * sources, which have different remediation: the per-SESSION progressive failed-attempt limit vs the
+ * per-EMAIL global rate-limit. Enum (fixed vocabulary), not a string union, per the project rule.
+ */
+export var AccountLockoutReason;
+(function (AccountLockoutReason) {
+    /** The per-session progressive failed-attempt limit tripped (`incrementSessionAttempts`). */
+    AccountLockoutReason["SESSION_ATTEMPT_LIMIT"] = "session_attempt_limit";
+    /** The per-email GLOBAL rate-limit lockout tripped (`checkRateLimit(GLOBAL_LOCKOUT + email)`). */
+    AccountLockoutReason["GLOBAL_EMAIL_RATE_LIMIT"] = "global_email_rate_limit";
+})(AccountLockoutReason || (AccountLockoutReason = {}));
 export const AuditableEvent_User_AccountLockedEventDataSchema = z.object({
     eventType: z.literal(CoreAuditableEventType.USER_ACCOUNT_LOCKED),
     userId: z.string(),
@@ -176,6 +678,93 @@ export const AuditableEvent_User_AccountLockedEventDataSchema = z.object({
     ipAddress: z.string(),
     userAgent: z.string(),
     sessionId: z.string(),
+    /**
+     * Which lockout mechanism tripped this event. OPTIONAL for backward compatibility — pre-existing
+     * emitters and already-stored rows may omit it; new emitters set it so SOC tooling can filter
+     * session-limit vs global-email-limit lockouts.
+     */
+    reason: z.enum(AccountLockoutReason).optional(),
+});
+/**
+ * A machine principal (api-key / OAuth-client secret / exchanged client-credentials token) that
+ * successfully authenticated. Carries the credential PROVENANCE — never the raw secret. Emitted at
+ * the OAuth token-issuance moment (`/oauth/token`); per-request direct-secret access additionally
+ * carries this provenance into any FIELD_ACCESS audit row (see `audit-access-fields`).
+ */
+export const AuditableEvent_MachineAuth_SuccessEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.MACHINE_AUTH_SUCCESS),
+    /** MachineAuthMethod value: `api_key` | `oauth_client`. */
+    authMethod: z.string(),
+    /** The ApiKey / OAuthClient row `_id` that authenticated — NEVER the raw secret. */
+    credentialId: z.string(),
+    /** Resolved machine execution type: `organization_machine` | `application_machine`. */
+    scopeType: z.string(),
+    /** organizationId (ORG machine) or applicationId (APP machine). */
+    scopeId: z.string().optional(),
+    resourceIdentifier: z.string().optional(),
+    operationIdentifier: z.string().optional(),
+    ipAddress: z.string().optional(),
+});
+/**
+ * A rejected machine-credential presentation (bad/expired/wrong-audience/wrong-scope secret or
+ * token, or a rate-limited source). Records the ATTEMPT — the presented credential kind + prefix,
+ * the target scope, and the reason — never a `credentialId` (the credential did not resolve). The
+ * per-source-IP brute-force signal (external-access hardening) is exactly this event stream.
+ */
+export const AuditableEvent_MachineAuth_FailedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.MACHINE_AUTH_FAILED),
+    /** Presented credential kind: `api_key` | `oauth_client` | `machine_token`. */
+    credentialKind: z.string(),
+    /** Human-routable secret prefix (e.g. `sk_org_` / `oc_app_`) — NEVER the full secret. Absent for token fronts. */
+    credentialPrefix: z.string().optional(),
+    /** Failure reason (e.g. `invalid_credential`, `inactive`, `aud_mismatch`, `wrong_scope`, `rate_limited`). */
+    reason: z.string(),
+    scopeType: z.string().optional(),
+    scopeId: z.string().optional(),
+    resourceIdentifier: z.string().optional(),
+    operationIdentifier: z.string().optional(),
+    ipAddress: z.string().optional(),
+});
+/**
+ * A machine principal (ORGANIZATION_MACHINE / APPLICATION_MACHINE) exercised an external
+ * resource-server surface (A2A `message/send`, MCP `tools/call`, …) with an already-issued,
+ * audience-bound token. The token-USE twin of MACHINE_AUTH_SUCCESS (token-MINT): the mint fires
+ * once, low-volume, at `/oauth/token`; THIS fires per external request so an org SIEM sees WHAT a
+ * machine did, not merely that it authenticated.
+ *
+ * Carries the credential PROVENANCE (authMethod + credentialId — never the raw secret), the ROLE
+ * context that authorized the access (roles are the single authorization axis — there is NO OAuth
+ * authorization-scope vocabulary), and the resource server + operation targeted. Emitted fire-and-
+ * forget at the A2A / MCP controller boundary AFTER the caller is authenticated + authorized; routed
+ * to the org SIEM via `routingOrgIds` (verified org for an ORGANIZATION_MACHINE; an
+ * APPLICATION_MACHINE has no single tenant SIEM ⇒ no per-org dispatch).
+ */
+export const AuditableEvent_MachineAccess_EventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.MACHINE_ACCESS),
+    /** MachineAuthMethod value: `api_key` | `oauth_client`. */
+    authMethod: z.string(),
+    /** The ApiKey / OAuthClient row `_id` whose token was presented — NEVER the raw secret. */
+    credentialId: z.string(),
+    /** Resolved machine execution type: `organization_machine` | `application_machine`. */
+    scopeType: z.string(),
+    /**
+     * TENANT scope id: organizationId (ORG machine) or applicationId (APP machine). This is the
+     * data-partition scope, NOT an OAuth authorization scope — that vocabulary was removed; roles are
+     * the single authorization axis.
+     */
+    scopeId: z.string().optional(),
+    /**
+     * The role context that authorized this access (the machine principal's roles). Roles are the
+     * single authorization axis; recorded so a SIEM sees the authority the access ran under.
+     */
+    roles: z.array(z.string()).optional(),
+    /** ResourceServerKind of the surface accessed: `a2a` | `mcp`. */
+    resourceServer: z.string(),
+    /** The resource-server audience / agent endpoint / systemRef the token was bound to and hit. */
+    resourceIdentifier: z.string().optional(),
+    /** Normalised MachineAccessOperation value (e.g. `a2a_message_send`, `mcp_tools_call`). */
+    operationIdentifier: z.string(),
+    ipAddress: z.string().optional(),
 });
 export const AuditableEvent_User_SessionExpiredEventDataSchema = z.object({
     eventType: z.literal(CoreAuditableEventType.USER_SESSION_EXPIRED),
@@ -184,6 +773,103 @@ export const AuditableEvent_User_SessionExpiredEventDataSchema = z.object({
     sessionDuration: z.number(), // minutes
     lastActivity: z.date(),
 });
+/**
+ * A `USERS` row was hard-deleted.
+ *
+ * The identity is gone after this event, so the record must carry enough to answer "who was
+ * removed?" without joining back to a row that no longer exists — hence `email` alongside `userId`.
+ * That is a deliberate, narrow retention of an identifier inside the audit trail: an erasure that
+ * left no trace of having happened would defeat the purpose of the trail, and the audit store is
+ * itself immutable and access-controlled. Prefer `RETAIN_AND_IMPERSONALIZE` erasure
+ * (`eraseSubjectAsSystem`) over a hard delete wherever the retention contract allows it — this
+ * event exists to make the hard-delete path, which the framework still exposes to administrators
+ * through `USERS | DELETE`, leave evidence.
+ *
+ * `deletedBy` is the acting principal, which for the admin route is NOT the subject. Mirrors
+ * `AuditableEvent_Organization_DeletedEventDataSchema`.
+ *
+ * assurance-control: WILDO.DATA.SECURE_LIFECYCLE — identity destruction is a
+ * security-relevant event and must be attributable.
+ */
+export const AuditableEvent_User_DeletedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.USER_DELETED),
+    userId: z.string(),
+    email: z.string().optional(),
+    deletedBy: z.string(),
+    /** Roles the deleted principal held, so an auditor can see what authority was removed. */
+    appRoles: z.array(z.string()).optional(),
+});
+/**
+ * Application-role grant / revocation on a `USERS` row.
+ *
+ * Carries BOTH the before and after arrays rather than only the delta: an auditor reconstructing a
+ * principal's authority at a point in time needs the resulting set, and the delta alone cannot
+ * distinguish "granted a role they already held" (a no-op) from a real widening. `requestedRoles`
+ * is what the administrator ASKED for — for an additive grant it is the delta, for a whole-array
+ * rewrite through the core UPDATE it is the full authored set — which is also exactly the set the
+ * role-ceiling gate measured, so the record shows what was checked, not just what resulted.
+ *
+ * `reason` is the administrator's free-text justification where the operation collects one
+ * (`assign_roles` / `revoke_roles`); the core UPDATE path has no such field and omits it.
+ */
+export const AuditableEvent_User_AppRolesChangedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.USER_APP_ROLES_CHANGED),
+    /** The user whose authority changed — the SUBJECT, not the actor. */
+    userId: z.string(),
+    previousRoles: z.array(z.string()),
+    newRoles: z.array(z.string()),
+    /** The roles as AUTHORED by the caller (the set the role-ceiling gate was measured against). */
+    requestedRoles: z.array(z.string()),
+    /** Which write path produced the change — the operation identifier (`assign_roles`, `update`, …). */
+    operation: z.string(),
+    changedBy: z.string(),
+    reason: z.string().optional(),
+});
+/**
+ * The application has no administratively usable super-administrator.
+ *
+ * Emitted by the startup floor report, not by a write path — every write that could REACH this state
+ * refuses instead, so an emission here is evidence the state arrived outside the guarded paths.
+ *
+ * `conferringRoles` is recorded because the answer depends on the LIVE role table: an application
+ * that renames or drops a custom role carrying `inheritFrom: APP_ADMIN_SUPER_ADMIN` can breach the
+ * floor without any user row changing, and an auditor reading the event a month later cannot
+ * reconstruct which roles counted at boot without it.
+ */
+export const AuditableEvent_Application_SuperAdminFloorBreachedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.APPLICATION_SUPER_ADMIN_FLOOR_BREACHED),
+    /** How many administratively usable super-administrators were found (expected: 0 when emitted). */
+    usableSuperAdminCount: z.number(),
+    /** The minimum the floor requires. */
+    requiredUsableSuperAdminCount: z.number(),
+    /** The role keys that conferred super-admin at boot, resolved from the live application role table. */
+    conferringRoles: z.array(z.string()),
+    /** The user statuses that counted as administratively usable. */
+    usableStatuses: z.array(z.string()),
+});
+/**
+ * A tenant left unadministrable by an allowed action.
+ *
+ * Carries the tenant, the memberships that stopped counting, and WHY the action was permitted, so an
+ * auditor can tell a deliberate containment decision from an accident. `remainingUsableOwners` is
+ * recorded rather than assumed zero: the floor's minimum is configurable, and an event that hard-codes
+ * the consequence cannot be re-read against a changed policy.
+ */
+export const AuditableEvent_Organization_OwnerFloorBreachedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.ORGANIZATION_OWNER_FLOOR_BREACHED),
+    /** The tenant left with no administratively usable owner. */
+    organizationId: z.string(),
+    /** The owner-conferring memberships this action removed from the population. */
+    reducedMemberIds: z.array(z.string()),
+    /** How many usable owners remain (expected: 0 when emitted). */
+    remainingUsableOwners: z.number(),
+    /** The lifecycle verb that caused it — the operator-facing "what did this". */
+    operationIdentifier: z.string(),
+    /** The subject whose deactivation triggered it. */
+    subjectUserId: z.string(),
+    /** The status the subject moved to, so a reader need not infer usability from the verb alone. */
+    subjectNextStatus: z.string(),
+});
 // Organization Member Event Data Schemas
 export const AuditableEvent_OrganizationMember_InvitedEventDataSchema = z.object({
     eventType: z.literal(CoreAuditableEventType.ORGANIZATION_MEMBER_INVITED),
@@ -206,14 +892,128 @@ export const AuditableEvent_OrganizationMember_UpdatedEventDataSchema = z.object
     memberId: z.string(),
     changes: z.record(z.string(), z.any()),
 });
+/**
+ * Organization-wide role grant / revocation on an `ORGANIZATION_MEMBERS` row.
+ *
+ * The ORGANIZATIONS-scope twin of {@link AuditableEvent_User_AppRolesChangedEventDataSchema}, and it
+ * carries the same before/after/requested triple for the same reasons: an auditor reconstructing a
+ * principal's authority at a point in time needs the RESULTING set, and the delta alone cannot
+ * distinguish "granted a role they already held" from a real widening.
+ *
+ * ## Why `requestedRoles` is not redundant with `newRoles` here
+ *
+ * It matters MORE on this resource than on the application twin. Membership CREATE runs the authored
+ * roles through resolution before persisting them — an organization type's `defaultMemberRole` is
+ * injected when the caller authored none — so "what the administrator asked for" and "what the
+ * member ended up holding" genuinely differ on an ordinary invite. `requestedRoles` is also exactly
+ * the set the role-ceiling gate measured, so the record shows what was CHECKED, not only what
+ * resulted. It is optional because "the caller authored no roles at all" (policy supplied them) is a
+ * different fact from "the caller explicitly authored an empty array", and collapsing the two would
+ * lose the distinction the ceiling gate itself draws.
+ *
+ * ## Why both `memberId` and `userId`
+ *
+ * `memberId` addresses the MEMBERSHIP ROW that was written; `userId` is the SUBJECT PRINCIPAL whose
+ * authority changed. "What could this person do on date X" is a question about the principal, and
+ * answering it through the row id alone requires a join that a retention sweep may already have
+ * removed. `AuditableEvent_OrganizationMember_RemovedEventDataSchema` carries the same pair for the
+ * same reason. `userId` stays optional so a degenerate row still leaves the rest of the evidence
+ * rather than suppressing the whole record.
+ */
 export const AuditableEvent_OrganizationMember_RoleChangedEventDataSchema = z.object({
     eventType: z.literal(CoreAuditableEventType.ORGANIZATION_MEMBER_ROLE_CHANGED),
+    /** Tenant the membership belongs to. */
     organizationId: z.string(),
+    /** The membership ROW that was written. */
     memberId: z.string(),
+    /** The SUBJECT principal whose authority changed — not the actor. */
+    userId: z.string().optional(),
     previousRoles: z.array(z.string()),
     newRoles: z.array(z.string()),
+    /** The roles as AUTHORED by the caller (the set the role-ceiling gate measured). Absent when the caller authored none. */
+    requestedRoles: z.array(z.string()).optional(),
+    /** Which write path produced the change — the operation identifier (`create`, `update`, …). */
+    operation: z.string(),
     changedBy: z.string(),
 });
+/**
+ * Per-unit role assignment on an `ORGANIZATION_UNIT_MEMBERS` row.
+ *
+ * The NARROWED twin of {@link AuditableEvent_OrganizationMember_RoleChangedEventDataSchema}. A unit
+ * assignment confers authority inside ONE organization unit — `appendUnitScopedRoles` emits it into
+ * `initiatorRoles` carrying an `organizationUnitId` discriminator, and every consumer that unions
+ * those entries partitions on that field first. The narrowing is what makes it not tenant-wide; it
+ * does not make it un-auditable, so the grant leaves evidence on the same terms.
+ *
+ * ## Why singular `role`, not an array
+ *
+ * `OrganizationUnitMember` persists ONE role per (unit, member) — that uniqueness is its business
+ * key. Reshaping it into an array here purely to mirror the organization-wide twin would invent a
+ * cardinality the resource does not have and invite a future reader to assume multiple unit roles
+ * are representable.
+ *
+ * `previousRole` is absent on an initial assignment, which is the honest encoding of "there was no
+ * prior grant" — distinct from a re-assignment away from a role that did exist.
+ */
+export const AuditableEvent_OrganizationUnitMember_RoleChangedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.ORGANIZATION_UNIT_MEMBER_ROLE_CHANGED),
+    /** Tenant the assignment belongs to. */
+    organizationId: z.string().optional(),
+    /** The unit the role is narrowed to — the discriminator that keeps this grant from reading as tenant-wide. */
+    organizationUnitId: z.string().optional(),
+    /** The assignment ROW that was written. */
+    assignmentId: z.string(),
+    /** The membership the assignment hangs off — the bridge to the SUBJECT principal. */
+    organizationMemberId: z.string().optional(),
+    /** Absent on an initial assignment: there was no prior grant to record. */
+    previousRole: z.string().optional(),
+    newRole: z.string(),
+    /** The role as AUTHORED by the caller (the value the role-ceiling gate measured). */
+    requestedRole: z.string().optional(),
+    /** Which write path produced the change — the operation identifier (`create`, `update`). */
+    operation: z.string(),
+    changedBy: z.string(),
+});
+/**
+ * Revocation of a per-unit role assignment — the closing half of
+ * {@link AuditableEvent_OrganizationUnitMember_RoleChangedEventDataSchema}.
+ *
+ * ## Why AUTHORIZATION rather than ORG_MANAGEMENT, unlike `ORGANIZATION_MEMBER_REMOVED`
+ *
+ * Removing an organization MEMBER is primarily a directory action — the person leaves the tenant —
+ * and the authority they lose is a consequence of that. An assignment row has no directory aspect
+ * whatsoever: it exists only to confer a role, so deleting it IS the revocation, and it is the exact
+ * counterpart of the CREATE that granted it. Classifying it as record-keeping would leave an
+ * authorization-filtered trail in which unit privileges are granted and never removed.
+ *
+ * ## Why the revoked role is captured
+ *
+ * `revokedRole` is the single field that cannot be recovered after the fact: the row is hard-deleted,
+ * so nothing else in the system can answer "what authority did this person lose". It is deliberately
+ * NOT named `previousRole` — that would imply a successor role, and there is none.
+ *
+ * ## Coverage boundary
+ *
+ * Emitted on the DIRECT assignment DELETE — the targeted revocation an operator performs and an
+ * auditor reviews. Cascade removals (deleting the parent membership, or the whole organization) run
+ * through the raw repository, which by construction does not execute service custom implementations;
+ * those are evidenced by their own parent event, because the semantic act there is losing the
+ * membership or the tenant, not revoking one unit role.
+ */
+export const AuditableEvent_OrganizationUnitMember_RemovedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.ORGANIZATION_UNIT_MEMBER_REMOVED),
+    /** Tenant the assignment belonged to. */
+    organizationId: z.string().optional(),
+    /** The unit the revoked role was narrowed to. */
+    organizationUnitId: z.string().optional(),
+    /** The assignment ROW that was deleted. */
+    assignmentId: z.string(),
+    /** The membership the assignment hung off — the bridge to the subject principal. */
+    organizationMemberId: z.string().optional(),
+    /** The authority that was removed. Unrecoverable once the row is gone, which is why it is recorded here. */
+    revokedRole: z.string().optional(),
+    removedBy: z.string(),
+});
 export const AuditableEvent_OrganizationMember_StatusChangedEventDataSchema = z.object({
     eventType: z.literal(CoreAuditableEventType.ORGANIZATION_MEMBER_STATUS_CHANGED),
     organizationId: z.string(),
@@ -223,12 +1023,109 @@ export const AuditableEvent_OrganizationMember_StatusChangedEventDataSchema = z.
     changedBy: z.string(),
     reason: z.string().optional(),
 });
+/**
+ * Removal of an organization membership — by administrative DELETE, or by cancelling a pending
+ * invitation through REVOKE.
+ *
+ * ## Why one event covers both, distinguished by `operation`
+ *
+ * They are genuinely different administrative acts — removing someone who works here versus
+ * withdrawing an invitation that was never accepted — and an auditor must never confuse them. But
+ * they are the same KIND of act (a membership ceases to exist) and share every other field, so
+ * splitting them into two event types would fragment "how did this person's membership end?" across
+ * two queries for no gain. `operation` carries the distinction, and `previousStatus` carries the
+ * state the row was actually in, which `operation` alone cannot give: DELETE accepts any
+ * non-`INVITED` status, so ACTIVE, INACTIVE and SUSPENDED removals are otherwise indistinguishable.
+ *
+ * An `INVITED` membership confers NOTHING — `execution-context-creator` builds `initiatorRoles` only
+ * from `ACTIVE` memberships — so a REVOKE removes no live authority. It is still recorded, because
+ * withdrawing someone's pending access is a directory decision an access review needs to see, and
+ * because `ORGANIZATION_MEMBER_INVITED` would otherwise stand unanswered.
+ *
+ * ## Why `roles` is captured
+ *
+ * The row is hard-deleted, so afterwards nothing in the system can answer "what authority did this
+ * person hold when they were removed". Same reasoning — and same shape — as
+ * `AuditableEvent_User_DeletedEventDataSchema.appRoles`. On a REVOKE it records what the invitee
+ * WOULD have received on acceptance.
+ *
+ * ## Category
+ *
+ * Classified ORG_MANAGEMENT rather than AUTHORIZATION, unlike `ORGANIZATION_UNIT_MEMBER_REMOVED`:
+ * removing a MEMBER is a directory-lifecycle action whose authority loss is a consequence, whereas a
+ * unit assignment row exists only to confer a role. The `roles` field is what keeps the authority
+ * question answerable from an ORG_MANAGEMENT record.
+ */
 export const AuditableEvent_OrganizationMember_RemovedEventDataSchema = z.object({
     eventType: z.literal(CoreAuditableEventType.ORGANIZATION_MEMBER_REMOVED),
     organizationId: z.string(),
+    /** The membership ROW that was deleted. */
     memberId: z.string(),
+    /** The SUBJECT principal who lost the membership. */
     removedUserId: z.string(),
+    /**
+     * The organization-wide roles the membership carried. Unrecoverable once the row is gone.
+     * On a REVOKE these were never in force — they are what acceptance would have conferred.
+     */
+    roles: z.array(z.string()).optional(),
+    /**
+     * The row's status at removal.
+     *
+     * Deliberately `z.string()` rather than the `OrganizationMemberStatus` enum, matching
+     * `AuditableEvent_OrganizationMember_StatusChangedEventDataSchema`: an audit row is a historical
+     * record that must stay readable after the vocabulary evolves, so the strictness belongs at the
+     * PRODUCER (which assigns from the enum), not at the record.
+     */
+    previousStatus: z.string().optional(),
+    /** Which path ended the membership — `delete` (a real member) or `revoke` (a pending invitation). */
+    operation: z.string(),
+    /**
+     * The per-unit grants this removal took with it.
+     *
+     * `ORGANIZATION_UNIT_MEMBERS` is a composition child of the membership, so deleting the membership
+     * cascades to every assignment — through the RAW REPOSITORY, below the service tier, where no
+     * custom implementation runs and therefore no `ORGANIZATION_UNIT_MEMBER_REMOVED` can fire. Without
+     * this field the trail would show each unit grant being made and never revoked: the assignment rows
+     * are hard-deleted, so the lost authority is not reconstructible from data either.
+     *
+     * Carried here rather than emitted per row on purpose — one membership removal is ONE decision, and
+     * a teardown that fans out into a dozen revocation events buries it. Captured in the DELETE prefix,
+     * which is the last moment the assignments still exist.
+     */
+    revokedUnitAssignments: z.array(z.object({
+        organizationUnitId: z.string(),
+        role: z.string(),
+    })).optional(),
+    /**
+     * Who ended the membership — a user id, or an {@link AuditActorSentinel}.
+     *
+     * ## Reading it: `operation: 'revoke'` has THREE causes, told apart HERE
+     *
+     * `operation` says a pending invitation ended; it does not say why. Three different acts produce
+     * an identical `revoke`, and the distinction between them is exactly what an access review needs:
+     *
+     * | Cause | How to recognise it |
+     * |---|---|
+     * | The invitee DECLINED | `removedBy === removedUserId` — the subject is the actor |
+     * | An administrator CANCELLED it | `removedBy` is a real user id, and a different one |
+     * | It EXPIRED unanswered | `removedBy === AuditActorSentinel.SYSTEM` (the stale-invitation sweep) |
+     *
+     * This is why the decline path supplies an on-behalf-of principal rather than running anonymously.
+     * A decline necessarily executes under BORROWED authority — the invitee has no standing to revoke
+     * an organization membership — and a borrowed-authority context carries no initiator user id, so
+     * the actor previously resolved to `SYSTEM`: an active refusal and a silent expiry wrote
+     * byte-identical rows. Recording the acting principal separates all three with no extra event type,
+     * which is the same economy `operation` and `previousStatus` already buy above.
+     *
+     * A reader must therefore not treat `removedBy === SYSTEM` on a `revoke` as "unknown actor". It is
+     * a positive statement that no human ended this invitation.
+     */
     removedBy: z.string(),
+    /**
+     * The justification. Declared by REVOKE for exactly this purpose and supplied by an administrator
+     * cancelling an invitation; on a decline it carries the invitee's optional reason, and the expiry
+     * sweep supplies none. Absent, therefore, on most declines — do not read its absence as a cause.
+     */
     reason: z.string().optional(),
 });
 // Organization Lifecycle Event Data Schemas
@@ -253,6 +1150,230 @@ export const AuditableEvent_Organization_DeletedEventDataSchema = z.object({
     deletedBy: z.string(),
     reason: z.string().optional(),
 });
+/**
+ * A tenant was MARKED for deletion — the soft-delete half of tenant teardown.
+ *
+ * Kept SEPARATE from {@link AuditableEvent_Organization_DeletedEventDataSchema} rather than folded
+ * into it with a flag, because the two record genuinely different facts and an auditor must not
+ * have to infer which one happened. This event says *the tenant's access was revoked and its data
+ * was scheduled for destruction*; `ORGANIZATION_DELETED` says *the data is gone*. Between them sits
+ * a retention window in which the decision is still reversible, and a single merged event would
+ * make "was this tenant's data actually destroyed?" unanswerable without correlating timestamps.
+ *
+ * It is also the evidence for the AUTHORIZATION consequence, which lands here and not at the purge:
+ * user types revoked and tokens invalidated. `revokedUserTypeCount` records the blast radius of that
+ * revocation without naming the users — the per-user detail belongs to the user-type events, and
+ * duplicating identities into a tenant-scoped record would widen the personal data this row holds.
+ *
+ * assurance-control: WILDO.DATA.SECURE_LIFECYCLE — scheduling the destruction
+ * of a tenant is a security-relevant, attributable decision that must leave evidence even when it
+ * is later reversed.
+ */
+export const AuditableEvent_Organization_DeletionRequestedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.ORGANIZATION_DELETION_REQUESTED),
+    organizationId: z.string(),
+    name: z.string(),
+    slug: z.string(),
+    /** The ACTOR. On the `admin` variant they are not a member of the tenant being marked. */
+    requestedBy: z.string(),
+    /** When the purge batch becomes allowed to destroy the tenant — the promise made to it. */
+    purgeScheduledAt: z.string(),
+    /** How many users lost at least one global `userTypes` grant as a result of the mark. */
+    revokedUserTypeCount: z.number().int().min(0),
+    reason: z.string().optional(),
+});
+/**
+ * A pending tenant deletion was CANCELLED inside its retention window.
+ *
+ * The closing half of {@link AuditableEvent_Organization_DeletionRequestedEventDataSchema}. Without
+ * it the audit trail records every scheduled destruction and none of the reversals, so a tenant
+ * that was marked and restored a year ago still reads as pending destruction — and an access review
+ * asking "why does this tenant have live members again?" has no answer on record.
+ *
+ * assurance-control: WILDO.ACCESS.LIFECYCLE — restoring access is as attributable as removing it.
+ */
+export const AuditableEvent_Organization_RestoredEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.ORGANIZATION_RESTORED),
+    organizationId: z.string(),
+    name: z.string(),
+    slug: z.string(),
+    /** The ACTOR — always a platform super-administrator; a marked tenant cannot restore itself. */
+    restoredBy: z.string(),
+    /** The status the tenant was returned to. */
+    restoredStatus: z.string(),
+    /** How many users had at least one global `userTypes` grant re-granted by the restore. */
+    regrantedUserTypeCount: z.number().int().min(0),
+    reason: z.string().optional(),
+});
+/**
+ * The tenant was administratively HALTED — every member loses their organization roles.
+ *
+ * ## Why this is its own event rather than an `ORGANIZATION_UPDATED`
+ *
+ * Suspension is not a field edit. Since the tenant-status authority gate shipped, `SUSPENDED` is a
+ * state in which a membership confers NOTHING — so this single write revokes the access of every
+ * member of the tenant at once. Folding that into the generic update event would bury an
+ * organization-wide access revocation inside a `changes` map, exactly where an access review would
+ * not look for it.
+ *
+ * `suspensionReason` is REQUIRED, mirroring the request contract, because the reason is the whole
+ * evidentiary point: an auditor asking "why was this tenant halted?" must not get a shrug.
+ * `notifiedMembers` records whether the tenant was told — a deliberately quiet suspension is a
+ * legitimate operator choice and one a reviewer needs to be able to see.
+ *
+ * assurance-control: WILDO.AUDIT.SECURITY_EVENT — organization-wide access
+ * revocation must be attributable, justified, and evidenced.
+ */
+export const AuditableEvent_Organization_SuspendedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.ORGANIZATION_SUSPENDED),
+    organizationId: z.string(),
+    name: z.string(),
+    slug: z.string(),
+    /** The ACTOR — always a platform super-administrator; a tenant cannot suspend itself. */
+    suspendedBy: z.string(),
+    /** The status the tenant was halted FROM, so the transition is legible without a second lookup. */
+    previousStatus: z.string(),
+    suspensionReason: z.string(),
+    /** Whether the tenant's members were emailed. A quiet suspension is a choice worth recording. */
+    notifiedMembers: z.boolean(),
+    /**
+     * How many users lost at least one GLOBAL `userTypes` grant because this tenant stopped counting.
+     *
+     * A suspension does not only halt the tenant: a membership in a non-authority-conferring
+     * organization no longer justifies a membership-derived global grant, so suspending an
+     * organization can withdraw what it was vouching for platform-wide. That reach is exactly what an
+     * access review needs to see, and it is invisible from the status change alone.
+     */
+    revokedUserTypeCount: z.number().int().min(0),
+});
+/**
+ * A halted or expired tenant was returned to normal operation — the inverse of
+ * {@link AuditableEvent_Organization_SuspendedEventDataSchema}.
+ *
+ * Restoring organization-wide access is as security-relevant as removing it, and without this event
+ * the trail would record every suspension and none of the lifts — leaving a tenant that was halted
+ * and reinstated a year ago still reading as suspended.
+ *
+ * `previousStatus` distinguishes the two journeys this operation serves: lifting a suspension
+ * (`SUSPENDED`) and converting an expired trial (`TRIAL_EXPIRED`). They land on the same state and
+ * are not the same event to a reviewer.
+ *
+ * assurance-control: WILDO.AUDIT.SECURITY_EVENT — reinstatement of access is attributable.
+ */
+export const AuditableEvent_Organization_ActivatedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.ORGANIZATION_ACTIVATED),
+    organizationId: z.string(),
+    name: z.string(),
+    slug: z.string(),
+    /** The ACTOR — always a platform super-administrator. */
+    activatedBy: z.string(),
+    /** `SUSPENDED` (a lift) or `TRIAL_EXPIRED` (a conversion) — not the same journey. */
+    previousStatus: z.string(),
+    /** How many users had at least one global `userTypes` grant restored by the reactivation. */
+    regrantedUserTypeCount: z.number().int().min(0),
+    reason: z.string().optional(),
+});
+/**
+ * One user type's authentication-policy snapshot — the COMPLETE authored `UserTypeAuthPolicy` (MFA,
+ * password, lockout, enabled auth methods, step-up, session duration, …) as recorded in the trail.
+ *
+ * The whole policy is captured, not a hand-picked subset, so no posture axis escapes the record: a
+ * weakening is as easily "disable the MFA auth method" (`authMethodsEnabled`) or "drop step-up"
+ * (`stepUpAuth`) as "turn `requireMFA` off". The policy carries only booleans / numbers / enums —
+ * never a secret — so recording it verbatim discloses nothing sensitive.
+ *
+ * Deliberately STRUCTURAL (an open record) rather than a reference to the live `UserTypeAuthPolicy`
+ * config schema. An audit record is a historical fact: it must keep validating after the config
+ * schema evolves, so it stores the policy as it was at that boot rather than re-validating it against
+ * today's shape. The queryable summary lives in `changedUserTypes` + `snapshotDigest`; this object
+ * carries the human-readable before/after detail.
+ */
+export const ApplicationAuthPolicySnapshotSchema = z.record(z.string(), z.unknown());
+/**
+ * The application's authored authentication policy changed between two boots.
+ *
+ * The per-user-type authentication policy (`userTypes.<type>.auth` — MFA, password, and lockout
+ * requirements) is STATIC application configuration authored in code and taken into effect at backend
+ * startup. A change to it — most consequentially a WEAKENING such as turning MFA off — is a
+ * security-posture decision that, before this event, left no product-side record: only the source
+ * history showed it. This event closes that gap.
+ *
+ * It is emitted at boot, by the system, when the resolved policy snapshot differs from the last one
+ * recorded in the trail (detected by comparing against the most recent event of this type for the
+ * application). Because there is no human actor at boot, the "who" is the deployment/source history;
+ * the event records WHAT changed (before → after per user type) so a reviewer sees the posture shift
+ * without reading the codebase.
+ *
+ * Scope note: this is the per-application AUTHORED baseline. It does NOT enumerate per-tenant
+ * `authOverrides` (which are per-(user-type × org-type) and require live tenants to resolve), nor the
+ * authenticate-time `FALLBACK_AUTH_POLICY` (a runtime substitute used only when no user type
+ * resolves, not authored config).
+ *
+ * assurance-control: WILDO.IDENTITY.SESSION_ASSURANCE — a change to the authentication assurance
+ * requirements (MFA / password / lockout) must be attributable and evidenced.
+ */
+export const AuditableEvent_ApplicationAuthPolicyChanged_EventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.APPLICATION_AUTH_POLICY_CHANGED),
+    applicationId: z.string(),
+    /** Which user types' policies differed from the previously-recorded snapshot. Sorted, non-empty. */
+    changedUserTypes: z.array(z.string()),
+    /**
+     * A stable digest of the `after` snapshot. Boot change-detection compares the current digest
+     * against the digest carried by the most recent recorded event of this type; equal digests are the
+     * signal to emit nothing, so the trail carries one row per genuine change, not one per boot.
+     */
+    snapshotDigest: z.string(),
+    /**
+     * The previously-recorded per-user-type policy snapshot, or `null` when this is the first snapshot
+     * ever recorded for the application (the baseline row). Keys are user-type identifiers.
+     */
+    before: z.record(z.string(), ApplicationAuthPolicySnapshotSchema).nullable(),
+    /** The per-user-type policy snapshot that took effect at this boot. Keys are user-type identifiers. */
+    after: z.record(z.string(), ApplicationAuthPolicySnapshotSchema),
+});
+/**
+ * A governed lifecycle transition changed a subject's `status`.
+ *
+ * Emitted by the shared status-transition implementation, so every verb it serves is trailed by
+ * construction and a future one inherits the trail rather than having to remember it. Before this
+ * existed those verbs emitted NOTHING: suspending a member (CRITICAL) or a user (HIGH) left no
+ * record at all, while suspending a TENANT was fully attributable — an asymmetry an access review
+ * would have to discover the hard way.
+ *
+ * `reason` is where the verbs' long-declared `reason` / `suspensionReason` fields finally land.
+ * They are not persisted on the row: a suspension reason is a compliance artefact nothing reads
+ * back, so the trail is its home rather than a schema column that would have to be scrubbed on
+ * erasure.
+ *
+ * assurance-control: WILDO.AUDIT.SECURITY_EVENT — a change to whether a principal may act must be
+ * attributable, justified and evidenced, on every resource that has such a state.
+ */
+export const AuditableEvent_Resource_StatusTransitionPerformedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.RESOURCE_STATUS_TRANSITION_PERFORMED),
+    /** Which resource the subject row belongs to — half of the verb discriminator. */
+    resourceType: z.string(),
+    /** The lifecycle verb that ran (`suspend`, `reactivate`, `suspend_user`, …). */
+    operationIdentifier: z.string(),
+    /** The row whose status changed. */
+    subjectId: z.string(),
+    /** The ACTOR who performed it, or the system principal when the reactivation sweep ran it. */
+    performedBy: z.string(),
+    /** The status transitioned FROM, so the change is legible without a second lookup. */
+    previousStatus: z.string(),
+    /** The status transitioned TO. */
+    newStatus: z.string(),
+    /** The caller's justification, where the verb's contract accepts one. */
+    reason: z.string().optional(),
+    /**
+     * When an automated sweep will undo this, if the caller time-boxed it. ISO-8601.
+     *
+     * Recorded because "suspended for 7 days" and "suspended indefinitely" are materially different
+     * decisions that would otherwise be indistinguishable in the trail.
+     */
+    scheduledReactivationAt: z.string().optional(),
+    /** Present when the subject is tenant-scoped, so the trail routes to that tenant's SIEM. */
+    organizationId: z.string().optional(),
+});
 export const AuditableEvent_OrganizationNotifications_UpdatedEventDataSchema = z.object({
     eventType: z.literal(CoreAuditableEventType.ORGANIZATION_NOTIFICATIONS_UPDATED),
     organizationId: z.string(),
@@ -289,10 +1410,38 @@ export const AuditableEvent_User_SSOLoginEventDataSchema = z.object({
     providerRef: z.string(),
     connectionType: z.enum(SsoConnectionType),
     authSource: z.string().optional(),
+    scopeType: z.enum(AuthScopeType).optional(),
     organizationId: z.string().optional(),
+    applicationId: z.string().optional(),
     ipAddress: z.string(),
     userAgent: z.string(),
     sessionId: z.string(),
+}).superRefine((event, ctx) => {
+    if (event.connectionType === SsoConnectionType.SOCIAL) {
+        if (event.scopeType !== undefined
+            || event.organizationId !== undefined
+            || event.applicationId !== undefined) {
+            ctx.addIssue({
+                code: 'custom',
+                path: ['scopeType'],
+                message: 'Social SSO audit events must not carry enterprise scope',
+            });
+        }
+        return;
+    }
+    const hasOrganizationScope = event.scopeType === AuthScopeType.ORGANIZATION
+        && event.organizationId !== undefined
+        && event.applicationId === undefined;
+    const hasApplicationScope = event.scopeType === AuthScopeType.APPLICATION
+        && event.applicationId !== undefined
+        && event.organizationId === undefined;
+    if (!hasOrganizationScope && !hasApplicationScope) {
+        ctx.addIssue({
+            code: 'custom',
+            path: ['scopeType'],
+            message: 'Enterprise SSO audit events require exactly one explicit tenant scope',
+        });
+    }
 });
 export const AuditableEvent_User_SSOLoginFailedEventDataSchema = z.object({
     eventType: z.literal(CoreAuditableEventType.USER_SSO_LOGIN_FAILED),
@@ -301,7 +1450,9 @@ export const AuditableEvent_User_SSOLoginFailedEventDataSchema = z.object({
     connectionType: z.enum(SsoConnectionType).optional(),
     authSource: z.string().optional(),
     failureReason: z.string(),
+    scopeType: z.enum(AuthScopeType).optional(),
     organizationId: z.string().optional(),
+    applicationId: z.string().optional(),
     ipAddress: z.string(),
     userAgent: z.string(),
 });
@@ -339,6 +1490,37 @@ export const AuditableEvent_Organization_SIEMExportConfiguredEventDataSchema = z
     webhookUrlDomain: z.string().optional(),
     eventFormatConfigured: z.string().optional(),
 });
+// Outbound M2M Webhook Event Data Schemas
+/**
+ * One `webhookConfig.testEndpoint` attempt — an admin causing the platform to open an
+ * outbound connection to an operator-supplied URL.
+ *
+ * Recorded for EVERY attempt, not only failures: the security signal here is the pattern
+ * (who probes which hosts, how often), which a SIEM can only derive if successes are
+ * present too. `outcome` distinguishes a refusing endpoint from an unreachable one from a
+ * local signing fault, so the stream stays diagnosable without the response body.
+ *
+ * `destinationHost` carries the host only, never the full URL — mirroring
+ * `AuditableEvent_Organization_SIEMExportConfiguredEventDataSchema.webhookUrlDomain`. Paths
+ * and query strings on customer endpoints routinely embed per-tenant tokens, and an audit
+ * row is replicated to the org SIEM and the immutable store.
+ */
+export const AuditableEvent_Webhook_EndpointTestDispatchedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.WEBHOOK_ENDPOINT_TEST_DISPATCHED),
+    /** Scope that owns the config — exactly one of these is set, per the polymorphic variant. */
+    organizationId: z.string().optional(),
+    applicationId: z.string().optional(),
+    /** Admin who fired the probe. */
+    dispatchedBy: z.string(),
+    endpointId: z.string(),
+    /** Host component only — see the schema JSDoc for why the full URL is withheld. */
+    destinationHost: z.string(),
+    outcome: z.enum(WebhookEndpointProbeOutcome),
+    responseStatus: z.number().int().optional(),
+    durationMs: z.number().int().nonnegative(),
+    /** `jti` of the signed probe, for correlation with the consumer's own logs. */
+    signatureJti: z.string(),
+});
 // SCIM Directory Provisioning Event Data Schemas
 export const AuditableEvent_SCIM_TokenCreatedEventDataSchema = z.object({
     eventType: z.literal(CoreAuditableEventType.SCIM_TOKEN_CREATED),
@@ -387,6 +1569,38 @@ export const AuditableEvent_User_PasswordResetRequestedEventDataSchema = z.objec
     ipAddress: z.string(),
     userAgent: z.string(),
 });
+/**
+ * Administrator-compelled credential reset.
+ *
+ * Carries BOTH identities because the actor and the subject differ — that separation is the
+ * whole point of the event. `actorUserId` is read from the authenticated execution context,
+ * never from request input, so it cannot be spoofed by the caller. `reason` is the operator's
+ * mandatory justification; it is what an auditor reads when asking why a credential was reset
+ * out-of-band.
+ *
+ * assurance-control: WILDO.IDENTITY.CREDENTIAL_LIFECYCLE — privileged credential
+ * intervention must be attributable to the acting administrator and carry a justification.
+ */
+export const AuditableEvent_User_PasswordResetForcedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.USER_PASSWORD_RESET_FORCED),
+    targetUserId: z.string(),
+    targetEmail: z.string(),
+    actorUserId: z.string(),
+    reason: z.string(),
+    /** Whether the target's active sessions were revoked as part of the reset. */
+    sessionsRevoked: z.boolean(),
+    /**
+     * Transport metadata, OPTIONAL because this event's only producer is a resource operation.
+     *
+     * The auth controllers thread `ipAddress` / `userAgent` down from the Express request, but a
+     * resource-operation custom implementation receives an `ExecutionContext`, which carries
+     * identity and no transport detail. Rather than stamping a fabricated `'unknown'` that reads
+     * like a captured value, the fields are omitted and correlation runs through the request log.
+     * They become populated if transport metadata is ever threaded onto the execution context.
+     */
+    ipAddress: z.string().optional(),
+    userAgent: z.string().optional(),
+});
 export const AuditableEvent_User_PasswordResetCompletedEventDataSchema = z.object({
     eventType: z.literal(CoreAuditableEventType.USER_PASSWORD_RESET_COMPLETED),
     userId: z.string(),
@@ -543,10 +1757,26 @@ export const AuditableEvent_OAuth2ProviderBlockedEventDataSchema = z.object({
     eventType: z.literal(CoreAuditableEventType.OAUTH2_PROVIDER_BLOCKED),
     email: z.string().optional(),
     providerRef: z.string(),
-    organizationId: z.string(),
+    scopeType: z.enum(AuthScopeType),
+    organizationId: z.string().optional(),
+    applicationId: z.string().optional(),
     reason: z.string(),
     ipAddress: z.string(),
     userAgent: z.string(),
+}).superRefine((event, ctx) => {
+    const hasOrganizationScope = event.scopeType === AuthScopeType.ORGANIZATION
+        && event.organizationId !== undefined
+        && event.applicationId === undefined;
+    const hasApplicationScope = event.scopeType === AuthScopeType.APPLICATION
+        && event.applicationId !== undefined
+        && event.organizationId === undefined;
+    if (!hasOrganizationScope && !hasApplicationScope) {
+        ctx.addIssue({
+            code: 'custom',
+            path: ['scopeType'],
+            message: 'OAuth2 provider-blocked events require exactly one explicit tenant scope',
+        });
+    }
 });
 // Emergency Access Event Data Schema
 export const AuditableEvent_EmergencyAccess_UsedEventDataSchema = z.object({
@@ -566,18 +1796,967 @@ export const AuditableEvent_FieldAccess_EventDataSchema = z.object({
     resourceId: z.string().optional(),
     operationIdentifier: z.string(),
     isCreateOperation: z.boolean(),
+    // Machine-credential provenance when the ACCESSING principal is a machine (api-key / OAuth
+    // client) rather than a human. Absent for user-authenticated access. Threads the credential id
+    // + auth method onto the sensitive-field-access row so machine access is attributable — the
+    // per-request counterpart to the dedicated MACHINE_AUTH_* events (machine-auth-hardening item 2).
+    machineCredentialAuthMethod: z.string().optional(),
+    machineCredentialId: z.string().optional(),
+});
+/**
+ * **A resource operation took effect.** The operation-triggered counterpart to
+ * {@link AuditableEvent_FieldAccess_EventDataSchema}, which is triggered by a decorated RESPONSE
+ * FIELD and is therefore blind to any operation whose response carries none.
+ *
+ * ## What the existence of this row asserts, and what it does not
+ *
+ * It is emitted from the framework-managed POST-COMMIT effects lane, so the row exists only for an
+ * operation whose mutation is already durable. "Performed" is therefore the whole claim — there is
+ * deliberately no `outcome` discriminator, because this emission point can never observe a failure.
+ *
+ * The absence of a row is NOT evidence that nothing happened; that is what makes audit-pipeline
+ * failure detection (`audit_store_failure_total`, and the operation identity now carried on the
+ * failure log line) a control in its own right rather than an operational nicety.
+ *
+ * **Refusals are a different event and a different chokepoint.** A denied operation never reaches
+ * this lane — the authorization decision happens pre-dispatch, its volume is attacker-drivable, and
+ * it needs rate-limit / dedup treatment this success path does not. Declaring a `DENIED` outcome
+ * here that nothing produces would repeat the very defect this event exists to fix (20 event types
+ * were authored in this enum and wired to nothing). That refusal event now exists and is emitted:
+ * see {@link AuditableEvent_ResourceOperationDenied_EventDataSchema}, raised from the authorizer.
+ * The two events are read together — this one for what happened, that one for what was stopped —
+ * and neither carries an `outcome` discriminator, because each states its whole claim in its name.
+ *
+ * ## Operation identity is a TRIPLE
+ *
+ * `resourceType` + `operationIdentifier` + `variantKey`. Recording only the first two makes an
+ * `admin` variant indistinguishable from a `self` variant — a distinction several polymorphic
+ * resources encode in `variantKey` alone, and precisely the distinction an auditor is checking.
+ *
+ * ## Correlation across a cascade
+ *
+ * Every execution surface emits — API, internal call, and repository-only — so one tenant deletion
+ * produces one row per cascaded child. The top-level `correlationId` is inherited by every sub-call
+ * context and preserved across mid-flight operation corrections, so it groups the whole fan-out to one request;
+ * `subCallDepth` separates the initiating operation (0) from what it cascaded into.
+ *
+ * ## Field evidence is deliberately partial (GDPR Art. 5(1)(c) + Art. 17)
+ *
+ * `changedFields` names every field the write touched — a field NAME is not personal data, so it is
+ * always safe and always recorded. `fieldEvidence` carries before/after VALUES only for fields the
+ * schema marks `.isAuditEvidence()`.
+ *
+ * Values are limited on purpose: audit rows replicate to the per-org SIEM and to the immutable
+ * ledger, and **the immutable ledger cannot be scrubbed** — so copying arbitrary personal data into
+ * this event would manufacture an unerasable duplicate, in direct conflict with Art. 17 and with the
+ * impersonalization/retention capability built to make personal data erasable. Authority-, status-
+ * and scope-bearing values ARE necessary (a role change that does not record the old and new roles
+ * proves nothing), and those are exactly what the marker is for.
+ *
+ * assurance-control: WILDO.AUDIT.EVIDENCE_INTEGRITY
+ */
+export const AuditableEvent_ResourceOperationPerformed_EventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.RESOURCE_OPERATION_PERFORMED),
+    // ── Operation identity (the triple + the shape that resolves the persistence semantics) ──
+    /** The resource whose row(s) the operation acted on. */
+    resourceType: z.string(),
+    /** The verb — a core operation (`update`, `delete`) or a custom identifier (`suspend`). */
+    operationIdentifier: z.string(),
+    /** Which execution surface ran it. API, internal call, repository-only, cron, batch. */
+    variantType: z.enum(ResourceOperationVariantType),
+    /**
+     * The variant discriminator. Absent on the default variant; REQUIRED to distinguish e.g. the
+     * `admin` variant of a verb from its `self` twin, which share `operationIdentifier`.
+     */
+    variantKey: z.string().optional(),
+    /** The core persistence semantics a custom verb borrows. Absent when the verb IS a core operation. */
+    resourceOperationLike: z.enum(CoreResourceOperation).optional(),
+    /** `true` for the bulk form, whose subject is a set rather than one row. */
+    isBulkOperation: z.boolean().optional(),
+    // ── Subject ──
+    /** The row acted on. Absent for bulk operations, which name a count instead. */
+    resourceId: z.string().optional(),
+    /** Bulk operations only: how many rows the write affected. */
+    affectedRecordCount: z.number().optional(),
+    // ── Principal (the row's `userId` / `organizationId` / `applicationId` carry the identity) ──
+    /**
+     * The caller's roles AS THEY WERE at decision time. Roles are the framework's single
+     * authorization axis, so without them a reader cannot tell whether the actor was entitled to the
+     * action — and the actor's roles today are not the roles they held then.
+     */
+    initiatorRoles: z.array(z.string()),
+    /** How the call was initiated — separates a human request from framework machinery. */
+    executionType: z.enum(ExecutionContext_ExecutionType),
+    /** Machine-credential provenance when the principal is a machine rather than a human. */
+    machineCredentialAuthMethod: z.string().optional(),
+    machineCredentialId: z.string().optional(),
+    // ── Cascade depth (the request that groups the whole cascade is the row's top-level `correlationId`) ──
+    /** `0` for the operation the caller invoked; deeper for what it cascaded into. */
+    subCallDepth: z.number(),
+    // ── Effect ──
+    /** Every field the write touched. Names only — always safe, always recorded. */
+    changedFields: z.array(z.string()).optional(),
+    /**
+     * Before/after values, restricted to fields marked `.isAuditEvidence()`. `before` is absent on a
+     * CREATE (there was no prior value) and on any bulk write (the framework fetches a pre-image only
+     * for a single selected id).
+     */
+    fieldEvidence: z
+        .record(z.string(), z.object({
+        before: z.unknown().optional(),
+        after: z.unknown().optional(),
+    }))
+        .optional(),
+});
+/**
+ * An operation the authorizer REFUSED. The other half of "record access decisions" — the negative
+ * decision, which until now left no trace anywhere in the framework.
+ *
+ * ## Emitted pre-dispatch, from the one funnel
+ *
+ * Every public entry point of `AuthorizationsBackendService` converges on the same two inner phase
+ * runners — `authorizeInController` (HTTP controller, MCP, WebSocket, queue, field validation),
+ * `authorizeInProgrammaticSurface` (a non-controller surface that faces an external caller), and
+ * `authorizeInRepositoryAndService`, which has exactly one caller — `authorizeInController` itself.
+ * So a single instrumentation point observes every refusal THE AUTHORIZER MAKES, with the operation
+ * and execution context both in scope. No mutation has occurred when this row is written; nothing is
+ * rolled back by it.
+ *
+ * **The scope of that claim, stated because an earlier revision overstated it.** It used to read
+ * "the sole production entry point for every execution surface", which asserts something stronger
+ * and false: that every execution surface passes the role gate. A programmatic operation entering at
+ * the SERVICE tier (`ServicesRegistryHandlerBackendService.read` / `list` / …) reaches no authorizer
+ * at all — deliberately, because that population includes the reads that ESTABLISH identity before a
+ * role-bearing principal exists. So the absence of a row here means "the authorizer refused nothing",
+ * never "nothing was read". See `AuthorizationsBackendService.authorizeInProgrammaticSurface` for the
+ * layering decision and the door.
+ *
+ * ## What it is NOT
+ *
+ * - **Not an authentication failure.** `USER_LOGIN_FAILED` / `MACHINE_AUTH_FAILED` say "you are not
+ *   who you claim to be". This says "you are, and you may not do this". Distinct types, distinct
+ *   categories, neither overloaded.
+ * - **Not an `outcome: 'denied'` variant of {@link AuditableEvent_ResourceOperationPerformed_EventDataSchema}.**
+ *   That event is emitted from the post-commit lane, which by construction can only observe
+ *   operations that already took effect. A refusal never reaches it.
+ *
+ * ## Volume: bounded by dedup, NOT by a risk floor
+ *
+ * Denial volume is attacker-drivable in a way the success path's never is. A risk floor was
+ * considered and rejected as the control: it would exclude 100% of denied READS (zero of the
+ * catalogue's HIGH/CRITICAL variants are reads, while 371 of 551 API-reachable variants are) —
+ * discarding the canonical reconnaissance signal — while not capping the adversarial worst case at
+ * all, since the attacker chooses which endpoint to hammer.
+ *
+ * The actual bound is a per-principal / per-operation / per-reason dedup window. Rather than
+ * suppressing repeats outright (which would erase the storm — the very signal a security-operations team wants),
+ * emission escalates on a LOGARITHMIC ladder: the 1st, 10th, 100th, … refusal in the window each
+ * emit one row carrying {@link occurrenceCount}. A burst of 10 000 identical denials therefore
+ * costs 5 rows and remains legible as a burst.
+ *
+ * Dedup is best-effort and FAILS OPEN (emit) when the counter store is unavailable — a fail-closed
+ * cooldown would let an attacker blind the audit trail by taking Redis down.
+ *
+ * assurance-control: WILDO.ACCESS.AUTHORIZATION_DECISION_AUDIT
+ */
+/**
+ * A platform operator acted on a row belonging to a tenant they are not a member of.
+ *
+ * ## Why this event exists
+ *
+ * Wildo's answer to "may a platform super-administrator administer any tenant?" is YES — the same
+ * answer most mature B2B platforms give, because support and incident response genuinely need it.
+ * What those platforms do NOT do is leave the reach implicit. Support access is a named, logged
+ * event, because the difference between legitimate operator work and quiet snooping is not the
+ * capability — both use the identical capability — it is whether anyone can tell afterwards.
+ *
+ * Until 2026-08-05 Wildo had the capability with none of the visibility, and by accident rather than
+ * declaration: per-instance org-scoped requests are checked by `authorizeOrganizations`, which
+ * compares the fetched row's organization against a scope the SAME REQUEST supplied through its URL.
+ * A non-member operator therefore passed it silently. Measured over real HTTP by
+ * `organization-ownership-grant-hostile.e2e.ts` probe F-1a, which deleted a membership row in
+ * another tenant and got a 200.
+ *
+ * This event is the visibility half. It does NOT refuse — refusing is a separate, much larger change
+ * with a measured blast radius (see the plan) and is a policy decision in its own right. Emission is
+ * best-effort and never blocks the request: an operator action must not fail because the audit sink
+ * is down, and a fail-closed variant would let anyone disable operator support by breaking the sink.
+ *
+ * ## Reading the event
+ *
+ * {@link admissionDeclared} is the field that matters most. `true` means the operation VARIANT
+ * declared `admitsCrossTenantPlatformAdministration` — an intended, reviewed crossing such as
+ * `organizationMembers.grantOwnership`. `false` means the reach came from the structural gap above:
+ * nobody declared it, no spec documents it, and it is the population to watch.
+ *
+ * assurance-control: WILDO.ACCESS.CROSS_TENANT_ADMINISTRATION — platform-tier access to a tenant the
+ * principal does not belong to.
+ * assurance-control: WILDO.ACCESS.AUTHORIZATION_DECISION_AUDIT
+ */
+/**
+ * One transition in the life of a platform access grant.
+ *
+ * The crossing itself is recorded by {@link CoreAuditableEventType.CROSS_TENANT_ADMINISTRATIVE_ACCESS}.
+ * This is the other half, and a reviewer needs both: that event answers "an operator reached into
+ * this tenant", this one answers "on what authority, asked for when, and who agreed".
+ *
+ * Deliberately two events rather than one enriched one. A grant is requested once and may authorise
+ * many crossings across its window, so folding them together would either duplicate the grant's
+ * details onto every access or lose the request/decision timeline entirely.
+ *
+ * {@link autoApprovalReason} is the field a customer audit turns on. Its ABSENCE on an approved grant
+ * means a human in the tenant said yes. `TENANT_APPROVAL_NOT_REQUIRED` means the tenant had not opted
+ * into approval. `TENANT_CANNOT_APPROVE` means the tenant had no administratively usable owner and
+ * could not consent — the one path where operator access proceeds against a tenant that never agreed
+ * and never could, which is why the emitter carries it at a higher risk level.
+ *
+ * assurance-control: WILDO.ACCESS.CROSS_TENANT_ADMINISTRATION
+ * assurance-control: WILDO.ACCESS.PRIVILEGE_EVIDENCE — evidence of a privileged assignment's full life.
+ */
+export const AuditableEvent_PlatformAccessGrantLifecycle_EventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.PLATFORM_ACCESS_GRANT_LIFECYCLE),
+    /** Which transition this row records. */
+    transition: z.enum(PlatformAccessGrantLifecycleTransition),
+    /** The grant, so the whole timeline can be reassembled from its rows. */
+    grantId: z.string(),
+    /** The tenant that was, or would have been, reached into. */
+    targetOrganizationId: z.string(),
+    /** The operator who asked. Never the decider — see {@link decidedByUserId}. */
+    operatorUserId: z.string(),
+    /** Why the operator said they needed access. Recorded on every transition, not only the request. */
+    justification: z.string().optional(),
+    /** The status the grant holds after this transition. */
+    resultingStatus: z.enum(PlatformAccessGrantStatus),
+    /** When the elevation stops working. Absent on a grant that never became usable. */
+    expiresAt: z.date().optional(),
+    /** Present exactly when the grant became usable with no tenant administrator acting. */
+    autoApprovalReason: z.enum(PlatformAccessGrantAutoApprovalReason).optional(),
+    /** The tenant administrator who approved, denied or revoked. Absent on an auto-approval. */
+    decidedByUserId: z.string().optional(),
+    /** Their stated reason, when they gave one. */
+    decisionReason: z.string().optional(),
+});
+export const AuditableEvent_CrossTenantAdministrativeAccess_EventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.CROSS_TENANT_ADMINISTRATIVE_ACCESS),
+    /** The tenant that was reached into — the row's organization, never the caller's own. */
+    targetOrganizationId: z.string(),
+    /** The resource whose row the operator acted on. */
+    resourceType: z.string(),
+    /** The verb — a core operation (`update`, `delete`) or a custom identifier (`grantOwnership`). */
+    operationIdentifier: z.string(),
+    /** Which execution surface the crossing arrived on. */
+    variantType: z.enum(ResourceOperationVariantType),
+    /** The variant discriminator, which is what distinguishes a declared crossing from its siblings. */
+    variantKey: z.string().optional(),
+    /** The row(s) reached. Absent for collection operations, which name no id. */
+    targetResourceIds: z.array(z.string()).optional(),
+    /**
+     * The elevation that authorised this crossing, when one did.
+     *
+     * This is what joins the two operator-access events into one story: the lifecycle event says an
+     * elevation was requested, justified and decided; this field says WHICH elevation a given access
+     * was exercised under. Without it a reviewer looking at a crossing has to infer the grant from
+     * timestamps, which stops working the moment an operator holds two grants in a day.
+     *
+     * Absent on the bootstrap verb (`requestAccess` is exempt — it is how a grant comes into existence)
+     * and on any crossing admitted before grants were required.
+     */
+    authorizingGrantId: z.string().optional(),
+    /**
+     * Did the operation variant DECLARE this crossing (`admitsCrossTenantPlatformAdministration`)?
+     *
+     * `false` is the signal worth alerting on: reach that no variant asked for and no specification
+     * describes. See this schema's JSDoc.
+     */
+    admissionDeclared: z.boolean(),
+    /** The caller's roles as they were at decision time. */
+    initiatorRoles: z.array(z.string()),
+    /** How the call was initiated — separates a human operator from framework machinery. */
+    executionType: z.enum(ExecutionContext_ExecutionType),
+});
+/**
+ * An application-wide directory enumeration.
+ *
+ * See {@link CoreAuditableEventType.PLATFORM_DIRECTORY_ACCESS} for why this is a distinct event
+ * type rather than a shape of the cross-tenant one. The short version: there is no target tenant to
+ * name, because the read deliberately spans them all.
+ */
+export const AuditableEvent_PlatformDirectoryAccess_EventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.PLATFORM_DIRECTORY_ACCESS),
+    /** The directory that was enumerated (`users`, `anonymousUsers`, …). */
+    resourceType: z.string(),
+    /** The collection verb — `list`, `search`, `count`. */
+    operationIdentifier: z.string(),
+    /** Which execution surface the read arrived on. */
+    variantType: z.enum(ResourceOperationVariantType),
+    /**
+     * The variant discriminator.
+     *
+     * Load-bearing rather than decorative: on `users` the DEFAULT `list` variant is `INTERNAL_CALL`
+     * and registers no route, while the HTTP-exposed one is the non-default `admin` variant. A
+     * reviewer who cannot tell the two apart cannot tell an internal enumeration from an operator
+     * browsing the directory.
+     */
+    variantKey: z.string().optional(),
+    /**
+     * How many rows the caller actually received.
+     *
+     * The size is the signal. "An operator opened the user directory" is routine; "an operator paged
+     * through 40,000 users" is the shape of an export, and only this field distinguishes them.
+     */
+    returnedCount: z.number().int().nonnegative(),
+    /** The caller's roles as they were at read time. */
+    initiatorRoles: z.array(z.string()),
+    /** How the call was initiated — separates a human operator from framework machinery. */
+    executionType: z.enum(ExecutionContext_ExecutionType),
+});
+export const AuditableEvent_ResourceOperationDenied_EventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.RESOURCE_OPERATION_DENIED),
+    // ── Why (the discriminator a security-operations dashboard groups by) ──
+    /** Which refusal the authorizer resolved. */
+    denialReason: z.enum(ResourceOperationDenialReason),
+    // ── Operation identity (the same TRIPLE as the success twin — see its JSDoc for why) ──
+    /** The resource whose row(s) the caller attempted to act on. */
+    resourceType: z.string(),
+    /** The verb — a core operation (`update`, `delete`) or a custom identifier (`suspend`). */
+    operationIdentifier: z.string(),
+    /** Which execution surface the attempt arrived on. */
+    variantType: z.enum(ResourceOperationVariantType),
+    /**
+     * The variant discriminator. Absent on the default variant; REQUIRED to distinguish e.g. the
+     * `admin` variant of a verb from its `self` twin, which share `operationIdentifier`.
+     */
+    variantKey: z.string().optional(),
+    /** The core persistence semantics a custom verb borrows. Absent when the verb IS a core operation. */
+    resourceOperationLike: z.enum(CoreResourceOperation).optional(),
+    /** `true` for the bulk form, whose subject is a set rather than one row. */
+    isBulkOperation: z.boolean().optional(),
+    // ── Subject (what was ATTEMPTED — never proof the row exists) ──
+    /**
+     * The row id(s) the caller named. Present even for {@link ResourceOperationDenialReason.SUBJECT_NOT_RESOLVABLE},
+     * where the id may correspond to nothing at all — this records what was ASKED FOR, not what exists.
+     * Absent for collection operations, which name no id.
+     */
+    attemptedResourceIds: z.array(z.string()).optional(),
+    // ── Authority (what was required vs. what was held) ──
+    /**
+     * The role set the operation demanded. Together with {@link initiatorRoles} this makes the refusal
+     * self-explaining: a reviewer sees what was needed and what the caller had, without re-deriving
+     * the operation's config as it stood that day.
+     */
+    requiredRoles: z.array(z.string()).optional(),
+    /**
+     * The caller's roles AS THEY WERE at decision time — empty when the refusal WAS the absence of
+     * them ({@link ResourceOperationDenialReason.MISSING_INITIATOR}).
+     */
+    initiatorRoles: z.array(z.string()),
+    /** How the call was initiated — separates a human request from framework machinery. */
+    executionType: z.enum(ExecutionContext_ExecutionType),
+    /** Machine-credential provenance when the refused principal is a machine rather than a human. */
+    machineCredentialAuthMethod: z.string().optional(),
+    machineCredentialId: z.string().optional(),
+    // ── Cascade depth (the request that groups the whole cascade is the row's top-level `correlationId`) ──
+    /** `0` for the operation the caller invoked; deeper for what it cascaded into. */
+    subCallDepth: z.number(),
+    // ── Burst accounting (see the dedup ladder in this schema's JSDoc) ──
+    /**
+     * How many identical refusals (same principal, operation and reason) have accumulated in the
+     * current dedup window INCLUDING this one. `1` on the first. A row with a large value is a
+     * deliberate escalation checkpoint, not a duplicate.
+     */
+    occurrenceCount: z.number(),
+    /**
+     * `true` when the count is exact (the dedup counter was reachable). `false` when the counter store
+     * was unavailable and the emission fell open — the row is then a truthful record of ONE refusal
+     * whose burst context is unknown, and {@link occurrenceCount} is not to be trusted as a total.
+     */
+    occurrenceCountIsExact: z.boolean(),
+});
+/**
+ * A privileged SEE-THROUGH read that revealed RETAINED (impersonalized-and-retained) records —
+ * rows kept for a legal/audit obligation while their personal data was scrubbed, hidden from
+ * normal callers by the retention hide-predicate. This is the compliance-grade access record over
+ * that scrubbed data, and its two defining properties (vs `SYSTEM_CONTEXT_READ`, which names only the
+ * RUNTIME that acted, never a human) are:
+ *
+ * 1. **Human attribution** — `accessingUserId` names the actual super-admin / `COMPLIANCE_AUDITOR`
+ *    who exercised the see-through, so a retained-data reveal is never anonymous. Non-empty
+ *    (`.trim().min(1)`) — a blank id cannot stand in for a human.
+ * 2. **A required reason** — `reason` is the mandatory justification for revealing scrubbed PII.
+ *    Non-empty (`.trim().min(1)`): a blank OR whitespace-only reason fails validation, so the audit
+ *    trail cannot record a reveal without a real "why". The see-through primitives ALSO fail-closed on
+ *    blank attribution before the read (the schema `.min(1)` is the contract; the primitive guard is
+ *    the enforcement point, since the audit store persists `eventData` as an unparsed record).
+ *
+ * Strictly read-only (the see-through primitive never mutates). Emitted by the see-through read
+ * primitive (`readRetainedAsSystem` / `listRetainedAsSystem`) — wired in a later phase; this is the
+ * contract only.
+ */
+export const AuditableEvent_RetainedDataAccess_EventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.RETAINED_DATA_ACCESS),
+    /** The HUMAN principal who performed the see-through read (super-admin / COMPLIANCE_AUDITOR). Non-empty. */
+    accessingUserId: z.string().trim().min(1),
+    /** REQUIRED non-empty compliance justification for revealing the retained (scrubbed) records — the "why". */
+    reason: z.string().trim().min(1),
+    /** The resource type whose retained rows were revealed. */
+    resourceType: z.string(),
+    /** Present for a single-record see-through read; absent for a list/search reveal. */
+    resourceId: z.string().optional(),
+    /** For a list/search see-through: how many retained rows the query revealed. */
+    retainedRecordCount: z.number().optional(),
+    /** The see-through primitive that ran (e.g. `readRetainedAsSystem` / `listRetainedAsSystem`). */
+    operationIdentifier: z.string(),
+    /** The privileged role(s) that authorized the see-through (roles are the single authorization axis). */
+    roles: z.array(z.string()).optional(),
+    /** Tenant scope of the accessed data (organizationId), when the read was org-scoped. */
+    organizationId: z.string().optional(),
+    ipAddress: z.string().optional(),
+});
+/**
+ * A DATA SUBJECT EXPORT — the compliance record of the framework assembling everything it holds
+ * about one person and disclosing it.
+ *
+ * This is the most sensitive READ the framework performs, and the one an access-request audit turns
+ * on. Its defining properties:
+ *
+ * 1. **A named subject** — `subjectResourceType` + `subjectIds`: WHOSE data left the system. An
+ *    export event that cannot name its subject is not an access record.
+ * 2. **A named purpose** — `purpose` is a `SubjectExportPurpose`. Art. 15 and Art. 20 produce
+ *    genuinely different bundles, so an audit trail that recorded only "an export happened" could
+ *    not later establish which right was answered or whether it was answered completely.
+ * 3. **What was actually included** — `includedResourceTypes` + `totalRecordCount`, and
+ *    `fieldsExcludedAsDerived` for the Art. 20 narrowing. The OMISSIONS matter as much as the
+ *    contents: "why was this not in my export?" must have a recorded answer.
+ *
+ * Carries NO personal data — resource types, ids, counts and field NAMES only. Recording the
+ * exported values would turn the record of a disclosure into a second copy of it, in a store with
+ * a longer retention than the export artifact itself.
+ *
+ * assurance-control: WILDO.PRIVACY.SUBJECT_DATA_EXPORT
+ */
+export const AuditableEvent_SubjectDataExport_EventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.SUBJECT_DATA_EXPORT),
+    /** WHICH data-subject right this export answered — the two produce different bundles. */
+    purpose: z.string().trim().min(1),
+    /** The exported subject's resource type. */
+    subjectResourceType: z.string().trim().min(1),
+    /** The exported subject rows. Non-empty: an export with no subject is not an export. */
+    subjectIds: z.array(z.string()).min(1),
+    /** Every resource that actually contributed rows to the bundle. */
+    includedResourceTypes: z.array(z.string()),
+    /** Total rows disclosed across the whole bundle. */
+    totalRecordCount: z.number(),
+    /**
+     * `resourceType.fieldName` locators omitted from an Art. 20 bundle as controller-derived. Empty
+     * for an Art. 15 access export, which discloses every field regardless of provenance.
+     */
+    fieldsExcludedAsDerived: z.array(z.string()),
+    /**
+     * `resourceType.fieldName` locators withheld as NON-DISCLOSABLE regardless of right — secrets and
+     * backend-only values the export refuses to hand out. Recorded so a thin bundle reads as a
+     * deliberate security floor rather than a missed resource.
+     */
+    fieldsWithheldAsNonDisclosable: z.array(z.string()),
+    /** Tenant scope, when the export ran org-scoped. */
+    organizationId: z.string().optional(),
+});
+/**
+ * A COLLECTION EXPORT — an operator rendered a resource listing to a file and downloaded it.
+ *
+ * ## What it must answer, and what it must never carry
+ *
+ * The reviewer's questions are: which listing, in what shape, and **how much left**. So the row
+ * count is mandatory and the row scope is recorded verbatim — "they exported the page they were
+ * looking at" and "they exported the whole table" are the same action with very different
+ * consequences, and only this field separates them after the fact.
+ *
+ * `filterFieldNames` records WHICH filters narrowed the export, **never their values**. A filter
+ * value is frequently personal data (`?email=…`, `?assigneeId=…`), so recording it would turn the
+ * record of a disclosure into a second copy of it, in a store that outlives the exported file — the
+ * same rule {@link AuditableEvent_SubjectDataExport_EventDataSchema} follows ("resource types, ids,
+ * counts and field NAMES only"). No row content, ever.
+ *
+ * ## Why the severity is static and the risk is not
+ *
+ * `AUDIT_EVENT_CLASSIFICATION_MAP` is keyed by event TYPE, so severity cannot vary per emission.
+ * Classifying every export WARNING would put a routine twenty-row page download beside a whole-table
+ * dump and train reviewers to skim the channel; classifying every export INFO would leave the dump
+ * indistinguishable. The distinction therefore rides on `riskLevel`, which IS per-emission and is an
+ * indexed summary column on the audit row: LOW for a page, HIGH for a full result set.
+ *
+ * *Rejected: two event types.* A page export and a full export are one action with one parameter,
+ * and splitting the vocabulary to vary a field would make every consumer match two types forever.
+ *
+ * assurance-control: WILDO.PRIVACY.COLLECTION_DATA_EXPORT
+ */
+export const AuditableEvent_CollectionDataExport_EventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.COLLECTION_DATA_EXPORT),
+    /** The exported resource. */
+    resourceType: z.string().trim().min(1),
+    /** The LIST/SEARCH operation whose result set was exported. */
+    sourceOperationIdentifier: z.string().trim().min(1),
+    /** `csv` | `json` — the rendered wire format. */
+    format: z.string().trim().min(1),
+    /** `visible_page` | `full_result_set` — see the docstring; this is the field that matters most. */
+    rowScope: z.string().trim().min(1),
+    /** Rows actually written to the file. Mandatory: an export event with no count answers nothing. */
+    rowCount: z.number().int().nonnegative(),
+    /** Names of the filters that narrowed the export. NEVER their values. */
+    filterFieldNames: z.array(z.string()),
+    /** Tenant scope, when the export ran org-scoped. */
+    organizationId: z.string().optional(),
+});
+/**
+ * Rows were read THROUGH an HTTP-API resource binding — the read-through trail for data living in
+ * an EXTERNAL system the platform does not own (ETL plan D8/R6; see the enum member's docstring
+ * for why this is neither SYSTEM_CONTEXT_READ nor COLLECTION_DATA_EXPORT).
+ *
+ * One event per read-family OPERATION execution: a paginated LIST and the count that totals its
+ * envelope are ONE access, not two — the unit a reviewer reasons about is "an operation reached
+ * into the external system", never the transport's call multiplicity. Carries NO row data and no
+ * filter VALUES — the trail must never become a second copy of the external system's content.
+ *
+ * `initiatorUserId` is the REAL initiating user (R12): under a SERVICE_PRINCIPAL binding every
+ * remote call authenticates as one service account, and this field is what keeps attribution
+ * alive through that shared principal. Optional because internal/machine executions genuinely
+ * have no user — absence means "a runtime acted", exactly as `executionType` records.
+ *
+ * assurance-control: WILDO.AUDIT.ATTRIBUTION — read-through access to an external system is
+ * recorded with the real initiating user carried through the shared service principal.
+ */
+export const AuditableEvent_HttpApiReadThroughAccess_EventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.HTTP_API_READ_THROUGH_ACCESS),
+    /** The Wildo resource whose binding was read through. */
+    resourceType: z.string().trim().min(1),
+    /** The read-family member executed: `read` | `list` | `count` | `search`. */
+    operationIdentifier: z.string().trim().min(1),
+    /** The provider the binding resolves credentials/base-URL through (e.g. `odoo`). */
+    providerRef: z.string().trim().min(1),
+    /** The remote entity (OData entity set / Odoo model / declared REST surface). */
+    remoteEntityRef: z.string().trim().min(1),
+    /** The transport dialect spoken (`odata` | `rest-json` | `odoo-jsonrpc`). */
+    dialect: z.string().trim().min(1),
+    /** The REAL initiating user — absent only for genuine machine/internal executions. */
+    initiatorUserId: z.string().optional(),
+    /** The execution type that acted, for the machine/internal cases. */
+    executionType: z.string().optional(),
+    /** Tenant scope, when the read ran org-scoped. */
+    organizationId: z.string().optional(),
+    /** The addressed row's synthesized id, for single-row reads. */
+    resourceId: z.string().optional(),
+    /** Rows returned (list/search), or the count answered (count). Absent for a single READ. */
+    rowCount: z.number().int().nonnegative().optional(),
+});
+/**
+ * A subject erasure invoked the DECLARED external-erasure operation of an HTTP_API binding
+ * (ETL D6 stance 6b) — rows linked to the erased subject were deleted in the external system.
+ *
+ * Carries ids only, never personal fields: by the time this emits, the subject's local row is
+ * scrubbed, and the whole point of the operation was that the remote copies stop existing.
+ *
+ * assurance-control: WILDO.AUDIT.ATTRIBUTION — the outbound deletion names the subject it served
+ * and the external system it reached; the erasure report is the per-request receipt, this row is
+ * the queryable trail.
+ */
+export const AuditableEvent_HttpApiExternalErasure_EventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.HTTP_API_EXTERNAL_ERASURE),
+    /** The erased subject's resource type (e.g. `users`). */
+    subjectResourceType: z.string().trim().min(1),
+    /** The erased subject row ids the deleted remote rows were linked to. */
+    subjectIds: z.array(z.string().trim().min(1)).min(1),
+    /** The HTTP_API-bound Wildo resource whose declared erasure operation ran. */
+    resourceType: z.string().trim().min(1),
+    /** The provider the binding resolves credentials/base-URL through. */
+    providerRef: z.string().trim().min(1),
+    /** The remote entity (OData entity set / Odoo model / declared REST surface). */
+    remoteEntityRef: z.string().trim().min(1),
+    /** The transport dialect spoken (`odata` | `rest-json` | `odoo-jsonrpc`). */
+    dialect: z.string().trim().min(1),
+    /** Remote rows the declared operation deleted (0 is a legitimate nothing-to-erase). */
+    deletedRowCount: z.number().int().nonnegative(),
+    /** Tenant scope, when the erasure request carried one. */
+    organizationId: z.string().optional(),
+});
+/**
+ * A subject erasure COMPLETED while rows linked to the subject remain live in an HTTP_API-bound
+ * external system, on the controller's explicit per-request acknowledgement (ETL D6 stance 6c).
+ *
+ * THE RECORD IS THE CONTROL: the acknowledgement's entire justification is that the hole becomes
+ * VISIBLE rather than prevented (`administrative-continuity-floors.md`), so this event must name
+ * everything a reviewer needs to act — the subject, the resource, the external system, and the
+ * remaining linkage when it could be measured.
+ *
+ * assurance-control: WILDO.AUDIT.ATTRIBUTION — an acknowledged erasure hole is recorded per
+ * resource, per erasure request, never as a standing posture.
+ */
+export const AuditableEvent_HttpApiNonErasureAcknowledged_EventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.HTTP_API_NON_ERASURE_ACKNOWLEDGED),
+    /** The erased subject's resource type (e.g. `users`). */
+    subjectResourceType: z.string().trim().min(1),
+    /** The erased subject row ids whose linked remote rows remain live. */
+    subjectIds: z.array(z.string().trim().min(1)).min(1),
+    /** The HTTP_API-bound Wildo resource whose rows remain un-erased. */
+    resourceType: z.string().trim().min(1),
+    /** The provider the binding resolves credentials/base-URL through. */
+    providerRef: z.string().trim().min(1),
+    /** The remote entity (OData entity set / Odoo model / declared REST surface). */
+    remoteEntityRef: z.string().trim().min(1),
+    /** The transport dialect spoken (`odata` | `rest-json` | `odoo-jsonrpc`). */
+    dialect: z.string().trim().min(1),
+    /**
+     * Remote rows still linked to the subject, when the target answered a count. ABSENT means the
+     * count could not be measured (the count read failed or is undeclared for the binding) — never
+     * write 0 for "unknown": zero is a measured answer.
+     */
+    remainingRowCount: z.number().int().nonnegative().optional(),
+    /** Tenant scope, when the erasure request carried one. */
+    organizationId: z.string().optional(),
+});
+/**
+ * Audit-log event for cross-frontend session handoff issuance
+ * (cross-app-jwt-propagation Step 2).
+ *
+ * Captures who issued a transferable session credential, where it was bound to,
+ * and a hash of the deep-link target so ops can correlate handoff issuance with
+ * the corresponding `tokenExchange` event WITHOUT leaking the raw deep link
+ * (which can carry org IDs, share codes, or draft IDs).
+ *
+ * `returnPathHash` is hex-encoded `sha256(returnPath)` computed by the audit-log
+ * helper from the validated returnPath. NEVER pass a pre-hashed value at the
+ * call site (defense-in-depth: prevents accidental double-hashing or hash
+ * mismatch with what the schema validated).
+ */
+export const AuditableEvent_User_CrossFrontendHandoffIssuedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.USER_CROSS_FRONTEND_HANDOFF_ISSUED),
+    userId: z.string(),
+    /** The `X-Frontend-Service-Name` of the source frontend that initiated the handoff. */
+    sourceFrontendServiceName: z.string().optional(),
+    /** The SaaS-config service key (and runtime `frontendServiceName`) of the target. */
+    targetServiceKey: z.string(),
+    /** SHA-256 hex of the validated returnPath; NEVER the raw path. */
+    returnPathHash: z.string(),
+    /** ID of the issued AUTH_CODE_EXCHANGE consumable token (for replay forensics). */
+    consumableTokenId: z.string(),
+    ipAddress: z.string(),
+    userAgent: z.string(),
+});
+// ── OAuth2 / OIDC Provider Event Data Schemas (Wildo AS the authorization server) ──
+/**
+ * A user-delegated `authorization_code` access token was minted for a third-party client at
+ * `/oauth/token`. This is the most security-sensitive access grant the provider makes: the client
+ * can now act AS the user at the audience-bound A2A/MCP resource. `clientId` is the `azp`
+ * (attribution only — the token carries the USER's authority, not the client's). Never carries the
+ * raw token.
+ */
+export const AuditableEvent_OAuth_DelegatedTokenIssuedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.OAUTH_DELEGATED_TOKEN_ISSUED),
+    /** The delegating (consenting) user — the token subject. */
+    userId: z.string(),
+    /** The third-party client the token was minted for (`azp`). */
+    clientId: z.string(),
+    /** The A2A/MCP resource-server audience the token is confined to. */
+    audience: z.string(),
+    /** Granted identity scopes (openid/…); may be empty. Identity/consent provenance only — no authz weight. */
+    scopes: z.array(z.string()),
+    /** Delegated-token lifetime in seconds (short-lived; never the full session TTL). */
+    ttlSeconds: z.number(),
+    ipAddress: z.string().optional(),
+});
+/** A user APPROVED an interactive consent request — a code is issued and the client may act for them. */
+export const AuditableEvent_OAuth_ConsentGrantedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.OAUTH_CONSENT_GRANTED),
+    /** The user who approved. */
+    userId: z.string(),
+    /** The client the consent was granted to. */
+    clientId: z.string(),
+    /** The scopes consented to. */
+    scopes: z.array(z.string()),
+    /** The RFC 8707 resource the consent was bound to, when present. */
+    resource: z.string().optional(),
+    /** Whether the user asked to persist the grant ("remember this app") — a durable-authority signal. */
+    remembered: z.boolean(),
+    ipAddress: z.string().optional(),
+});
+/** A user DENIED an interactive consent request — access refused. */
+export const AuditableEvent_OAuth_ConsentDeniedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.OAUTH_CONSENT_DENIED),
+    userId: z.string(),
+    clientId: z.string(),
+    scopes: z.array(z.string()),
+    resource: z.string().optional(),
+    ipAddress: z.string().optional(),
+});
+/**
+ * A persistent consent grant (the durable "remember this app" record, keyed on
+ * `(userId, clientId, resource)`) was created or updated — it lets future authorize flows SKIP the
+ * consent prompt, so its lifecycle is a first-class delegated-authority audit concern.
+ */
+export const AuditableEvent_OAuth_ConsentGrantPersistedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.OAUTH_CONSENT_GRANT_PERSISTED),
+    userId: z.string(),
+    clientId: z.string(),
+    /** The RFC 8707 resource the grant covers; absent for an OIDC-only (resource-less) grant. */
+    resource: z.string().optional(),
+    /** The union of scopes the grant now covers after the write. */
+    scopes: z.array(z.string()),
+    /** `true` when a NEW grant row was created; `false` when an existing grant's scopes were widened. */
+    isNewGrant: z.boolean(),
+});
+/**
+ * A CIMD `client_id` URL was refused. Unauthenticated by construction, so the URL, the reason and
+ * the source of the request ARE the investigation surface.
+ */
+export const AuditableEvent_OAuth_CimdClientRefusedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.OAUTH_CIMD_CLIENT_REFUSED),
+    /** The `client_id` URL as presented. Attacker-controlled, so treated as data, never as a locator. */
+    clientId: z.string(),
+    /** Closed vocabulary — branched on by operators and COUNTED, never free text. */
+    reason: z.string(),
+    detail: z.string().optional(),
+});
+/**
+ * A client registered itself at `/oauth/register` (RFC 7591). Unauthenticated by construction, so
+ * the source IP and the self-asserted name/redirects ARE the investigation surface — there is no
+ * principal to attribute it to.
+ */
+export const AuditableEvent_OAuth_DynamicClientRegisteredEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.OAUTH_DYNAMIC_CLIENT_REGISTERED),
+    clientId: z.string(),
+    /** Self-asserted; nobody vetted it. Shown on the consent screen, so worth recording verbatim. */
+    clientName: z.string(),
+    /** The redirect URIs the client claimed — where an authorization code would be delivered. */
+    redirectUris: z.array(z.string()),
+    /**
+     * The POST-LOGOUT redirect URIs the client claimed (revocation-C) — where an RP-Initiated Logout would
+     * send the browser after the session ends. Optional: absent on rows written before the field existed and
+     * for a registration that declared none.
+     */
+    postLogoutRedirectUris: z.array(z.string()).optional(),
+    ipAddress: z.string().optional(),
+});
+/**
+ * A user token was rotated via the provider `refresh_token` grant (`/oauth/token`). Distinct from the
+ * first-party session refresh (`USER_TOKEN_REFRESHED`): this is the OAuth-provider endpoint, which a
+ * confidential client MAY authenticate to. Low-detail INFO — the security-relevant refresh signal is
+ * reuse/theft ({@link CoreAuditableEventType.USER_REFRESH_TOKEN_REUSE_DETECTED}).
+ *
+ * There is deliberately NO `OAUTH_TOKEN_REFRESH_FAILED` counterpart (user-confirmed 2026-07-31): routine
+ * refresh failures (expired / revoked / plain-invalid presented token) are high-volume benign noise from
+ * ended sessions, and auditing them would drown the compliance store. The only refresh-failure worth an
+ * audit record is credential theft, which reuse-detection catches → `USER_REFRESH_TOKEN_REUSE_DETECTED`.
+ */
+export const AuditableEvent_OAuth_TokenRefreshedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.OAUTH_TOKEN_REFRESHED),
+    /** The refreshing user, when resolvable from the freshly-minted access token; else absent. */
+    userId: z.string().optional(),
+    /** The client that authenticated the refresh (confidential-client id_token re-issue path); else absent. */
+    clientId: z.string().optional(),
+    /** Whether a confidential client was authenticated on this refresh (vs a first-party session refresh). */
+    clientAuthenticated: z.boolean(),
+    ipAddress: z.string().optional(),
+});
+/**
+ * A token was revoked via `/oauth/revoke` (RFC 7009). The endpoint is deliberately a no-oracle (200 for
+ * unknown tokens), so this records the ATTEMPT + the authenticated client (if any), never whether the
+ * token existed or whose it was.
+ */
+export const AuditableEvent_OAuth_TokenRevokedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.OAUTH_TOKEN_REVOKED),
+    /** The confidential client that authenticated to revoke, when present. */
+    clientId: z.string().optional(),
+    /** Whether a confidential client authenticated the revocation. */
+    clientAuthenticated: z.boolean(),
+    /** The RFC 7009 `token_type_hint` the caller supplied, when present. */
+    tokenTypeHint: z.string().optional(),
+    ipAddress: z.string().optional(),
+});
+/**
+ * An OIDC RP-Initiated Logout (RP-Initiated Logout 1.0) terminated the End-User's OP session at
+ * `/oauth/end-session` (revocation-C). Records WHO logged out WHICH session via WHICH relying party, and
+ * whether a session was actually terminated / a post-logout redirect was refused. `userId`/`sessionId`/
+ * `clientId` are present only when a valid `id_token_hint` identified them — an invalid or absent hint
+ * still lands the user on the OP's page but terminates nothing.
+ */
+export const AuditableEvent_OAuth_RpInitiatedLogoutEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.OAUTH_RP_INITIATED_LOGOUT),
+    /** The user whose OP session was terminated — present only when a valid `id_token_hint` identified them. */
+    userId: z.string().optional(),
+    /** The terminated login session (the id_token `sid`) — present only when the hint carried one. */
+    sessionId: z.string().optional(),
+    /** The relying party that initiated the logout (the id_token `azp`), when identifiable. */
+    clientId: z.string().optional(),
+    /** Whether a session was actually terminated (a valid hint carrying a `sid` was presented). */
+    sessionTerminated: z.boolean(),
+    /** Whether a presented `post_logout_redirect_uri` was REFUSED because it did not match the client's
+     *  registered allowlist — a misconfiguration / open-redirect-probe signal worth separating from a
+     *  plain no-URI logout. */
+    postLogoutRedirectUriRejected: z.boolean(),
+    ipAddress: z.string().optional(),
+});
+/**
+ * An `authorization_code` exchange was REJECTED at `/oauth/token`. A potential attack signal (code
+ * replay, PKCE downgrade, redirect tampering, cross-client redemption). `reason` names the cause;
+ * `userId`/`resource` are present only for causes detected AFTER the code decodes (never for the
+ * atomic replay/consume failure, which fails before decode).
+ */
+export const AuditableEvent_OAuth_CodeExchangeFailedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.OAUTH_CODE_EXCHANGE_FAILED),
+    /** The specific failure cause (closed vocabulary). */
+    reason: z.enum(OAuthCodeExchangeFailureReason),
+    /** The redeeming client, when the request supplied one. */
+    clientId: z.string().optional(),
+    /** The code's subject, available only for post-decode causes. */
+    userId: z.string().optional(),
+    /** The code's bound resource, available only for post-decode causes. */
+    resource: z.string().optional(),
+    ipAddress: z.string().optional(),
+});
+/**
+ * A consent DECISION was submitted by an authenticated user who is NOT the user the consent request was
+ * bound to (returns 403). A textbook cross-user authorization-abuse signal — user A attempting to act on
+ * user B's pending consent. CRITICAL: records BOTH principals for the SIEM.
+ */
+export const AuditableEvent_OAuth_ConsentBindingViolationEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.OAUTH_CONSENT_BINDING_VIOLATION),
+    /** The authenticated user who submitted the decision (the actor). */
+    authenticatedUserId: z.string(),
+    /** The user the consent request was actually bound to (the victim). */
+    boundUserId: z.string(),
+    /** The client the consent request was for, when known. */
+    clientId: z.string().optional(),
+    /** The consent-request consumable-token id, for replay forensics. */
+    consentTokenId: z.string().optional(),
+    ipAddress: z.string().optional(),
+});
+/**
+ * Refresh-token REUSE was detected → the whole token family was revoked (possible theft). Emitted by the
+ * refresh CALLERS, NOT the token issuer: the issuer stays audit-free by design (it performs the revoke and
+ * surfaces a machine-readable reuse SIGNAL on its thrown error), and each caller decides to audit. Applies
+ * to BOTH the first-party session refresh and the OAuth-provider refresh grant (shared issuer).
+ */
+export const AuditableEvent_User_RefreshTokenReuseDetectedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.USER_REFRESH_TOKEN_REUSE_DETECTED),
+    /** The user whose token family was revoked (the victim). */
+    userId: z.string(),
+    /** The reused refresh token's `jti` (the replayed credential id) — never the raw token. */
+    reusedJti: z.string(),
+    /** The session the reused token belonged to, when present on the claim. */
+    sessionId: z.string().optional(),
+    /** Whether the family-wide revocation (`TOKEN_INVALID_BEFORE`) was written — the action taken. */
+    familyRevoked: z.boolean(),
+    ipAddress: z.string().optional(),
 });
 // MongoDB-compatible schema using simple object for eventData
 // The discriminated union validation will be handled at the service layer
 export const AuditableEvent_DataSchema = z.record(z.string(), z.any());
 export const AuditableEvent_BaseSchema = z.object({
     _id: z.string().isPrimaryKey().isSummaryField(),
+    /**
+     * Store-agnostic, server-minted correlation key (UUID). The Mongo `_id` is
+     * THIS store's primary key, but immudb (and any future audit sink) has its
+     * own native key — so cross-store correlation needs an id that belongs to the
+     * EVENT, not to one store. Minted in `AuditLogsBackendService._createAuditLog`
+     * BEFORE the DB write and carried on BOTH the DB row AND the provider fan-out
+     * emission, so the Phase-3 completeness reconciler can match DB rows ⇄ immudb
+     * records (and `AuditLogVerification.verifyAuditEvent(eventId)` resolves the
+     * same key). Not the primary key: `_id` stays the DB PK.
+     */
+    eventId: z.string().isDBIndexed(),
     // Note: .optional() must come AFTER decorators to preserve optionality in TypeScript type inference
     userId: z.string().isSummaryField().optional(),
+    /**
+     * The org the event is ABOUT (event DATA) — e.g. the org whose SSO config changed, or the
+     * org resolved from a login email's domain. **NEVER a routing key.** Per-org SIEM / sink
+     * dispatch routes ONLY on the AUTHENTICATED request org
+     * (`ExecutionContext.initiatorIds.organizationId`) — this field is attacker-influenceable on
+     * pre-auth paths (a failed-login email domain → org lookup), so routing on it would leak one
+     * tenant's events into another tenant's SIEM (F4). See `AuditLogsBackendService._createAuditLog`.
+     *
+     * ## Why an attacker-influenceable value is nonetheless SAFE to persist here
+     *
+     * Recorded 2026-08-05, when this field stopped being silently dropped on write (see
+     * `_createAuditLog`'s `preserveServerInjectedFields` call). The change makes a value an
+     * unauthenticated caller can influence both durable and, on the org-scoped viewer, VISIBLE — so
+     * the two channels it could reach were each checked rather than assumed.
+     *
+     * 1. **SIEM delivery — unaffected.** Per-org dispatch keys on the AUTHENTICATED request org, never
+     *    on this field (F4, above). Persisting it changes no routing decision, so the cross-tenant
+     *    SIEM leak F4 exists to prevent is not reachable through it.
+     * 2. **In-product visibility — intended, not a leak.** `ORGANIZATIONS → AUDIT_LOGS` is
+     *    `REQUIRES_CONTEXT` on `organizationId`, so this value decides which org sees the row in the
+     *    org-scoped Audit Log Viewer. A failed-login row surfacing in the org whose user was targeted
+     *    is the CORRECT outcome — a tenant seeing authentication attempts against its own members is
+     *    the purpose of an audit log, not a disclosure. Nothing about a third org is exposed: the row
+     *    describes the attempt itself.
+     *
+     * **Residual, stated rather than hidden:** an unauthenticated caller can therefore cause rows to
+     * appear in a NAMED org's viewer (log injection / noise) by choosing the email domain it probes.
+     * Bounded to rows describing that caller's own attempt against that org, which is the org already
+     * being attacked and the party with the strongest reason to see them. Volume abuse is bounded by
+     * the authentication rate limiters, not by this field. If a future review wants that noise
+     * separated, the fix is a provenance discriminator on the row (authenticated vs. domain-resolved
+     * org), NOT dropping the field again — dropping it is what made the viewer's org filter return
+     * nothing at all.
+     *
+     * assurance-control: WILDO.ACCESS.SCOPE_CONFINEMENT — tenant segregation of the audit trail is
+     * enforced on the authenticated scope, while the subject org retains visibility of events
+     * concerning it.
+     */
     organizationId: z.string().isSummaryField().optional(),
+    /**
+     * The application the event is ABOUT when its owning tenant is application-scoped.
+     * Like `organizationId`, this is forensic event data and never a per-org SIEM routing key.
+     */
+    applicationId: z.string().isSummaryField().optional(),
+    /**
+     * The request-correlation id (see `ExecutionContext.correlationId`) — groups every audit row produced
+     * by ONE request / job / cron tick, and equals the `correlationId` stamped on that request's structured
+     * log lines and errors, so an investigator can pivot audit ⇄ logs ⇄ error by a single id. Populated by
+     * `_createAuditLog` from the request `ExecutionContext` when threaded, else from the ambient
+     * request-context ALS frame — that fallback is what finally populates it on the COMMON emit path (most
+     * emitters pass no EC). Indexed for correlation queries. Store-agnostic like `eventId`, but distinct:
+     * `eventId` correlates ONE event across audit stores; `correlationId` correlates MANY events to one request.
+     */
+    correlationId: z.string().isDBIndexed().isSummaryField().optional(),
+    /**
+     * Which frontend SURFACE the request originated from (`x-frontend-service-name`: app / website / docs),
+     * captured at the HTTP edge into the request-context frame and hoisted here by `_createAuditLog`. Origin
+     * attribution — "where did this action come from". Absent for non-HTTP (job / cron / internal) events.
+     */
+    frontendServiceName: z.string().isSummaryField().optional(),
+    /**
+     * Which browser/device INSTALL the request came from (`x-client-instance-id`) — the axis that lets a
+     * reviewer group one actor's activity ACROSS sessions and logins, which `correlationId` (one request)
+     * and `frontendServiceName` (which surface) cannot. Captured at the HTTP edge into the request-context
+     * frame and hoisted here by `_createAuditLog`, exactly like `frontendServiceName`.
+     *
+     * **Populated ONLY when the application authored a non-`DISABLED` `compliance.clientInstanceIdScope`
+     * (OPT-IN, default OFF — Fork D / SD9).** Absent for every unopted application, for non-HTTP events
+     * (job / cron / internal), and whenever the client sent no id. It is a pseudonymous identifier under
+     * GDPR Art 4(5), so it carries obligations the other correlation columns do not — see
+     * `ClientInstanceIdScope` and `.claude/plans/traceability-correlation-id.md` (SD9).
+     *
+     * Deliberately DISTINCT from (never merged with, per SD8): `anonymousUserId` (an identity the app
+     * assigns a pre-auth PERSON), `DeviceInfoSchema.fingerprint` (a derived/probabilistic device
+     * signature), and `clientId` (the OAuth `azp` — which SOFTWARE client, already on the row).
+     */
+    // GDPR Art. 4(5) pseudonymised data by this field's own JSDoc above — so it is personal data, and
+    // a notice must enumerate it. IDENTITY: it is an identifier assigned to a person's client, not an
+    // observation of what they did.
+    clientInstanceId: z.string().isDBIndexed().isSummaryField().optional()
+        .dataCategories(PersonalDataCategory.IDENTITY),
     riskLevel: z.enum(ResourceOperationRiskLevel).isSummaryField(),
-    eventType: z.string().isSummaryField(),
-    eventData: AuditableEvent_DataSchema,
+    // USAGE — an audit row is a record of what a principal DID. The event type and its data together
+    // are the observation, so both carry the category; `riskLevel`, `eventCategory` and `severity` are
+    // the framework's CLASSIFICATION of the event rather than data about the person, and carry none.
+    //
+    // ⚠️ The reverse of the `.isAuditEvidence()` rule, and deliberately so. That marker decides which
+    // FIELD VALUES get copied INTO an audit row, and personal data must never be marked, because the
+    // immutable ledger cannot be scrubbed. This declaration is about the audit row's OWN fields, which
+    // hold personal data whether or not anyone wanted them to — and a notice must say so precisely
+    // BECAUSE they are unerasable.
+    eventType: z.string().isSummaryField().dataCategories(PersonalDataCategory.USAGE),
+    eventData: AuditableEvent_DataSchema.dataCategories(PersonalDataCategory.USAGE),
     /** Populated by service layer via getAuditEventClassification(). Required for CREATE (audit logs are REPOSITORY_ONLY, no API). */
     eventCategory: z.enum(AuditEventCategory).isSummaryField(),
     /** Populated by service layer via getAuditEventClassification(). Required for CREATE (audit logs are REPOSITORY_ONLY, no API). */
@@ -591,7 +2770,13 @@ export const AuditableEvent_TypedDataSchema = z.discriminatedUnion('eventType',
     AuditableEvent_User_LogoutEventDataSchema,
     AuditableEvent_User_LoginFailedEventDataSchema,
     AuditableEvent_User_AccountLockedEventDataSchema,
+    AuditableEvent_MachineAuth_SuccessEventDataSchema,
+    AuditableEvent_MachineAuth_FailedEventDataSchema,
+    AuditableEvent_MachineAccess_EventDataSchema,
     AuditableEvent_User_SessionExpiredEventDataSchema,
+    AuditableEvent_User_AppRolesChangedEventDataSchema,
+    AuditableEvent_Application_SuperAdminFloorBreachedEventDataSchema,
+    AuditableEvent_Organization_OwnerFloorBreachedEventDataSchema,
     AuditableEvent_OrganizationMember_InvitedEventDataSchema,
     AuditableEvent_OrganizationMember_JoinedEventDataSchema,
     AuditableEvent_OrganizationMember_UpdatedEventDataSchema,
@@ -601,16 +2786,26 @@ export const AuditableEvent_TypedDataSchema = z.discriminatedUnion('eventType',
     AuditableEvent_Organization_CreatedEventDataSchema,
     AuditableEvent_Organization_UpdatedEventDataSchema,
     AuditableEvent_Organization_DeletedEventDataSchema,
+    AuditableEvent_Organization_DeletionRequestedEventDataSchema,
+    AuditableEvent_Organization_RestoredEventDataSchema,
+    AuditableEvent_Organization_SuspendedEventDataSchema,
+    AuditableEvent_Resource_StatusTransitionPerformedEventDataSchema,
+    AuditableEvent_Organization_ActivatedEventDataSchema,
     AuditableEvent_OrganizationNotifications_UpdatedEventDataSchema,
     AuditableEvent_OrganizationPreferences_UpdatedEventDataSchema,
     AuditableEvent_OrganizationProfile_UpdatedEventDataSchema,
     AuditableEvent_OrganizationUnit_UpdatedEventDataSchema,
+    AuditableEvent_OrganizationUnitMember_RoleChangedEventDataSchema,
+    AuditableEvent_OrganizationUnitMember_RemovedEventDataSchema,
+    AuditableEvent_User_DeletedEventDataSchema,
     AuditableEvent_User_SSOLoginEventDataSchema,
     AuditableEvent_User_SSOLoginFailedEventDataSchema,
     AuditableEvent_User_SSOEnforcementBlockedEventDataSchema,
     AuditableEvent_User_TokenRefreshedEventDataSchema,
     AuditableEvent_Organization_SSOConfigurationChangedEventDataSchema,
     AuditableEvent_Organization_SIEMExportConfiguredEventDataSchema,
+    AuditableEvent_ApplicationAuthPolicyChanged_EventDataSchema,
+    AuditableEvent_Webhook_EndpointTestDispatchedEventDataSchema,
     AuditableEvent_SCIM_TokenCreatedEventDataSchema,
     AuditableEvent_SCIM_TokenRevokedEventDataSchema,
     AuditableEvent_SCIM_UserProvisionedEventDataSchema,
@@ -618,6 +2813,7 @@ export const AuditableEvent_TypedDataSchema = z.discriminatedUnion('eventType',
     AuditableEvent_SCIM_UserDeactivatedEventDataSchema,
     AuditableEvent_User_PasswordResetRequestedEventDataSchema,
     AuditableEvent_User_PasswordResetCompletedEventDataSchema,
+    AuditableEvent_User_PasswordResetForcedEventDataSchema,
     AuditableEvent_User_RegisteredEventDataSchema,
     AuditableEvent_User_EmailVerifiedEventDataSchema,
     AuditableEvent_User_VerificationEmailResentEventDataSchema,
@@ -639,5 +2835,27 @@ export const AuditableEvent_TypedDataSchema = z.discriminatedUnion('eventType',
     AuditableEvent_OAuth2ProviderBlockedEventDataSchema,
     AuditableEvent_EmergencyAccess_UsedEventDataSchema,
     AuditableEvent_FieldAccess_EventDataSchema,
+    AuditableEvent_ResourceOperationPerformed_EventDataSchema,
+    AuditableEvent_ResourceOperationDenied_EventDataSchema,
+    AuditableEvent_CrossTenantAdministrativeAccess_EventDataSchema,
+    AuditableEvent_PlatformDirectoryAccess_EventDataSchema,
+    AuditableEvent_PlatformAccessGrantLifecycle_EventDataSchema,
+    AuditableEvent_RetainedDataAccess_EventDataSchema,
+    AuditableEvent_SubjectDataExport_EventDataSchema,
+    AuditableEvent_CollectionDataExport_EventDataSchema,
+    AuditableEvent_HttpApiReadThroughAccess_EventDataSchema,
+    AuditableEvent_HttpApiExternalErasure_EventDataSchema,
+    AuditableEvent_HttpApiNonErasureAcknowledged_EventDataSchema,
+    AuditableEvent_User_CrossFrontendHandoffIssuedEventDataSchema,
+    AuditableEvent_OAuth_DelegatedTokenIssuedEventDataSchema,
+    AuditableEvent_OAuth_ConsentGrantedEventDataSchema,
+    AuditableEvent_OAuth_ConsentDeniedEventDataSchema,
+    AuditableEvent_OAuth_ConsentGrantPersistedEventDataSchema,
+    AuditableEvent_OAuth_TokenRefreshedEventDataSchema,
+    AuditableEvent_OAuth_TokenRevokedEventDataSchema,
+    AuditableEvent_OAuth_RpInitiatedLogoutEventDataSchema,
+    AuditableEvent_OAuth_CodeExchangeFailedEventDataSchema,
+    AuditableEvent_OAuth_ConsentBindingViolationEventDataSchema,
+    AuditableEvent_User_RefreshTokenReuseDetectedEventDataSchema,
 ]);
-//# sourceMappingURL=auditable-events.shared.schema.js.map
+//# sourceMappingURL=auditable-events.shared.schema.js.map