@wildo-ai/saas-models 1.1.2 → 1.1.4

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

@@ -2,10 +2,11 @@ import { z } from "zod";
 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 { PlatformAccessGrantAutoApprovalReason, PlatformAccessGrantLifecycleTransition, PlatformAccessGrantScope, 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";
+import { ProviderCredentialDeletionReason, ProviderCredentialResolutionSource, } from "../../security/connected-accounts/provider-credentials.shared.schemas.js";
 export var CoreAuditableEventType;
 (function (CoreAuditableEventType) {
     // Authentication Events
@@ -172,6 +173,55 @@ 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";
+    // Organization Provider Credential Events
+    //
+    // An organization's OWN credential toward a third party. The four verbs are separate members
+    // rather than one event with a `changeType`, because they answer four different questions a
+    // credential incident asks in a different order — when did this tenant grant us authority, when
+    // did the value last change, when was it last SPENT, and when did the grant end — and a SIEM
+    // rule that alerts on a spend cannot be written against a payload discriminator that also
+    // matches configuration edits.
+    //
+    // NONE of the four payloads carries the credential value. That is a structural property of the
+    // schemas below, not a redaction step somebody has to remember: there is no field to put it in.
+    //
+    // assurance-control: WILDO.IDENTITY.DELEGATED_AUTHORIZATION — an organization authorizes this
+    // application to act as it toward a named third party.
+    CoreAuditableEventType["ORGANIZATION_PROVIDER_CREDENTIAL_SET"] = "organization_provider_credential_set";
+    CoreAuditableEventType["ORGANIZATION_PROVIDER_CREDENTIAL_ROTATED"] = "organization_provider_credential_rotated";
+    CoreAuditableEventType["ORGANIZATION_PROVIDER_CREDENTIAL_USED"] = "organization_provider_credential_used";
+    CoreAuditableEventType["ORGANIZATION_PROVIDER_CREDENTIAL_DELETED"] = "organization_provider_credential_deleted";
+    // A PERSON's own credential toward a third party. Four members mirroring the organization's,
+    // and deliberately NOT the same members with a nullable organization: the subject differs, the
+    // SIEM routing differs (there is no tenant to route to), and the data-protection reading differs
+    // — a person's connection to a vendor is that person's, and an event saying so must not be
+    // indistinguishable from one about a tenant's shared integration.
+    CoreAuditableEventType["USER_PROVIDER_CREDENTIAL_SET"] = "user_provider_credential_set";
+    CoreAuditableEventType["USER_PROVIDER_CREDENTIAL_ROTATED"] = "user_provider_credential_rotated";
+    CoreAuditableEventType["USER_PROVIDER_CREDENTIAL_USED"] = "user_provider_credential_used";
+    CoreAuditableEventType["USER_PROVIDER_CREDENTIAL_DELETED"] = "user_provider_credential_deleted";
+    // A delegated authorization GRANTED at a vendor, for each owner scope.
+    //
+    // Distinct from `_SET` rather than a flag on it, on the same three grounds the vocabulary already
+    // uses to separate its members. The ACT differs: `_SET` is a value arriving in a row, and this is
+    // a principal completing a consent ceremony at a third party — the only event in this family that
+    // records somebody deciding something. The DATA differs: a grant carries the scopes that were
+    // authorized and the vendor account they were authorized for, neither of which exists for a pasted
+    // secret. And the EMISSION POINT differs, which is what makes a flag impractical as well as wrong:
+    // `_SET` is emitted by the resource's write hook, which sees the row after the value is sealed,
+    // while the scopes are known only to the store that received the grant, before sealing.
+    //
+    // The distinction is the one an auditor asks for first. "Which of our people granted a third party
+    // access, to what, and when" is a different question from "which credentials were configured", and
+    // a trail that answers them with the same event answers neither well.
+    //
+    // Neither payload carries a token, and as with the four above that is structural rather than a
+    // redaction step: there is no field to put one in.
+    //
+    // assurance-control: WILDO.IDENTITY.DELEGATED_AUTHORIZATION — the act of authorizing is recorded
+    // as itself, with what was authorized.
+    CoreAuditableEventType["ORGANIZATION_PROVIDER_CONNECTION_GRANTED"] = "organization_provider_connection_granted";
+    CoreAuditableEventType["USER_PROVIDER_CONNECTION_GRANTED"] = "user_provider_connection_granted";
     // 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
@@ -232,6 +282,7 @@ export var CoreAuditableEventType;
     CoreAuditableEventType["USER_PASSKEY_AUTHENTICATION_SUCCESS"] = "user_passkey_authentication_success";
     CoreAuditableEventType["USER_PASSKEY_AUTHENTICATION_FAILURE"] = "user_passkey_authentication_failure";
     CoreAuditableEventType["USER_PASSKEY_REMOVED"] = "user_passkey_removed";
+    CoreAuditableEventType["USER_PASSKEY_CLONE_SUSPECTED"] = "user_passkey_clone_suspected";
     // Magic Link Events (Phase G2)
     CoreAuditableEventType["USER_MAGIC_LINK_SENT"] = "user_magic_link_sent";
     CoreAuditableEventType["USER_MAGIC_LINK_VERIFIED"] = "user_magic_link_verified";
@@ -255,6 +306,17 @@ export var CoreAuditableEventType;
     CoreAuditableEventType["SAML_EMAIL_CHANGED"] = "saml_email_changed";
     // OAuth2 Provider Restriction Events (Phase G3)
     CoreAuditableEventType["OAUTH2_PROVIDER_BLOCKED"] = "oauth2_provider_blocked";
+    /**
+     * An enterprise OIDC login was refused because the identity provider did not report the
+     * authentication context the connection DEMANDED (issue #444).
+     *
+     * `acr_values` is a REQUEST parameter: the relying party asks, the provider decides, and the ID
+     * token's `acr` claim reports what actually happened. So a refusal here is the only evidence that
+     * a step-up demand was made and not met — without it an operator debugging "why can this person
+     * not sign in" sees an ordinary authentication failure and has nothing to distinguish it from a
+     * wrong password.
+     */
+    CoreAuditableEventType["OIDC_ACR_DEMAND_UNSATISFIED"] = "oidc_acr_demand_unsatisfied";
     // One-Off Session Events (W7.3b)
     /**
      * File upload grant lifecycle (issue #312) — the first FILE-domain audit events. A grant is a
@@ -267,6 +329,37 @@ export var CoreAuditableEventType;
     CoreAuditableEventType["FILE_UPLOAD_GRANT_ISSUED"] = "file_upload_grant_issued";
     CoreAuditableEventType["FILE_UPLOAD_GRANT_REDEEMED"] = "file_upload_grant_redeemed";
     CoreAuditableEventType["FILE_UPLOAD_GRANT_REVOKED"] = "file_upload_grant_revoked";
+    // File content-inspection outcomes (#506)
+    /**
+     * A scanner concluded that an uploaded file is INFECTED, and the file was quarantined.
+     *
+     * Until this existed, the scanner emitted no audit row of any kind: an infection produced a
+     * `SCANNING → INFECTED → QUARANTINED` status transition on the file record and nothing else, so
+     * the only way to learn that malware had reached the application's storage was to NOTICE a row
+     * sitting at `QUARANTINED` — a poll, not a signal. Malware arriving is one of the few things an
+     * operator wants to be alerted on, and one of the few a customer security questionnaire asks about
+     * by name.
+     *
+     * `CRITICAL`, on the same argument as `USER_PASSKEY_CLONE_SUSPECTED`: a conclusion the security
+     * mechanism reached about a real threat, not a routine outcome.
+     *
+     * assurance-control: WILDO.SECURITY.INGESTED_CONTENT_INSPECTION — a detected infection is
+     * attributable and monitorable, not only visible as a row status. This event is the RECORD half of
+     * that objective; the mechanism half is the fail-closed scan gate itself.
+     */
+    CoreAuditableEventType["FILE_MALWARE_DETECTED"] = "file_malware_detected";
+    /**
+     * A scan could NOT be completed — the scanner was unreachable, or the pipeline errored.
+     *
+     * Its own event rather than a lower severity on the one above, because the operational stories are
+     * opposite: an infection means the control WORKED, a failure means it DID NOT RUN. From outside
+     * they are indistinguishable today — the file is non-downloadable either way — which is precisely
+     * why the trail has to tell them apart. A run of these means files are arriving unscanned.
+     *
+     * `WARNING`, not `CRITICAL`: nothing was found and nothing was exposed, because the file fails
+     * closed to `FAILED` and stays undownloadable. What is wrong is the control's availability.
+     */
+    CoreAuditableEventType["FILE_MALWARE_SCAN_FAILED"] = "file_malware_scan_failed";
     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. */
@@ -354,6 +447,13 @@ export var CoreAuditableEventType;
      * crossing is NAMED in the trail". Before this event, an operator could enumerate every user's
      * email across every tenant and leave nothing behind.
      *
+     * ⚠️ "Structurally unavailable" above is exact about the EXISTING grant mechanism — it needs a
+     * target tenant and a collection call names none — and must not be read as "prevention is
+     * impossible". An application-wide grant kind is buildable; what blocks it is the question of who
+     * approves an elevation that names no tenant. See
+     * `ScopeRootConfinementDisposition.UNCONFINED_APPLICATION_TIER_DIRECTORY`, which owns that
+     * reasoning beside the declaration that makes this read unconfined.
+     *
      * 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.
@@ -384,7 +484,8 @@ export var CoreAuditableEventType;
     // 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 —
+    // that acted; this read is HUMAN-ATTRIBUTED (an application super-administrator, the only role the
+    // see-through gate admits today) 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";
@@ -437,6 +538,82 @@ export var CoreAuditableEventType;
     // 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";
+    // The application CALLED a declared operation on a third-party provider — one event per outbound
+    // call, on both the success and the failure path.
+    //
+    // Distinct from the three HTTP_API_* members above, which are the ETL read-through plane: those
+    // record a RESOURCE whose rows live elsewhere being read or erased through a binding. This is the
+    // other door — a custom backend service naming a provider and an operation directly — and the
+    // question it answers is the first question of any provider incident: WHOSE third-party account
+    // did we spend, on whose behalf, and what came back. `connectionOwnerScope`/`connectionOwnerId`
+    // are what the initiator's own ids cannot answer, because one execution may legitimately spend
+    // several tenants' accounts (a user action fanning out to every organization that user belongs to
+    // issues N calls with N owners under ONE initiator).
+    //
+    // Distinct from `*_PROVIDER_CREDENTIAL_USED`, which records that a stored credential was SPENT and
+    // what the vendor thought of it. That one is about the CREDENTIAL's health and is emitted by the
+    // store; this one is about the ACT and is emitted by the executor. A credential incident reads
+    // both, in that order, and folding them would make "which calls did this credential make" a query
+    // nobody can write.
+    //
+    // Classified DATA_ACCESS / INFO for the read-through member's reason — routine, authorized
+    // activity whose value is the queryable trail, not an alarm. The READ/WRITE axis rides
+    // `classification` in the payload and the per-emission `riskLevel`, never the static severity.
+    //
+    // assurance-control: WILDO.AUDIT.ATTRIBUTION — an outbound call made on a user's behalf is
+    // recorded with the real initiating user carried through whichever account it spent.
+    CoreAuditableEventType["PROVIDER_OPERATION_CALL"] = "provider_operation_call";
+    // An AGENT reached an MCP server on somebody's behalf (#491).
+    //
+    // A sibling of `PROVIDER_OPERATION_CALL`, not a case of it, and the split is the same one that
+    // separates that member from `*_PROVIDER_CREDENTIAL_USED`: they identify different acts. A
+    // provider operation is a CATALOGUE operation — it has an `operationId`, a `domain`, an HTTP
+    // method and a declared READ/WRITE classification. An MCP tool has none of those: the tool list is
+    // discovered from the server at turn start, the transport is always a JSON-RPC POST, and nothing
+    // declares in advance what a tool does. Folding them would make "which catalogue operations ran"
+    // a query that returns tools that are not catalogue operations.
+    //
+    // The ATTRIBUTION fields are deliberately identical, so a reviewer asking "what did this person's
+    // delegated credential do at that vendor" writes one shape of query across both.
+    //
+    // Classified DATA_ACCESS / INFO for the same reason as its sibling: routine authorized activity
+    // whose value is the queryable trail rather than an alarm. A refused outbound TARGET is carried on
+    // the same event through `failureKind`, because an attempted egress a guard blocked is exactly
+    // what a reviewer wants beside the calls that succeeded.
+    //
+    // assurance-control: WILDO.AUDIT.ATTRIBUTION — an agent's outbound tool call is recorded with the
+    // real initiating user carried through whichever account it spent.
+    CoreAuditableEventType["MCP_TOOL_CALL"] = "mcp_tool_call";
+    // A human APPROVER changed a proposed tool call's arguments and approved the changed call (#566).
+    //
+    // The strongest act available on the approval plane, and the reason it is its own member rather
+    // than a flag on some broader "approval decided" event: on every other decision the approver
+    // ASSENTS to a call the model authored, and here they AUTHOR one the model never proposed. An
+    // incident reader asking "who wrote the arguments this tool ran with" is asking a different
+    // question from "who let it run", and folding the two would make the first unanswerable by query.
+    //
+    // Emitted ONLY when the executed input differs from the proposed one. An ordinary approval is not
+    // this event and is deliberately not recorded here — the plane has no approval-decision trail at
+    // all yet, which is a separate gap with its own issue; adding half of one under this name would
+    // make `mcp_tool_call`'s mistake in the other direction, an event that answers two questions and
+    // neither well.
+    //
+    // NAMES AND DIGESTS ONLY — never argument values. Identical reasoning to
+    // `RESOURCE_OPERATION_PERFORMED`'s `changedFields` / `fieldEvidence` split: audit rows replicate
+    // to the per-org SIEM and to an immutable ledger that cannot be scrubbed, so copying arbitrary
+    // tool arguments here would manufacture an unerasable duplicate of whatever a person typed, in
+    // direct conflict with GDPR Art. 17. The two digests prove executed ≠ proposed; the key names say
+    // WHICH arguments a person authored. Neither can leak content.
+    //
+    // Classified AUTHORIZATION / WARNING. Authorization because the act IS a human authorization
+    // decision, not a data access. WARNING rather than CRITICAL for the same reading the OAuth grant
+    // rows take: it is notable, dashboard-worthy and worth reviewing, and it is an AUTHORIZED action
+    // taken by an identified person with the pause in front of them — reserving CRITICAL for the rows
+    // that mean something is wrong is what keeps a severity filter usable.
+    //
+    // assurance-control: WILDO.ACCESS.AUTHORIZATION_DECISION_AUDIT — the approver who authored the
+    // executed arguments is recorded beside proof that they differed from the proposal.
+    CoreAuditableEventType["AGENT_TOOL_APPROVAL_MODIFIED"] = "agent_tool_approval_modified";
     // ── 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
@@ -527,6 +704,38 @@ export var AuditEventSeverity;
     AuditEventSeverity["WARNING"] = "warning";
     AuditEventSeverity["CRITICAL"] = "critical";
 })(AuditEventSeverity || (AuditEventSeverity = {}));
+/**
+ * What each audit category and severity MEANS to whoever reads the trail.
+ *
+ * The words were authored, correctly, in the technical-documentation catalog that renders the
+ * audit-trail page — and lived only there, so the same vocabularies reached every other surface as
+ * bare tokens. Moved here, beside the enums, because a vocabulary's words belong with the
+ * vocabulary: the catalog now imports them, the schemas describe their own fields from them, and
+ * there is one account of what `data_access` selects rather than two that can disagree.
+ *
+ * `name` is what a reader is shown; `meaning` is what selecting it actually gets them. Exhaustive by
+ * type, so a sixth category cannot ship as a bare value.
+ */
+export const AUDIT_EVENT_CATEGORY_MEANINGS = {
+    [AuditEventCategory.AUTHENTICATION]: { name: 'Authentication', meaning: 'Signing in, signing out, second factors and failed attempts.' },
+    [AuditEventCategory.AUTHORIZATION]: { name: 'Authorization', meaning: 'Access decisions: what an identity was allowed or refused.' },
+    [AuditEventCategory.USER_LIFECYCLE]: { name: 'User lifecycle', meaning: 'Accounts created, changed, suspended, restored or removed.' },
+    [AuditEventCategory.ORG_MANAGEMENT]: { name: 'Organization management', meaning: 'Membership, roles, units and organization settings.' },
+    [AuditEventCategory.DATA_ACCESS]: { name: 'Data access', meaning: 'Reads and changes of application data that are recorded for review.' },
+};
+export const AUDIT_EVENT_SEVERITY_MEANINGS = {
+    [AuditEventSeverity.INFO]: { name: 'Information', meaning: 'Expected activity. Useful as evidence, not a signal on its own.' },
+    [AuditEventSeverity.WARNING]: { name: 'Warning', meaning: 'Unusual or refused activity worth reviewing in context.' },
+    [AuditEventSeverity.CRITICAL]: { name: 'Critical', meaning: 'Activity that should reach whoever handles security incidents.' },
+};
+/**
+ * A `Values:` legend in the shape the generated API reference already uses, so a field described
+ * here reads exactly like one described from a resource specification.
+ */
+export function describeAuditVocabulary(lead, meanings) {
+    const legend = Object.entries(meanings).map(([value, words]) => `- \`${value}\`: ${words.meaning}`).join('\n');
+    return `${lead}\n\nValues:\n${legend}`;
+}
 /**
  * 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.
@@ -588,6 +797,22 @@ export var ResourceOperationDenialReason;
      * becoming an existence oracle.
      */
     ResourceOperationDenialReason["SUBJECT_NOT_RESOLVABLE"] = "subject_not_resolvable";
+    /**
+     * The caller holds the ROLE but no usable APPLICATION-WIDE elevation.
+     *
+     * Its own member rather than `INSUFFICIENT_ROLES`, and the distinction is the whole point of the
+     * grant model: the caller IS an administrator and the refusal is about STANDING privilege, not
+     * about authority. Folding it into the roles reason would make the two indistinguishable in the
+     * trail — and a reviewer asking "did zero-standing-privilege actually bite anyone?" would have no
+     * way to count it.
+     *
+     * Distinct from a tenant crossing refused for the same shape of reason: that one is refused inside
+     * `authorizeOrganizations` and surfaces as `SCOPE_MISMATCH`, because there the caller genuinely is
+     * outside the tenant. Here there is no tenant to be outside of.
+     *
+     * assurance-control: WILDO.ACCESS.AUTHORIZATION_DECISION_AUDIT
+     */
+    ResourceOperationDenialReason["APPLICATION_WIDE_ELEVATION_MISSING"] = "application_wide_elevation_missing";
 })(ResourceOperationDenialReason || (ResourceOperationDenialReason = {}));
 /** SSO configuration change type. */
 export var SsoConfigChangeType;
