Cloud Functional Requirements

Definitions

Organisation — A named workspace that groups users, devices, and applications. Every resource in the cloud belongs to exactly one organisation. Organisations are isolated from one another; the users and resources of one organisation are not visible to members of another.

Provisioned user — A user whose account exists in the cloud. An account may be created by the administrative API, by accepting an invitation, or by signing in with an email address that matches an organisation's approved domain. A provisioned user with no organisation membership may create a new organisation or accept an invitation but has no access to any organisational resource until they do.

Device — A physical piece of hardware running Wendy OS. A device may be registered in the cloud before it has been enrolled or has ever connected.

Machine user — A non-human account within an organisation, intended for automated systems. A machine user has a role and authenticates via PATs, but has no interactive login and cannot be invited or created through the external identity provider.

Enrollment token — A short-lived, single-use secret generated by the cloud and delivered to a device out-of-band. It is the only credential a device may use before it has a certificate, and it is consumed the moment it is used.

Deployment — The act of expressing and delivering a desired running state for one or more applications across a targeted set of devices. A deployment is created in Wendy Cloud and delivered to devices asynchronously.

Release — The act of publishing a named, immutable version of an application to Wendy Cloud. A release references a specific container image by its content digest and may be targeted by deployments once created.

---

1. Organisations

1.1 Every resource in the cloud belongs to exactly one organisation.
1.2 A user may be a member of multiple organisations simultaneously and holds an independent role in each. A user who is an owner in one organisation may hold any role in another.
1.3 A provisioned user may create a new organisation. The user who creates the organisation becomes its owner. There is no limit on the number of organisations a user may create.
1.4 An organisation may not be deleted while it has active devices or members other than the owner.
1.5 Organisations are isolated. A user may only access resources within organisations they are a member of. Resources of one organisation are not visible to members of another.

---

2. Identity and Access

2.1 Authentication

2.1.1 Users authenticate through an external identity provider. The cloud does not store or manage passwords directly.
2.1.2 The method of authentication (for example, email link or single sign-on provider) does not affect the user's role or permissions within an organisation. Role assignment is always explicit.
2.1.3 A user who joins an organisation through an invitation receives the role specified in that invitation, regardless of how they authenticated.

2.2 User Provisioning

The cloud does not permit self-registration. A user account must exist before the user can sign in for the first time.

2.2.1 User accounts are provisioned via an administrative API. This allows external systems — such as a purchase flow or helpdesk tool — to create accounts on behalf of Wendy before the user ever signs in.
2.2.2 A user whose account has been provisioned but who has no organisation membership may create a new organisation or accept an invitation. They have no access to any organisational resource until they do.
2.2.3 An organisation may configure one or more approved email domains. A user whose email address matches an approved domain may sign in without prior API provisioning; an account is created automatically upon first sign-in, and the user is added to the configuring organisation with the role specified in the domain configuration.
2.2.4 A user may not sign in if their email address does not match an approved domain for any organisation and their account has not been provisioned via the administrative API.

2.3 Roles

The cloud defines four membership roles. Each role is a strict superset of the one below it.

2.3.1 An organisation has exactly one owner at all times.
2.3.2 Ownership may be transferred by the current owner to any existing member of the organisation. The previous owner becomes an admin upon transfer.
2.3.3 An owner or admin may change any member's role, subject to the constraint that no member may be assigned a role exceeding that of the user making the change.
2.3.4 A member may not modify their own role.
2.3.5 An owner may remove any member. An admin may remove members and viewers, but not other admins or the owner.

2.4 Invitations

An invitation is a one-time, time-limited credential sent to an email address that allows the recipient to join an organisation with a pre-assigned role. It is the only mechanism by which a manually provisioned user may join an organisation they did not create.

2.4.1 An owner or admin may invite a user by specifying an email address and the role the invited user will receive upon joining.
2.4.2 The role assigned in an invitation may not exceed the role of the user sending it.
2.4.3 An invitation is valid for seven days from the time it is sent. A user who does not accept within that period must be re-invited.
2.4.4 An invitation may be revoked by an owner or admin before it is accepted. A revoked invitation cannot be used to join the organisation.
2.4.5 Accepting an invitation adds the user to the organisation with the specified role. If the recipient already has an account, their existing account is used. If they do not, accepting the invitation also provisions their account.
2.4.6 A manually provisioned user may not join an organisation without a valid invitation, unless they are the organisation's creator.

2.5 Directory Provisioning

