Governance and retention

Governance settings are under Governance & Retention in the administration section.

The audit log

Every significant action is recorded: who did it, what they did, which resource, when, and the originating address. Document lifecycle, permission changes, workflow actions, and authentication events all land here.

The audit log is append-only at the database level. The application’s runtime principal has insert permission on the audit table but not update or delete. This is not a policy the application enforces on itself - it is a grant the database refuses to exceed, so a defect or a compromise in the application cannot rewrite history.

See Database deployment for the principal model this rests on.

The log is readable through the audit report and through the per-document activity timeline. See Reports.

Governance settings: watermarks, retention, and system settings.

Retention

Retention settings control how long soft-deleted content stays in the recycle bin before being purged.

The retention cleanup job runs hourly by default and purges items past the configured period. Until then, deleted items can be restored to their original location.

Purge is not the same as reclaiming disk space

Purging removes the document record. The underlying bytes are content-addressed and may still be referenced by other documents, so they are not deleted at that moment. A separate orphan-byte job reclaims blobs that no longer have any reference and are older than a minimum age.

Two jobs, two intervals. Disk space is freed some time after the purge, not at it. See Background jobs.

Before changing a retention period, run the inactive-documents report to see what the new setting would actually affect. Shortening retention is not reversible for anything it purges.

Watermarks

Watermark settings control whether, and how, a watermark is composited onto generated previews. Position can be set to any of nine anchor points - the three horizontal positions across top, middle, and bottom.

Watermarks apply to the rendered preview, not to the stored file. A user with Download permission receives the original bytes as uploaded, unwatermarked.

This is worth being clear about internally, because it is easy to assume otherwise. Watermarking is a deterrent against casual screenshotting of a preview. It is not a control on distribution - that is what the Download permission is for. See Permission model.

System settings

System settings hold configuration that belongs to the deployment rather than to a configuration file, and can be scoped:

Scope	Applies to
Global	Everyone.
Department	Members of a department.
User	One user.

Values are typed - string, integer, boolean, decimal, or JSON - and validated against their type.

Scoping means a setting can have an organisation-wide default with a department-level exception, without either being expressed as a special case in code.

Signing capability

Whether documents can be signed is itself a governance control, set per folder or per document and inherited down the tree. It is off by default, so signing is something a folder is deliberately opted into rather than something available everywhere.

See Signatures.

Storage integrity

A background job periodically re-reads stored blobs, re-hashes them, and compares against the recorded hash. Because storage is content-addressed, this detects both corruption and files that have gone missing underneath the application - the two failure modes a document management system most needs to know about early rather than at the moment someone tries to retrieve a document.

The job is watermarked, so each pass continues where the last one stopped rather than re-verifying the same first batch forever.

Related

• Reports - reading the audit log and finding retention candidates.
• Folders and documents - the recycle bin and content-addressed storage.
• Background jobs - retention, reclamation, and integrity cadences.