@@ -912,20 +1137,66 @@ export const AuditableEvent_Application_SuperAdminFloorBreachedEventDataSchema =
  * 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.
  */
+/**
+ * HOW a tenant's owner-floor breach came to be known.
+ *
+ * The two answers mean genuinely different things to whoever reads the record, and a reader cannot
+ * tell them apart from the rest of the payload — which is why this is a named member rather than an
+ * inference from whether the action fields happen to be present.
+ *
+ * The event type stays SINGLE across both, deliberately. The fact recorded is "this tenant has no
+ * administratively usable owner", and that is the query an operator needs to be one query: splitting
+ * it in two would mean a breach is missed by whichever half somebody alerts on.
+ */
+export var AdministrativeContinuityBreachDetection;
+(function (AdministrativeContinuityBreachDetection) {
+    /**
+     * A guarded lifecycle write was ALLOWED through and stranded the tenant.
+     *
+     * The permissive branch is deliberate — refusing a suspension would mean an operator cannot lock
+     * out a compromised owner without first transferring ownership using the tenant the attacker
+     * controls — so this record IS the control that makes the trade acceptable. The action fields are
+     * populated here, because there is an action to name.
+     */
+    AdministrativeContinuityBreachDetection["ALLOWED_LIFECYCLE_ACTION"] = "allowed_lifecycle_action";
+    /**
+     * The boot report found the tenant ALREADY stranded, by a route no guard ever saw: a direct
+     * database edit, a restore from a backup taken mid-erasure, a seed that authored no owner, or a
+     * role-table change that redefined which roles confer ownership.
+     *
+     * There is no action to name, so the action fields are absent rather than filled with placeholders
+     * — the same reading `logApplicationSuperAdminFloorBreached` takes for its missing `userId`.
+     */
+    AdministrativeContinuityBreachDetection["BOOT_REPORT"] = "boot_report";
+})(AdministrativeContinuityBreachDetection || (AdministrativeContinuityBreachDetection = {}));
 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()),