An organisation may connect to an external identity provider to synchronise user membership and roles automatically. When a directory integration is active, the external directory is the authoritative source for membership and roles within that organisation.

2.5.1 Owners and admins may configure a directory integration for their organisation.
2.5.2 Users added to the organisation in the external directory are automatically added to the organisation in the cloud with the role assigned in the directory. If the user has no cloud account, one is provisioned automatically.
2.5.3 Users removed from the organisation in the external directory are automatically removed from the organisation in the cloud.
2.5.4 Role changes made in the external directory are automatically applied. A role assigned by the directory may not exceed the role of the admin who configured the integration.
2.5.5 Manual changes to directory-managed users may be overwritten on the next directory sync. The directory is the authoritative source while the integration is active.
2.5.6 Directory-managed users are clearly identified as such in the member list.
2.5.7 A directory integration is configured with both a directory connection and an associated identity provider. These are typically the same external system (for example, an enterprise identity platform that manages both user records and authentication). When a provisioned user signs in, the cloud identifies the correct identity provider from the organisation's directory configuration and redirects authentication there.
2.5.8 Directory synchronisation runs automatically on a fixed schedule. The default sync interval is 15 minutes. Owners and admins may also trigger a manual sync at any time.
2.5.9 An owner or admin may disconnect a directory integration at any time. Existing members are not automatically removed when the integration is disconnected; their membership reverts to manual management.

2.6 Personal Access Tokens

A Personal Access Token (PAT) is a secret string that allows a user to authenticate API calls without an interactive session. PATs are intended for scripts and read-only integrations where an interactive login is not possible and the operation must run under a specific user's identity and permissions.

PATs are not the intended mechanism for CI/CD pipelines or automated systems acting on behalf of the organisation rather than on behalf of a specific person. Machine users (section 2.7) are the correct approach for those use cases.

2.6.1 A PAT is scoped to a user's account, not to a specific organisation.
2.6.2 Any user who holds a role of viewer or above in at least one organisation may create a PAT. A user with no organisation membership may not create a PAT.
2.6.3 Viewers may create PATs to enable programmatic read-only access (for example, querying fleet status or logs from a script).
2.6.4 A PAT grants the permissions of the issuing user at the time of each API call, reflecting whatever role the user holds in each organisation at that moment.
2.6.5 If the user's role in an organisation changes after the PAT is created, the PAT immediately reflects the updated permissions for that organisation.
2.6.6 If the user is removed from an organisation, the PAT immediately loses access to that organisation.
2.6.7 If the user account is deleted, all associated PATs are immediately revoked.
2.6.8 A PAT must be given an expiry date at creation time. The maximum permitted lifetime is 365 days.
2.6.9 A PAT may be revoked only by the user who created it.
2.6.10 A PAT may not be used to perform any identity or access management action. This includes creating or revoking tokens, inviting or removing members, changing roles, creating or deleting machine users, configuring directory integrations, and transferring or deleting the organisation.
2.6.11 The cloud does not reveal the full token value after creation. The user is responsible for storing it.

Each organisation independently controls whether a user's PATs may be used to access that organisation. This allows admins to restrict programmatic access without revoking or invalidating the user's PAT globally.

2.6.12 PAT access is enabled by default for all members of an organisation.
2.6.13 Owners and admins of an organisation may enable or disable PAT access for any member of that organisation.
2.6.14 When PAT access is disabled for a user in an organisation, API calls made with that user's PATs are rejected for that organisation. The user's PATs are not revoked and remain valid for other organisations where access is enabled.

2.7 Machine Users

Machine users are non-human accounts within an organisation, intended for automated systems — CI/CD pipelines, monitoring agents, deployment scripts, and similar — that need to act on behalf of the organisation rather than on behalf of a specific person. Using a machine user instead of a real user's PAT ensures that automated access does not depend on any individual's employment or membership status.

2.7.1 Owners and admins may create machine users within their organisation.
2.7.2 A machine user is assigned a role of admin, member, or viewer at creation time. Machine users may not hold the owner role.
2.7.3 Machine users authenticate exclusively through PATs. They have no interactive login.
2.7.4 PATs for machine users are created and revoked by owners and admins of the organisation. All other PAT rules in section 2.6 apply, with the exception that the per-organisation PAT access controls (2.6.11–2.6.14) do not apply to machine users; a machine user's PATs are always valid within their organisation while the machine user is active.
2.7.5 When a machine user is deleted, all PATs associated with it are immediately revoked.
2.7.6 Machine users are visible in the member list of an organisation and are clearly distinguished from human users.

