Where Each Log Lives

Every log the platform keeps is a set of ordinary database rows, reachable from the Architect Panel under Activity, and queryable and exportable like any other data.

Where to find it

Architect Panel → Activity:

• Activity Log — changes, with before-and-after row data and chain hashes
• Record Read Log — reads, with record IDs, row counts and context
• Audit Chain — the chain head, seal and verification state per datastore
• Error Log — type, message, URL, stack trace, user agent and IP
• E-mail Log — account, recipients, subject, body, attachments and result
• SMS Log — number, message, provider message and request identifiers
• Calls — telephone activity
• Correspondence — letters and documents sent
• Satisfaction — survey responses

Everything is in the database

There is no split where some logs live on disk and others in tables, and nothing is written to an external logging service. Stack traces are stored in the error log row itself rather than in a file alongside it.

The practical consequences are good ones: every log is included in the normal database backup, every log can be queried and filtered the same way, and there is no second retention regime to manage or forget about.

What that means for exports

Because each log is a datastore, the ordinary export applies. An extract for an auditor, a regulator or an investigation is produced the same way as any other data export, with the same permissions governing who may take it.

Log contents are sensitive

Worth stating plainly, because it is easy to think of logs as technical rather than personal data:

• The Activity Log holds complete before-and-after copies of rows — including any personal data those rows contained.
• The E-mail Log holds subjects, bodies and attachments — the actual correspondence.
• The SMS Log holds message text and telephone numbers.
• The Error Log holds URLs and stack traces, which can contain identifiers and occasionally submitted values.

Access to logs should therefore be restricted like access to the underlying data, not more loosely because they are "just logs". A read-only auditor account with access to the activity log has access to a copy of everything.

Retention applies here too

Because logs hold personal data, they fall within retention and disposal like anything else. A policy that carefully disposes of case records while keeping an audit log containing full copies of those records has not achieved what it set out to.

Backups include logs

Which is usually what you want, and is worth knowing when estimating backup size — the activity log on a busy system is frequently larger than the data it describes, because it holds two copies of every version.

Before you query directly

Reading log tables with SQL is legitimate for analysis. Writing to them is not: the audit tables carry chain hashes, and any direct modification breaks the chain and cannot be undone.

Worked example

Preparing for an information-rights audit, an administrator lists what personal data is held. Alongside the obvious datastores they include the activity log — which holds copies of every version of every customer record — and the e-mail log, which holds the correspondence. Both are given explicit retention periods and their access is narrowed to two named administrators.

Recommendations

• Treat logs as personal data when they contain it, which is most of them.
• Restrict log access as tightly as the underlying data.
• Include logs in retention, not just business records.
• Never write to audit tables directly.