+    /**
+     * WHICH observation produced this record. Required, so the compiler forces every emitter — present
+     * and future — to say which; a reader cannot recover it from the payload, and guessing it from the
+     * presence of the action fields would make an emitter's omission look like a boot observation.
+     */
+    detectedBy: z.enum(AdministrativeContinuityBreachDetection),
     /** 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(),
+    /**
+     * The owner-conferring memberships the action removed from the population.
+     *
+     * Absent under `BOOT_REPORT`: nothing was removed within sight of a guard, which is the whole
+     * reason the boot report has to look.
+     */
+    reducedMemberIds: z.array(z.string()).optional(),
+    /** The lifecycle verb that caused it — the operator-facing "what did this". Absent under `BOOT_REPORT`. */
+    operationIdentifier: z.string().optional(),
+    /** The subject whose deactivation triggered it. Absent under `BOOT_REPORT`. */
+    subjectUserId: z.string().optional(),
+    /**
+     * The status the subject moved to, so a reader need not infer usability from the verb alone. Absent
+     * under `BOOT_REPORT`.
+     */
+    subjectNextStatus: z.string().optional(),
 });
 // Organization Member Event Data Schemas
 export const AuditableEvent_OrganizationMember_InvitedEventDataSchema = z.object({
@@ -1371,7 +1642,22 @@ export const ApplicationAuthPolicySnapshotSchema = z.record(z.string(), z.unknow
  */
 export const AuditableEvent_ApplicationAuthPolicyChanged_EventDataSchema = z.object({
     eventType: z.literal(CoreAuditableEventType.APPLICATION_AUTH_POLICY_CHANGED),
-    applicationId: z.string(),
+    /*
+     * NO `applicationId` HERE — removed 2026-09-09, and the removal is the fix for a real defect.
+     *
+     * The row this payload rides on ALREADY carries `applicationId` as its scope column, injected by
+     * the repository's write-path enrichment from the writer's own execution context. A second copy in
+     * the payload could only ever agree with it or contradict it, and it contradicted it: the boot
+     * emitter had no application id to hand — `appIdentity.applicationId` is merged in for the FRONTEND
+     * projection only — so it passed `appIdentity.appName`, the SLUG, into both. Measured on the
+     * dogfood trail: 2,175 rows carried the correct id and this event's one row carried `wonder-todos`,
+     * which made it reachable through no API, on the door built for exactly that population (#317).
+     *
+     * Dropping the field is what makes the two-copies question unaskable, rather than answering it
+     * again per emitter. Nothing read it: no SIEM projection, no OCSF mapping, no consumer. Old stored
+     * rows keep parsing — `z.object` strips an unknown key rather than refusing it — so the change is
+     * a shrink with no migration.
+     */
     /** Which user types' policies differed from the previously-recorded snapshot. Sorted, non-empty. */
     changedUserTypes: z.array(z.string()),
     /**
@@ -1547,6 +1833,239 @@ export const AuditableEvent_Organization_SIEMExportConfiguredEventDataSchema = z
     webhookUrlDomain: z.string().optional(),
     eventFormatConfigured: z.string().optional(),
 });
+// Organization Provider Credential Event Data Schemas
+//
+// ## The value is absent by CONSTRUCTION
+//
+// Every field below is an identifier, a timestamp, a closed vocabulary or a count. There is no
+// free-text field an implementation could put a secret in by accident, and no `changes` /
+// `metadata` record — the shape the SSO event uses (`z.record(z.string(), z.any())`) is exactly
+// what a credential event must not have, because an audit row is replicated to the organization's
+// SIEM and to the immutable store, and neither can be edited afterwards.
+//
+// ## Why a provider ref and a slug, and nothing about the value
+//
+// A reader needs to know WHICH authority moved. `providerRef` + `secretSlug` say that completely.
+// A fingerprint of the value was considered and rejected: it is a stable oracle for confirming a
+// guessed secret, so it would put a verification oracle into the one store designed never to
+// forget.
+/**
+ * A tenant granted this application authority to act as it toward a third party.
+ *
+ * assurance-control: WILDO.IDENTITY.DELEGATED_AUTHORIZATION — organization authorizes delegated
+ * access to a named third party.
+ */
+export const AuditableEvent_OrganizationProviderCredential_SetEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.ORGANIZATION_PROVIDER_CREDENTIAL_SET),
+    organizationId: z.string(),
+    providerRef: z.string(),
+    secretSlug: z.string(),
+    /** The acting administrator. Absent only on a system-initiated write, which none exists today. */
+    setBy: z.string().optional(),
+    credentialId: z.string(),
+});
+/**
+ * The stored VALUE changed for a credential that already existed.
+ *
+ * Separate from `_SET` because rotation is the response to a suspected compromise, and "was this
+ * rotated after the incident?" must be answerable without reading every configuration edit.
+ *
+ * assurance-control: WILDO.IDENTITY.DELEGATED_AUTHORIZATION — the delegated authority's secret is
+ * replaced.
+ */
+export const AuditableEvent_OrganizationProviderCredential_RotatedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.ORGANIZATION_PROVIDER_CREDENTIAL_ROTATED),
+    organizationId: z.string(),
+    providerRef: z.string(),
+    secretSlug: z.string(),
+    rotatedBy: z.string().optional(),
+    credentialId: z.string(),
+    /** When the value it replaced was set — how long the retired secret was live. */
+    previousSecretSetAt: z.string().optional(),
+});
+/**
+ * The credential was RESOLVED for an outbound call — the application acted as the tenant.
+ *
+ * The highest-volume of the four and the one that makes the other three worth having: without a
+ * use event, a leaked credential's exploitation is invisible and only its configuration is
+ * recorded. `resolvedFrom` distinguishes a tenant's own credential from the deployment-wide
+ * environment fallback, which is precisely the distinction this whole resource exists to make
+ * visible — a tenant silently acting as the shared principal is the defect, and here it is a
+ * value in a field rather than something nobody can see.
+ *
+ * assurance-control: WILDO.IDENTITY.DELEGATED_AUTHORIZATION — delegated authority is exercised.
+ */
+export const AuditableEvent_OrganizationProviderCredential_UsedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.ORGANIZATION_PROVIDER_CREDENTIAL_USED),
+    organizationId: z.string(),
+    providerRef: z.string(),
+    secretSlug: z.string(),
+    resolvedFrom: z.enum(ProviderCredentialResolutionSource),
+    /** Absent when `resolvedFrom` is the deployment environment — there is no row to name. */
+    credentialId: z.string().optional(),
+});
+/**
+ * The grant ended — by the tenant removing it, or by the tenant itself being purged.
+ *
+ * `reason` separates the two, because "the credential is gone" means different things to an
+ * incident reviewer depending on whether a human revoked it or a cascade removed it.
+ *
+ * assurance-control: WILDO.IDENTITY.DELEGATED_AUTHORIZATION — evidence that delegated authority
+ * was withdrawn.
+ */
+export const AuditableEvent_OrganizationProviderCredential_DeletedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.ORGANIZATION_PROVIDER_CREDENTIAL_DELETED),
+    organizationId: z.string(),
+    providerRef: z.string(),
+    secretSlug: z.string(),
+    deletedBy: z.string().optional(),
+    credentialId: z.string(),
+    reason: z.enum(ProviderCredentialDeletionReason),
+});
+/**
+ * A PERSON connected their own account at a third party to this application.
+ *
+ * The organization's four events say "this tenant authorized the application". These four say "this
+ * individual did", and the difference is not cosmetic: the vendor will attribute every resulting act
+ * to that person's account, so the trail that answers "who authorized this" has to name them.
+ *
+ * `userId` is the subject, not the actor, and the two are the same here BY CONSTRUCTION — the
+ * resource admits no administrative variant, so nobody but the holder can write one of these rows.
+ * That is why there is no `setBy`: an organization credential needs one because several
+ * administrators can write the tenant's row, and a person's own credential has exactly one possible
+ * author. A `setBy` that could only ever repeat `userId` would invite a future reader to believe the
+ * two can differ.
+ *
+ * assurance-control: WILDO.IDENTITY.DELEGATED_AUTHORIZATION — a user authorizes third-party
+ * delegated access.
+ */
+export const AuditableEvent_UserProviderCredential_SetEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.USER_PROVIDER_CREDENTIAL_SET),
+    userId: z.string(),
+    providerRef: z.string(),
+    secretSlug: z.string(),
+    credentialId: z.string(),
+});
+/**
+ * A PERSON completed a consent ceremony at a vendor and this application now holds their grant.
+ *
+ * The subject and the actor are the same by construction — the resource admits no administrative
+ * variant, and the connect leg refuses any owner but the caller — so there is no `grantedBy`.
+ *
+ * `grantedScopes` is what the VENDOR said it issued, not what was asked for. The two differ often
+ * enough to matter: a vendor may narrow a request against what the account is permitted, and the
+ * answer to "what could this application actually do as them" is the granted set. Optional because
+ * several vendors return no scope at all on a token response, and an empty array would assert
+ * something stronger than silence.
+ *
+ * assurance-control: WILDO.IDENTITY.DELEGATED_AUTHORIZATION — a user authorizes third-party
+ * delegated access, and the authorization's extent is recorded with it.
+ */
+export const AuditableEvent_UserProviderConnection_GrantedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.USER_PROVIDER_CONNECTION_GRANTED),
+    userId: z.string(),
+    providerRef: z.string(),
+    secretSlug: z.string(),
+    credentialId: z.string(),
+    grantedScopes: z.array(z.string()).optional(),
+    /**
+     * WHICH account at the vendor — a workspace, a tenant, a directory. Never a secret, and the answer
+     * to a question the row alone cannot settle: two people connecting the same provider may be
+     * granting access to entirely different organizations of that vendor.
+     */
+    accountRef: z.string().optional(),
+    /**
+     * Whether this replaced a connection that already existed.
+     *
+     * A first connection and a re-authorization look identical in the row afterwards, and they are not
+     * the same event to an auditor: a re-authorization frequently follows a revocation at the vendor,
+     * which is exactly the sequence worth being able to see.
+     */
+    replacedExistingConnection: z.boolean(),
+});
+/**
+ * An ORGANIZATION's delegated authorization toward a vendor was granted.
+ *
+ * Mirrors the person's event and is deliberately not the same event with a nullable user: the
+ * subject is a tenant, the SIEM routing is the tenant's, and the data-protection reading differs —
+ * a tenant's shared integration is not anybody's personal connection.
+ *
+ * `grantedByUserId` exists here and not on the user's, for the reason the `_SET` pair already
+ * records: several administrators can authorize on a tenant's behalf, so WHO did is a real question.
+ *
+ * assurance-control: WILDO.IDENTITY.DELEGATED_AUTHORIZATION — an organization authorizes this
+ * application to act as it toward a named third party.
+ */
+export const AuditableEvent_OrganizationProviderConnection_GrantedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.ORGANIZATION_PROVIDER_CONNECTION_GRANTED),
+    organizationId: z.string(),
+    providerRef: z.string(),
+    secretSlug: z.string(),
+    credentialId: z.string(),
+    grantedByUserId: z.string().optional(),
+    grantedScopes: z.array(z.string()).optional(),
+    accountRef: z.string().optional(),
+    replacedExistingConnection: z.boolean(),
+});
+/**
+ * The stored VALUE changed for a person's credential that already existed.
+ *
+ * Separate from `_SET` for the organization's reason — rotation answers "was this replaced after the
+ * incident?" — and for one that is specific to a person: a credential someone rotates on their own
+ * initiative is often the first evidence that they believe their vendor account was compromised.
+ *
+ * assurance-control: WILDO.IDENTITY.DELEGATED_AUTHORIZATION — the delegated authority's secret is
+ * replaced.
+ */
+export const AuditableEvent_UserProviderCredential_RotatedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.USER_PROVIDER_CREDENTIAL_ROTATED),
+    userId: z.string(),
+    providerRef: z.string(),
+    secretSlug: z.string(),
+    credentialId: z.string(),
+    /** When the value it replaced was set — how long the retired secret was live. */
+    previousSecretSetAt: z.string().optional(),
+});
+/**
+ * The credential was RESOLVED for an outbound call — the application acted as that person.
+ *
+ * `resolvedFrom` is present for symmetry with the organization event but carries a narrower range:
+ * a person's credential has NO fallback, because substituting the deployment's shared principal for
+ * someone's own account would attribute the act to the wrong party at the vendor — the very
+ * substitution the whole scope triangle exists to forbid. So this field reads
+ * `USER_CREDENTIAL` on every event, and a reviewer seeing anything else is looking at a defect.
+ *
+ * assurance-control: WILDO.IDENTITY.DELEGATED_AUTHORIZATION — delegated authority is exercised.
+ */
+export const AuditableEvent_UserProviderCredential_UsedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.USER_PROVIDER_CREDENTIAL_USED),
+    userId: z.string(),
+    providerRef: z.string(),
+    secretSlug: z.string(),
+    resolvedFrom: z.enum(ProviderCredentialResolutionSource),
+    credentialId: z.string(),
+});
+/**
+ * The person's grant ended — by them removing it, or by their own erasure.
+ *
+ * `reason` matters more here than on the organization sibling. A credential removed by a cascade
+ * from a subject-erasure request is EVIDENCE that the erasure reached this store, and it is the
+ * evidence an operator produces when asked whether a person's third-party keys were destroyed. The
+ * row itself is gone by then, so the event is all that remains.
+ *
+ * assurance-control: WILDO.IDENTITY.DELEGATED_AUTHORIZATION — evidence that delegated authority
+ * was withdrawn.
+ * assurance-control: WILDO.PRIVACY.ERASURE — evidence that erasure destroyed the subject's
+ * third-party credentials.
+ */
+export const AuditableEvent_UserProviderCredential_DeletedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.USER_PROVIDER_CREDENTIAL_DELETED),
+    userId: z.string(),
+    providerRef: z.string(),
+    secretSlug: z.string(),
+    credentialId: z.string(),
+    reason: z.enum(ProviderCredentialDeletionReason),
+});
 // Outbound M2M Webhook Event Data Schemas
 /**
  * One `webhookConfig.testEndpoint` attempt — an admin causing the platform to open an
@@ -1736,6 +2255,91 @@ export const AuditableEvent_User_PasskeyAuthFailureEventDataSchema = z.object({
     userAgent: z.string(),
     sessionId: z.string(),
 });
+/**
+ * A passkey assertion whose SIGNATURE VERIFIED and whose signature counter did not advance.
+ *
+ * This is the WebAuthn cloned-authenticator signal (W3C WebAuthn L3 §6.1.1: "The signature
+ * counter's purpose is to aid Relying Parties in detecting cloned authenticators"). It is emitted
+ * on the spec's own predicate — either counter non-zero AND the received value not greater than
+ * the stored one — so a credential that reports 0 permanently, which every synced passkey does,
+ * compares 0-against-0 and never reaches here.
+ *
+ * spec-cite: W3C Web Authentication Level 3, §6.1.1 Signature Counter Considerations
+ * (https://www.w3.org/TR/webauthn-3/#sctn-sign-counter). The spec declines to mandate an outcome
+ * (§7.2 step 22: "whether the Relying Party ... fails the authentication ceremony or not, is
+ * Relying Party-specific"); Wildo refuses, matching what every major implementation does.
+ *
+ * SEPARATE from `USER_PASSKEY_AUTHENTICATION_FAILURE` deliberately. A wrong credential, an absent
+ * challenge and a bad signature are routine noise; this one means a private key may exist in two
+ * places. Recorded as its own type at CRITICAL so it is alertable rather than buried among ordinary
+ * failed logins — which is exactly where it lived until 2026-09-08.
+ *
+ * The device-type, backup and AAGUID fields are carried for TRIAGE, never for a decision: nothing
+ * branches on them. A synced credential that once reported a non-zero counter and then regresses is
+ * still a signal, and exempting by device type would silently disable clone detection for the
+ * growing majority of credentials.
+ */
+/**
+ * One file that a scanner concluded is infected (#506).
+ *
+ * `threatName` is the scanner's own signature or rule name (`Eicar-Test-Signature`, a YARA rule id).
+ * It is carried because it is the first thing a responder needs and it names a THREAT, not a person
+ * — unlike a file name, which is user-supplied content and is deliberately absent: audit rows are
+ * replicated to the organisation's SIEM and to the immutable store, and an uploaded file's name
+ * routinely carries personal data ("Invoice - Jane Doe.pdf"). The file id resolves to the row for
+ * anyone authorised to look.
+ */
+export const AuditableEvent_File_MalwareDetectedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.FILE_MALWARE_DETECTED),
+    fileId: z.string(),
+    /** Which scanner concluded it — ClamAV signature matching and YARA pattern matching are different evidence. */
+    scannerRef: z.string(),
+    /** The signature or rule the scanner matched, when it reports one. */
+    threatName: z.string().optional(),
+    /** The resource the file belongs to, when the scan context carries it. */
+    resourceType: z.string().optional(),
+    resourceId: z.string().optional(),
+    organizationId: z.string().optional(),
+    /** Terminal status the file was moved to. Recorded so the row cannot claim a state the record does not hold. */
+    fileStatus: z.string(),
+});
+/**
+ * One scan that could not be completed (#506).
+ *
+ * Distinct from a detection: the control did not run. `failureReason` is TRUNCATED because a scanner
+ * error routinely embeds a host, a socket path or a temporary file path, and this row reaches the
+ * organisation's SIEM.
+ */
+export const AuditableEvent_File_MalwareScanFailedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.FILE_MALWARE_SCAN_FAILED),
+    fileId: z.string(),
+    scannerRef: z.string(),
+    /** Truncated scanner/pipeline error — enough to triage, bounded so a path cannot ride into the SIEM whole. */
+    failureReason: z.string().optional(),
+    resourceType: z.string().optional(),
+    resourceId: z.string().optional(),
+    organizationId: z.string().optional(),
+    fileStatus: z.string(),
+});
+export const AuditableEvent_User_PasskeyCloneSuspectedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.USER_PASSKEY_CLONE_SUSPECTED),
+    userId: z.string(),
+    credentialId: z.string(),
+    /** The counter Wildo held for this credential before the assertion. */
+    storedCounter: z.number().int().min(0),
+    /** The counter the authenticator reported. Not greater than `storedCounter`, which is the signal. */
+    receivedCounter: z.number().int().min(0),
+    /** Triage only: `singleDevice` or `multiDevice`, as captured at registration. */
+    credentialDeviceType: z.string(),
+    /** Triage only: whether the credential is backed up (synced), as captured at registration. */
+    credentialBackedUp: z.boolean(),
+    /** Triage only: the authenticator model identifier, when the registration reported one. */
+    aaguid: z.string().optional(),
+    /** Which door the assertion arrived at — a step-up regression is not the same story as a login. */
+    ceremony: z.string(),
+    ipAddress: z.string(),
+    userAgent: z.string(),
+});
 export const AuditableEvent_User_PasskeyRemovedEventDataSchema = z.object({
     eventType: z.literal(CoreAuditableEventType.USER_PASSKEY_REMOVED),
     userId: z.string(),
@@ -1835,16 +2439,65 @@ export const AuditableEvent_OAuth2ProviderBlockedEventDataSchema = z.object({
         });
     }
 });