---

3. Device Provisioning

3.1 Enrollment Tokens

An enrollment token is a short-lived, single-use secret that authorises a physical device to request its first identity certificate from the cloud. It solves a bootstrapping problem: a device that has never connected to the cloud has no existing credential, so it cannot use certificate-based authentication to prove who it is. The token is its one permitted exception — a temporary shared secret agreed upon before the device has any identity of its own.

The token is generated on the cloud side and delivered to the device out-of-band — for example, written to the device's configuration partition during flashing or first-time setup — before the device ever attempts to connect.

3.1.1 Enrollment tokens may only be generated by admins and owners. Members may manage existing devices (metadata, deployments, ad-hoc control) but may not enroll new devices into the fleet.
3.1.2 Each token is scoped to a specific device record within the organisation. A token issued for device A may not be used to enroll device B.
3.1.3 A token has a default validity period of 24 hours from creation. Owners and admins may configure a different default validity period for their organisation. Owners and admins may also override the validity period for an individual token at creation time.
3.1.4 A token is invalidated immediately upon use. It may not be reused.
3.1.5 A token may not be used to authenticate any API call other than certificate issuance. It grants no access to any cloud resource.
3.1.6 The cloud stores only a one-way hash of the token value. The full token value is displayed once at creation time and is never retrievable thereafter.
3.1.7 Admins and owners may list and revoke unused tokens for their organisation.
3.1.8 Enrollment tokens may be created programmatically via the API when authenticated with an admin-role PAT or machine user. Programmatic token creation is enabled by default and may be disabled at the organisation level by owners and admins.

3.2 Certificate Issuance

3.2.1 Wendy OS generates a cryptographic key pair on the device before initiating enrollment.
3.2.2 The device presents the enrollment token and its public key to request an identity certificate.
3.2.3 The cloud validates the token, signs the public key, and issues a certificate that encodes the device's organisation identifier and device identifier.
3.2.4 The private key never leaves the device. The cloud does not have access to it.
3.2.5 The issued certificate is the sole credential the device uses for all subsequent cloud communication.
3.2.6 The cloud records the certificate, its validity period, and its association to the device.

3.3 Certificate Renewal

Certificates have a fixed validity period. A device must renew its certificate before expiry to maintain uninterrupted access to the cloud.

3.3.1 A device may renew its certificate before expiry by presenting its current valid certificate and a new public key.
3.3.2 Renewal does not require human intervention.
3.3.3 Upon renewal, the previous certificate is immediately invalidated.

3.4 Certificate Expiry

A certificate that reaches its expiry date without having been renewed is no longer valid. To reduce the risk of devices becoming unreachable due to expiry, Wendy OS initiates renewal well before the certificate's expiry date.

To handle cases where a device is offline during the normal renewal window — for example, a remote device with intermittent connectivity — a grace period applies after expiry during which the device may still renew without requiring out-of-band intervention.

3.4.1 Wendy OS initiates certificate renewal automatically when the certificate has consumed a configurable percentage of its validity period. The default threshold is 80%.
3.4.2 A device whose certificate has expired but is within the grace period may still renew by presenting its expired certificate and a new public key. During the grace period, an expired certificate is accepted exclusively for renewal requests; it cannot be used for any other cloud operation.
3.4.3 The grace period after certificate expiry is configurable by owners and admins. The default grace period is 72 hours.
3.4.4 A device that has passed the grace period is denied access to the cloud and cannot self-recover. An admin or owner must generate a new enrollment token scoped to the existing device record and deliver it to the device out-of-band.
3.4.5 When a device re-enrolls after grace period expiry, the cloud issues a new certificate against the same device record. The device's name, metadata, tags, and historical records are unchanged.
3.4.6 Re-enrollment after grace period expiry is identical to initial enrollment from a protocol standpoint. No new device record is created.

3.5 Revocation

3.5.1 Admins and owners may revoke a device's certificate at any time.
3.5.2 A revoked device is immediately denied access to the cloud. No grace period applies to revocation. To reconnect, the device must re-enroll using a new enrollment token, following the same process described in section 3.4.4.

---

4. Device Management

4.1 Fleet Overview

4.1.1 Viewers, members, admins, and owners may view all provisioned devices in the organisation.
4.1.2 The fleet view shows each device's name, hardware type, connection status, and time of last contact.
4.1.3 Connection status is one of: online (the device has an active connection to the cloud), offline (the device has not contacted the cloud within its expected check-in interval), or never connected (the device has been provisioned but has not yet established a first connection).

