Audit logging

Every meaningful action in Dalea is recorded in an audit log. When you need to answer "who did what, when, why", this is the page you'll come back to.

What's logged

The audit trail captures state-changing events across every service. A non-exhaustive list:

• Failed sign-ins and failed API-key authentication, plus password changes
• Member invitations, role changes, removals (org and workspace level)
• Workspace creation, deletion, settings changes, OAuth client management
• Document creation, edits, version snapshots and restores, archive and permanent delete
• Schema changes (table create, column update, naming-scheme change), including the reason for change the user typed
• Result batches created and superseded, and the finalization sweep that runs when a document is approved or reopened under a review policy
• Inventory item registration, container moves, check-in and check-out, consumption, quantity adjustments
• Data imports and exports
• Template publishes and package publishes to dalea.market
• API key creation and revocation
• Failed and denied requests, emitted as <service>.request_failed and <service>.request_denied

Successful sign-ins are not audit events. Your own recent sessions, including expired ones, are in Login History instead.

Each event records the actor (id, name and type), timestamp, action, target type and id, result, service name, severity, IP address, auth method, and any details the emitting service attached. Destructive actions also carry the reason for change, and actions behind an e-signature carry the signature id. Request-scoped records add the HTTP method, matched route, path and status code.

Where to find it

The audit trail is workspace-scoped. There are two surfaces:

Reads always carry a workspace context. An org Owner or Admin can open any workspace's Audit Reviews tab, because their org role grants every workspace permission, but there is no single org-wide view. Cross-workspace and cross-org queries are a platform-admin surface. There is no live tail.

Filters

The Audit Reviews tab itself offers one toggle: all actors, or me only. A member without the View Audit Reviews permission is force-scoped to their own actions, and asking for another actor is refused.

The audit-trail API behind it accepts more, if you are querying it directly:

• Actor: a user id, to see everything one person did.
• Service: one of auth, inventory, documents, addons, data, storage, market, ai, worker, mcp, bug-report, e-signatures.
• Action prefix: data. or documents.review, to keep one family.
• Action verb: deleted, request_denied, matched as an action suffix.
• Excluded action prefixes: drop noisy families such as ai.tool.
• Time window: startTime and endTime; unset means the last 90 days.

There is no filter for outcome, for a specific target object, or for the member's role.

Exporting

Compliance audits, regulatory submissions, and SIEM ingestion all want the audit log in machine-readable form.

Choose the format, optionally narrow to a set of services, and set a start and end date. Every format carries a SHA-256 hash of a canonical encoding of the entries, so an inspector can recompute it from any of the three and confirm the export is a true copy. There is no separate signature sidecar and no .zip.

Exporting needs the workspace Export Audit Trail permission and an e-signature, and the export itself is recorded as audit.trail_exported.

Retention

Retention is infrastructure-level and identical on every tier: audit records stay hot for 180 days, are then archived to cold storage, and are deleted at 10 years. That is what lets labs answer 21 CFR Part 11 / GxP "show me the audit trail from 2031" without keeping decade-old records hot.

What the tier controls is how far back you may query:

Audit reasons

Many actions in Dalea prompt for a reason for change (EU GMP Annex 11): schema changes, archives and permanent deletes, inventory consumption, removing an org member. The reason is free text but captured permanently on the audit record.

Encourage the habit:

• "Adding metabolite_id column to support PK study DLA-7-Phase-2."
• "Superseding batch with re-recorded standards after pipette calibration."
• "Consuming lot 24-088: expiration past plus QC failure."

Specific reasons make audits much faster and reduce the chance you have to re-derive context two years later.

E-signatures

E-signatures are available on every tier. They are gated by workspace permissions and review policy, not by your subscription.

Some actions always demand one, such as exporting the audit trail; others are turned on through a document review policy. At that point the user re-authenticates with a passkey, with password plus TOTP, or through a linked Google or Microsoft account, and the signature is bound to the action and recorded on the audit record via its signature id. This is what underpins 21 CFR Part 11 compliance.

Privacy

Any workspace member can read their own audit trail, and their own recent sessions under Login History. Reading the whole workspace trail needs the View Audit Reviews permission. Auditing the audit log itself is also captured: every query is logged as audit.trail_queried and every export as audit.trail_exported.

Tips

What's next