+/**
+ * Authentication-context demand unsatisfied (issue #444).
+ *
+ * Carries BOTH sides of the comparison, because either alone is unactionable: `demandedAcrValues`
+ * is what the connection authored, `receivedAcr` is what the provider's ID token reported. The
+ * received value is OPTIONAL and its absence is the distinct, common case — a provider that emits
+ * no `acr` claim at all — which reads very differently from one that answered with a weaker
+ * context, and an operator must be able to tell them apart from the trail alone.
+ *
+ * No email field. The refusal happens before any identity is established or trusted, and recording
+ * an unauthenticated claimant's address as though it were a subject is the kind of quiet personal
+ * data this family avoids; `providerRef` and the two ACR sides are what a reader needs.
+ */
+export const AuditableEvent_OidcAcrDemandUnsatisfiedEventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.OIDC_ACR_DEMAND_UNSATISFIED),
+    providerRef: z.string(),
+    /** The ordered list of acceptable values the connection authored. Never empty — an empty demand is not enforced at all. */
+    demandedAcrValues: z.array(z.string()).min(1),
+    /** What the ID token's `acr` claim reported. ABSENT when the provider emitted no claim. */
+    receivedAcr: z.string().optional(),
+    /** Present when the ID token itself could not be read, which is a different refusal from a mismatched claim. */
+    failureReason: z.string().optional(),
+});
 // Emergency Access Event Data Schema