4.2 Device Detail

4.2.1 Each device exposes its installed applications, their running state, the time it last reported its state, and any active deployments targeting it.
4.2.2 A device is considered to have reported its state when it sends a state update to the cloud. If no update has been received within the expected check-in interval, the device is marked offline and its last known state is displayed.

4.3 Device Metadata

4.3.1 Each device record holds a name, an optional physical location, one or more tags, and hardware specifications (device type, Central Processing Unit (CPU) architecture, RAM, and storage).

Physical location supports two independent formats, both of which may be set simultaneously on a single device:

• Geographic coordinates: latitude and longitude expressed as decimal degrees (for example, 51.5074° N, -0.1278° E). Intended for integration with maps or asset tracking systems.
• Location label: a free-form text field for hierarchical or room-based naming (for example, "Factory A / Production Hall 3 / Zone Beta"). The cloud imposes no structure on this field; the organisation defines its own naming conventions.

Tags are free-form string labels applied to devices to group them for targeting. A device may carry any number of tags. Tags are used when creating deployments (section 4.5) and notification rules (section 6.4) to address groups of devices without naming them individually.

4.3.2 Members, admins, and owners may update device metadata, including adding and removing tags.
4.3.3 Viewers may view device metadata but may not modify it.
4.3.4 Tags and their meanings are defined by the organisation. The cloud imposes no structure or validation on tag values.
4.3.5 A device may declare tags in its on-device configuration. Tags declared in this way are automatically applied to the device record in Wendy Cloud when the device connects. Manifest-declared tags coexist with tags set manually through Wendy Cloud; neither set overrides the other.

4.4 Device Removal

4.4.1 Admins and owners may remove a device from the organisation's fleet.
4.4.2 Removing a device revokes its certificate, cancels all active deployments targeting it exclusively, and removes it from any future deployment targets evaluated after removal.
4.4.3 Historical records associated with the device (audit log entries, past deployment records, log history) are retained and attributed to the device identifier.

4.5 Targeting

4.5.1 Devices may be targeted individually by identifier, by one or more tags, or as an entire fleet.
4.5.2 A deployment target is evaluated at the time of deployment creation. Devices provisioned after a deployment is created are not automatically included.

---

5. Application Management

5.1 Applications

An application is a containerized workload intended to run on one or more Wendy OS devices. It is delivered as an OCI-compliant container image containing an embedded manifest file that declares the application's identity, required device resources, and runtime configuration. Developers are responsible for building and publishing the container image; Wendy Cloud does not build images.

The lifecycle of an application is: an application record is created in Wendy Cloud; one or more releases are published referencing specific container images; deployments install and run those releases on targeted devices; a deployment with the Absent state removes the application from devices; the application record may be deleted once all devices have converged on Absent or all deployments have been cancelled.

The manifest embedded in the image declares:

• A unique application identifier in reverse-domain format (for example, com.example.myapp).
• The application version.
• The device resources the application requires, declared as entitlements. An application may only access a device resource if it has declared the corresponding entitlement. Entitlements are enforced at runtime by Wendy OS.
• Optional runtime configuration including a readiness probe and lifecycle hooks.

The following entitlements are supported:

5.1.1 An application has a display name set in Wendy Cloud and a system identifier declared in the embedded manifest. The display name is a human-readable label and may be changed at any time. The system identifier is set by the developer in the manifest and must be consistent across all releases of the same application; it is how the cloud and Wendy OS track which application a release belongs to. The system identifier must be unique within the organisation.
5.1.2 Members, admins, and owners may view applications. Viewers may not view applications.
5.1.3 Members, admins, and owners may create applications.
5.1.4 Admins and owners may delete an application. An application may not be deleted while any of its releases have an active deployment on any device.
5.1.5 Admins and owners may issue a fleet-wide removal for an application. This creates a single Absent deployment targeting every device that currently has the application installed, regardless of how those devices were originally targeted. Devices that are offline at the time will receive the removal instruction when they next connect.
5.1.6 Deleting an application record may only be done after all devices have converged on the Absent state, or after all active deployments targeting it have been cancelled.

5.2 Releases

5.2.1 A release is a named, immutable version of an application. It references a container image by its content digest, ensuring the artifact cannot change after the release is created. The manifest embedded in the image at the time of release creation is the version of record for that release's entitlements and runtime configuration.
5.2.2 The cloud does not host container images. A release references an image stored in an external container registry. The cloud verifies the image is accessible at the time of release creation.
5.2.3 Viewers, members, admins, and owners may view releases.
5.2.4 Members, admins, and owners may create releases.
5.2.5 Releases may not be modified or deleted after creation.

5.3 Deployments

5.3.1 A deployment expresses the desired state for a set of devices. It specifies a release and one of three running states:

5.3.2 Members, admins, and owners may create deployments.
5.3.3 Supersession is per-device. When a new deployment is created for an application, it supersedes the prior deployment only for the devices it targets. For each such device, the prior deployment's desired state is replaced by the new one. Devices targeted by the prior deployment that are not targeted by the new deployment continue to follow the prior deployment unchanged.
5.3.4 Devices receive and apply deployment instructions asynchronously. The cloud does not wait for device confirmation before recording the deployment as created.
5.3.5 A device is considered converged on a deployment when its reported state matches the deployment's desired state for every targeted application.
5.3.6 Admins and owners may cancel a deployment that has not yet converged. Cancelling a deployment stops the cloud from delivering further instructions for it but does not revert any changes already applied on devices.

5.4 Deployment Status

5.4.1 For each targeted device, the cloud reports one of the following per-device states:

5.4.2 The cloud records the time the instruction was last delivered to each device and the time each device last reported its state.
5.4.3 Viewers, members, admins, and owners may view deployment status.

5.5 Ad-hoc Control

5.5.1 Members, admins, and owners may instruct a specific device to start, stop, or remove a specific application immediately, outside of a versioned deployment. This is intended for out-of-band operational needs where bypassing the normal deployment workflow is appropriate.
5.5.2 An ad-hoc instruction does not create a deployment record and does not affect the desired state of any active deployment. If an active deployment targets the same application on the same device, the deployment's desired state will be re-delivered on the next check-in and will override the ad-hoc change. This is intentional: the deployment represents declared intent, and ad-hoc control is explicitly an out-of-band intervention. To make a change permanent, create a new deployment.

5.6 Application Runtime

Once installed on a device, an application runs as a container managed by Wendy OS. Runtime behaviour — restart policies, readiness probes, and lifecycle hooks — is specified in the Wendy OS requirements. The following requirements describe what the cloud tracks as a result of that runtime behaviour.

5.6.1 The cloud receives the cumulative restart count and last exit signal from each device as part of reported state. This data feeds the crash loop notification condition in section 6.5.
5.6.2 If an application fails to start on a device for any reason, the cloud reports that device as not converged for the active deployment.

Persistent storage

5.6.3 An application may declare one or more named persistent storage volumes in its manifest. A volume persists across application restarts, updates, and re-deployments.
5.6.4 Two applications on the same device that declare a volume with the same name share that volume. Shared volumes are not isolated between applications.
5.6.5 Deploying an application with the Absent state removes the application from the device but does not delete its persistent volumes. Volume deletion is a separate action and is not currently managed through Wendy Cloud.

Entitlement enforcement

5.6.6 An application may only access a device resource if it has declared the corresponding entitlement in its manifest. Access to undeclared resources is blocked by Wendy OS.
5.6.7 If a target device does not have a hardware resource required by an entitlement, the application will fail to start on that device. The cloud reports the device as not converged.

---

6. Observability

Devices emit structured telemetry to the cloud following the OpenTelemetry (OTEL) specification. Three signal types are supported, each serving a distinct purpose:

• Logs: Timestamped text records of discrete events, such as application start, errors, or status changes. Use logs to diagnose specific incidents and understand what happened at a particular moment.
• Metrics: Numeric measurements recorded over time, such as CPU usage, temperature, or application-defined values. Use metrics to monitor trends and detect anomalies.
• Traces: End-to-end records of an operation as it flows through one or more components, capturing how long each step took. Use traces to diagnose latency and understand dependencies between application components.

Each signal is attributed to its originating device and application.

6.1 Logs

6.1.1 The cloud receives and retains structured log entries from all connected devices.
6.1.2 Each log entry carries at minimum: originating device identifier, application identifier, severity level, timestamp, and message body.
6.1.3 Log entries are retained for a period configurable by owners and admins. The default retention period is 30 days.
6.1.4 Members, admins, and owners may query logs filtered by device, application, severity level, and time range.
6.1.5 Members, admins, and owners may follow the live log output of a specific application on a specific device as it arrives.
6.1.6 Viewers may not query logs or access live log output. Log data is accessible to viewers only through dashboards shared with them.