+/**
+ * A named break-glass account signed in past its tenant's own SSO requirement (#423).
+ *
+ * `organizationId` was REQUIRED here and is now one of two scopes, because `emergencyAccess` lives
+ * on the POLYMORPHIC SSO config: an application-scope policy carries break-glass accounts for the
+ * application itself, and requiring an organization id would have made the one event that matters
+ * unemittable for exactly that case — a privileged sign-in with no record, which is the opposite of
+ * what this event is for. The exactly-one-scope refinement follows the OAuth2-provider-blocked
+ * event above rather than inventing a second shape.
+ */
 export const AuditableEvent_EmergencyAccess_UsedEventDataSchema = z.object({
     eventType: z.literal(CoreAuditableEventType.EMERGENCY_ACCESS_USED),
     userId: z.string(),
     email: z.email(),
-    organizationId: z.string(),
+    scopeType: z.enum(AuthScopeType),
+    organizationId: z.string().optional(),
+    applicationId: z.string().optional(),
     reason: z.string().optional(),
     ipAddress: z.string(),
     userAgent: z.string(),
     sessionId: 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: 'Emergency-access events require exactly one explicit tenant scope',
+        });
+    }
 });
 export const AuditableEvent_FieldAccess_EventDataSchema = z.object({
     eventType: z.literal(CoreAuditableEventType.FIELD_ACCESS),
@@ -2034,17 +2687,21 @@ export const AuditableEvent_ResourceOperationPerformed_EventDataSchema = z.objec
  * `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
+ * This event is the visibility half, and it is NOT the refusal. The refusal shipped separately and
+ * lives in `authorizeOrganizations`: an undeclared crossing is no longer admitted, and the caller is
+ * answered as not-found so the response cannot be used as an existence oracle. Emission here stays
  * 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.
+ * The observation is taken BEFORE the admission decision, on purpose, so a sanctioned crossing is
+ * recorded too.
  *
  * ## 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.
+ * `organizationMembers.grantOwnership`, which additionally requires a usable platform access grant.
+ * `false` now means an ATTEMPTED undeclared crossing, which was refused: still the population to
+ * watch, because it is reach nobody declared and no specification describes.
  *
  * assurance-control: WILDO.ACCESS.CROSS_TENANT_ADMINISTRATION — platform-tier access to a tenant the
  * principal does not belong to.
@@ -2076,8 +2733,25 @@ export const AuditableEvent_PlatformAccessGrantLifecycle_EventDataSchema = z.obj
     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(),
+    /**
+     * WHAT the elevation reaches, and therefore who was entitled to approve it.
+     *
+     * Carried explicitly rather than inferred from the presence of `targetOrganizationId`: a reviewer
+     * asking "was this approved by the party the rules require?" needs the SCOPE, and deriving it from
+     * a field's absence would make a lost or scrubbed value read as an application-wide elevation.
+     *
+     * `TENANT` is the default so every row written before this axis existed keeps its true meaning —
+     * the application-wide grant did not exist then.
+     */
+    grantScope: z.enum(PlatformAccessGrantScope).default(PlatformAccessGrantScope.TENANT),
+    /**
+     * The tenant that was, or would have been, reached into.
+     *
+     * OPTIONAL since the application-wide scope arrived: that grant names no tenant, and writing a
+     * placeholder would be a lie about which customer an operator reached. Absent ⇔
+     * `grantScope === APPLICATION_WIDE`.
+     */
+    targetOrganizationId: z.string().optional(),
     /** 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. */
@@ -2119,11 +2793,20 @@ export const AuditableEvent_CrossTenantAdministrativeAccess_EventDataSchema = z.
      * and on any crossing admitted before grants were required.
      */
     authorizingGrantId: z.string().optional(),
+    /**
+     * WHICH COLLECTION {@link authorizingGrantId} names.
+     *
+     * A grant id alone is not resolvable: `platformAccessGrants` and `applicationAccessGrants` are two
+     * resources with two collections, and a reviewer handed only an id has to try both. Absent exactly
+     * when `authorizingGrantId` is.
+     */
+    authorizingGrantScope: z.enum(PlatformAccessGrantScope).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.
+     * `false` is the signal worth alerting on: an ATTEMPTED crossing that no variant asked for and no
+     * specification describes. It was refused, so the row records an attempt rather than a completed
+     * access. See this schema's JSDoc.
      */
     admissionDeclared: z.boolean(),
     /** The caller's roles as they were at decision time. */
@@ -2166,6 +2849,21 @@ export const AuditableEvent_PlatformDirectoryAccess_EventDataSchema = z.object({
     initiatorRoles: z.array(z.string()),
     /** How the call was initiated — separates a human operator from framework machinery. */
     executionType: z.enum(ExecutionContext_ExecutionType),
+    /**
+     * The application-wide elevation that authorised this directory read.
+     *
+     * Until 2026-09-09 this event named NO elevation, because none was required — the read was gated on
+     * an administrator role alone while the far narrower per-row crossing required a usable, time-bound,
+     * approved grant. That inversion is what `applicationAccessGrants` closes, and this field is the
+     * evidence half of the closure: it is what joins a directory read to the two administrators who
+     * signed for it.
+     *
+     * Absent on a read the admission does not gate — an exempt execution type (batch, webhook), or a
+     * read the confinement authority confined, neither of which is an elevation.
+     */
+    authorizingGrantId: z.string().optional(),
+    /** WHICH collection {@link authorizingGrantId} names. Absent exactly when it is. */
+    authorizingGrantScope: z.enum(PlatformAccessGrantScope).optional(),
 });
 export const AuditableEvent_ResourceOperationDenied_EventDataSchema = z.object({
     eventType: z.literal(CoreAuditableEventType.RESOURCE_OPERATION_DENIED),
@@ -2236,22 +2934,24 @@ export const AuditableEvent_ResourceOperationDenied_EventDataSchema = z.object({
  * 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.
+ * 1. **Human attribution** — `accessingUserId` names the actual human 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. The gate admits `APP_ADMIN_SUPER_ADMIN` and nothing else; a dedicated
+ *    auditor role does not exist yet, and adding one is a purely additive change to that gate.
  * 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.
+ * Strictly read-only (the see-through primitive never mutates). Emitted TODAY by both see-through
+ * read primitives, `readRetainedAsSystem` and `listRetainedAsSystem`: each calls
+ * `logRetainedDataAccess` after its gates pass, so this is a live event, not a contract awaiting a
+ * producer.
  */
 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. */
+    /** The HUMAN principal who performed the see-through read (an application super-administrator). 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),
@@ -2363,6 +3063,145 @@ export const AuditableEvent_CollectionDataExport_EventDataSchema = z.object({
     /** Tenant scope, when the export ran org-scoped. */
     organizationId: z.string().optional(),
 });
+/**
+ * The application CALLED a declared operation on a third-party provider (S3a/S3b; see the enum
+ * member's docstring for why this is neither an HTTP_API read-through nor a credential-use event).
+ *
+ * One event per OUTBOUND CALL, emitted on both the success and the failure path. Recording only
+ * what worked would hide the attempts, and a refused or failed outbound call is exactly what a
+ * reviewer wants to see first.
+ *
+ * Ids and SHAPE only, never a payload. There is no field for the request body, the response body or
+ * the credential — a structural property of this schema rather than a redaction step somebody has to
+ * remember, for the same reason the credential family carries no value field.
+ *
+ * assurance-control: WILDO.ACCESS.AUTHORIZATION_DECISION_AUDIT — records WHOSE third-party account
+ * an outbound call spent, which the initiator's own ids cannot answer once one execution may spend
+ * several.
+ */
+export const AuditableEvent_ProviderOperationCall_EventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.PROVIDER_OPERATION_CALL),
+    /** The provider whose catalogue declared the operation (e.g. `slack`). */
+    providerRef: z.string().trim().min(1),
+    /** The operation id as the catalogue declares it. */
+    operationId: z.string().trim().min(1),
+    /** The catalogue domain the operation belongs to. */
+    domain: z.string().trim().min(1),
+    /** The HTTP method the compiled request used. */
+    method: z.string().trim().min(1),
+    /** `READ` | `WRITE`, as the operation declares its effect — the axis a reviewer filters on first. */
+    classification: z.string().trim().min(1),
+    /**
+     * WHOSE ACCOUNT the call spent: `application` | `organization` | `user`.
+     *
+     * Deliberately separate from `organizationId` below, which records the tenant the REQUEST was
+     * scoped to. Those are the same tenant in the ordinary case and different ones exactly where it
+     * matters — a trail carrying only the initiator's organization would attribute a fan-out's calls
+     * to the wrong tenants.
+     */
+    connectionOwnerScope: z.string().trim().min(1),
+    /** The owner's id, absent for an application-owned call which names no second party. */
+    connectionOwnerId: z.string().optional(),
+    /** `service` | `user` — whether the call acted for the owner itself or on a person's delegation. */
+    connectionDelegation: z.string().trim().min(1),
+    /** HTTP status of the answer; absent when the call never got one. */
+    status: z.number().int().optional(),
+    /** Present when the call failed, naming the failure KIND rather than the vendor's prose. */
+    failureKind: z.string().optional(),
+    /** 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(),
+    /** The tenant the REQUEST was scoped to — see `connectionOwnerScope`. */
+    organizationId: z.string().optional(),
+});
+/**
+ * An agent reached an MCP server — the outbound trail for a tool call that leaves the trust
+ * boundary (#491).
+ *
+ * One event per ATTEMPT, successful or not. Recording only what worked would hide exactly what a
+ * reviewer wants first: the refused targets, the calls that timed out, and the tools that answered
+ * with their own error. `outcome` names which of those it was, in the client's own vocabulary, so
+ * the trail and the logs agree on the words.
+ *
+ * Ids, HOST and SHAPE only — never a payload. There is no field for the tool arguments, the tool
+ * result or the credential. That is a structural property of this schema rather than a redaction
+ * step somebody has to remember, the same choice the provider-call and credential families make.
+ * `destinationHost` and not the URL, because an MCP endpoint routinely carries a tenant or session
+ * identifier in its path.
+ *
+ * assurance-control: WILDO.ACCESS.AUTHORIZATION_DECISION_AUDIT — records WHOSE third-party account
+ * an agent's tool call spent, which the initiator's own ids cannot answer once one turn may spend
+ * either the person's or the tenant's.
+ */
+export const AuditableEvent_McpToolCall_EventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.MCP_TOOL_CALL),
+    /** The server ref the application declared and the agent named. */
+    mcpServerRef: z.string().trim().min(1),
+    /** HOST only — see the docstring for why never the URL. */
+    destinationHost: z.string().trim().min(1),
+    /** The tool called. Absent when the attempt failed before any tool was chosen (discovery). */
+    toolName: z.string().optional(),
+    /** The client's outcome kind — `ok`, `refused_target`, `unreachable`, `timed_out`, `protocol_error`, `tool_error`. */
+    outcome: z.string().trim().min(1),
+    /**
+     * WHOSE ACCOUNT the call spent: `user` | `organization`. Absent when no credential was resolved,
+     * which is itself the reason the attempt failed.
+     *
+     * Separate from `organizationId` for the same reason as the provider-call event: those are the
+     * same tenant in the ordinary case, and different ones exactly where it matters.
+     */
+    connectionOwnerScope: z.string().optional(),
+    /** The credential row that was spent, for the audit trail. */
+    credentialId: z.string().optional(),
+    /** The REAL initiating user — absent only for genuine machine/internal executions. */
+    initiatorUserId: z.string().optional(),
+    /** The tenant the turn was scoped to — see `connectionOwnerScope`. */
+    organizationId: z.string().optional(),
+    /** The agent whose declaration named the server, so a trail can be read back to a configuration. */
+    agentRef: z.string().optional(),
+});
+/**
+ * A human approver AUTHORED the arguments an approval-gated tool ran with (#566).
+ *
+ * One row per MODIFIED approval — never per approval. See the enum member's docstring for why an
+ * ordinary approval is not this event, and for why no argument VALUE appears in this schema.
+ *
+ * `proposedInputDigest` / `executedInputDigest` are the model SDK's own canonical input digests, the
+ * same values its approval signature is computed over. That is what makes them evidence rather than
+ * a convenience: a reader holding the executed call can recompute the second and see it match, and
+ * the two differing is proof that the call which ran is not the call which was proposed — with no
+ * copy of either payload on the trail.
+ *
+ * assurance-control: WILDO.ACCESS.AUTHORIZATION_DECISION_AUDIT — records that an authorization
+ * decision REWROTE the act it authorized, and who made it.
+ */
+export const AuditableEvent_AgentToolApprovalModified_EventDataSchema = z.object({
+    eventType: z.literal(CoreAuditableEventType.AGENT_TOOL_APPROVAL_MODIFIED),
+    /** The conversational execution whose turn was paused. */
+    executionId: z.string().trim().min(1),
+    /** The pending decision's id — correlates this row with the pause and the resume in the logs. */
+    approvalId: z.string().trim().min(1),
+    /** The actor system the turn belongs to. */
+    systemRef: z.string().trim().min(1),
+    /** The agent whose declaration gated the tool, so a trail reads back to a configuration. */
+    agentRef: z.string().trim().min(1),
+    /** The approval-gated tool, as the model was shown it. */
+    toolName: z.string().trim().min(1),
+    /** Canonical digest of the arguments the MODEL proposed. */
+    proposedInputDigest: z.string().trim().min(1),
+    /** Canonical digest of the arguments that actually RAN. Differs from the above by construction. */
+    executedInputDigest: z.string().trim().min(1),
+    /**
+     * The argument NAMES the approver changed, sorted. Names only — a field name is not personal data,
+     * which is exactly why it is always safe and always recorded.
+     */
+    modifiedArgumentKeys: z.array(z.string()),
+    /** The approver. Absent never happens on this plane — only a present human can answer — but the envelope owns the field. */
+    approverUserId: z.string().optional(),
+    /** The tenant the turn was scoped to. */
+    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
@@ -2861,6 +3700,10 @@ export const AuditableEvent_TypedDataSchema = z.discriminatedUnion('eventType',
     AuditableEvent_User_TokenRefreshedEventDataSchema,
     AuditableEvent_Organization_SSOConfigurationChangedEventDataSchema,
     AuditableEvent_Organization_SIEMExportConfiguredEventDataSchema,
+    AuditableEvent_OrganizationProviderCredential_SetEventDataSchema,
+    AuditableEvent_OrganizationProviderCredential_RotatedEventDataSchema,
+    AuditableEvent_OrganizationProviderCredential_UsedEventDataSchema,
+    AuditableEvent_OrganizationProviderCredential_DeletedEventDataSchema,
     AuditableEvent_ApplicationAuthPolicyChanged_EventDataSchema,
     AuditableEvent_Webhook_EndpointTestDispatchedEventDataSchema,
     AuditableEvent_SCIM_TokenCreatedEventDataSchema,
@@ -2881,6 +3724,7 @@ export const AuditableEvent_TypedDataSchema = z.discriminatedUnion('eventType',
     AuditableEvent_User_PasskeyAuthSuccessEventDataSchema,
     AuditableEvent_User_PasskeyAuthFailureEventDataSchema,
     AuditableEvent_User_PasskeyRemovedEventDataSchema,
+    AuditableEvent_User_PasskeyCloneSuspectedEventDataSchema,
     AuditableEvent_User_MagicLinkSentEventDataSchema,
     AuditableEvent_User_MagicLinkVerifiedEventDataSchema,
     AuditableEvent_User_MagicLinkFailedEventDataSchema,
@@ -2890,6 +3734,7 @@ export const AuditableEvent_TypedDataSchema = z.discriminatedUnion('eventType',
     AuditableEvent_User_PhoneVerifiedEventDataSchema,
     AuditableEvent_User_PhoneVerificationFailedEventDataSchema,
     AuditableEvent_OAuth2ProviderBlockedEventDataSchema,
+    AuditableEvent_OidcAcrDemandUnsatisfiedEventDataSchema,
     AuditableEvent_EmergencyAccess_UsedEventDataSchema,
     AuditableEvent_FieldAccess_EventDataSchema,
     AuditableEvent_ResourceOperationPerformed_EventDataSchema,
@@ -2902,6 +3747,7 @@ export const AuditableEvent_TypedDataSchema = z.discriminatedUnion('eventType',
     AuditableEvent_CollectionDataExport_EventDataSchema,
     AuditableEvent_User_SessionEvictedEventDataSchema,
     AuditableEvent_HttpApiReadThroughAccess_EventDataSchema,
+    AuditableEvent_ProviderOperationCall_EventDataSchema,
     AuditableEvent_HttpApiExternalErasure_EventDataSchema,
     AuditableEvent_HttpApiNonErasureAcknowledged_EventDataSchema,
     AuditableEvent_User_CrossFrontendHandoffIssuedEventDataSchema,