6.2 Metrics

Metrics are divided into two categories:

• System metrics: Hardware and operating system measurements reported automatically by Wendy OS, including CPU usage, memory usage, storage usage, device temperature, battery level (where applicable), and network throughput.
• Application metrics: Custom numeric measurements defined and emitted by the application using the OpenTelemetry SDK. These are defined entirely by the application developer and may represent anything relevant to the application's behaviour.

6.2.1 The cloud receives and retains both system metrics and application metrics from all connected devices.
6.2.2 System metrics are reported automatically by Wendy OS without any application-level configuration.
6.2.3 Application metrics are defined and emitted by the application using the OpenTelemetry SDK.
6.2.4 Data retention for raw metric data points and aggregated data is configurable by owners and admins per organisation. The default retention periods are 30 days for raw data points and 12 months for hourly and daily aggregates.
6.2.5 Members, admins, and owners may query metrics for a specific device and application over a selectable time range.
6.2.6 Viewers may not query metrics directly. Metric data is accessible to viewers only through dashboards shared with them.

6.3 Dashboards

6.3.1 Members, admins, and owners may create dashboards composed of log queries and metric charts.
6.3.2 A dashboard may be shared with any member of the organisation, including viewers.
6.3.3 Viewers may view dashboards that have been shared with them. They may not create or modify dashboards.

6.4 Application Data

Applications may produce data beyond logs and metrics — for example, files generated by processing, recorded video, inference results, or sensor readings. The cloud does not provide a general-purpose data storage or retrieval mechanism for this output. Applications are responsible for exposing or exporting their own generated data. The following mechanisms are available:

6.4.1 Structured numeric output may be emitted as application metrics via the OpenTelemetry SDK and queried through the cloud.
6.4.2 Textual event output may be emitted as log entries via the OpenTelemetry SDK and queried through the cloud.
6.4.3 File-based output is written to named persistent volumes on the device (section 5.6). Members, admins, and owners may browse and download files from a device's named persistent volumes through Wendy Cloud. The device must be online for this operation.

6.5 Notifications

Notification destinations

Notification destinations are reusable, named resources configured at the organisation level. A destination specifies a delivery mechanism and its credentials. Once configured, a destination may be referenced by any number of notification rules without reconfiguration.

6.5.1 Owners and admins may add, update, and delete notification destinations.
6.5.2 Supported destination types include: email address, webhook URL, Slack channel, Microsoft Teams channel, and PagerDuty service.
6.5.3 Destination credentials are stored securely and are not exposed after initial configuration. They may be updated or deleted at any time by owners and admins.

Notification rules

A notification rule specifies a trigger condition, the set of devices it monitors, and one or more destinations to deliver to when the condition fires.

6.5.4 Owners and admins may create, modify, and delete notification rules.
6.5.5 A notification rule targets one of: all devices in the organisation, all devices matching one or more tags, or a specific set of devices by identifier.
6.5.6 The following trigger conditions are supported:

6.5.7 Each notification rule may include a custom message to be included in the notification.
6.5.8 Each notification rule references one or more configured destinations. All referenced destinations receive the notification simultaneously when the rule fires.
6.5.9 Notification delivery is not gated by organisation role. A destination may be any address or endpoint regardless of whether the recipient is a member of the organisation.

---

7. Audit

7.1 The cloud maintains an append-only audit log of all write actions performed within an organisation. Read-only actions (viewing, querying, tailing logs) are not audited.
7.2 Audited actions include:

• Member invitations and removals
• Role changes
• Directory integration configuration, synchronisation, and disconnection
• Directory-provisioned membership changes
• Enrollment token generation and revocation
• Certificate revocation
• Application and release creation
• Application deletion
• Deployment creation and cancellation
• Ad-hoc device control
• Machine user creation and deletion
• PAT creation and revocation
• Per-organisation PAT access changes
• Notification destination creation, modification, and deletion
• Notification rule creation, modification, and deletion
• Dashboard creation, modification, sharing, and deletion
  7.3 Each entry records the actor (human user or machine user), the action performed, the affected resource identifier, and the UTC timestamp.
  7.4 Failed actions are not recorded in the audit log. Only actions that were accepted and processed by the cloud are audited.
  7.5 No user, including the owner, may modify or delete audit log entries.
  7.6 Admins and owners may query the full audit log for their organisation. Members and viewers may query only entries where they are the actor.
  7.7 Audit log entries are retained for a minimum of 12 months and may not be deleted before that period expires.