Options: usage log and retention

The On-premises column states the value that applies in an installation on your own premises as long as nothing is set explicitly.

Option	Default	On-premises	Effect
UsageTrackingEnabled	true	as default	one JSONL line per tool call: tool, success, duration, language, client address, user agent, path, format
UsageStoreContent	true	false	additionally the contents: the upload, the result, the create form
UsageDirectory	usage	as default	the location, relative to the installation directory
UsageRetentionDays	30	as default	older logs and files are deleted at the turn of the day
UsageCorpusEnabled	true	false	a long-lived, anonymised second copy of all artefacts for analysing the engine’s quality
UsageCorpusDirectory	usage/corpus	as default	the location of the corpus
UsageCorpusRetentionDays	0	as default	0 = never delete automatically

Where things sit

The log as usage/usage-YYYYMMDD.jsonl, the contents under usage/files/YYYYMMDD/.

Tracking must never break processing

Failures while logging land in the application log, not in the answer to the user.

Why two options are off on-premises

The quality corpus is our basis for analysing the engine

On a customer’s server it would be someone else’s business data with no purpose — hence off there. Anyone who switches it on explicitly gets it; to build an analysis basis for their own documents, for instance.

The same goes for UsageStoreContent: the event lines are useful for operations, the invoice contents rarely are for the operator — and filing them is a data-protection decision nobody should take unasked.

Two things that are not covered here

The activity log in the account area is something else: it shows a tenant’s administrative events and sits in the database, not in the file system. See Activity log.

The application log (logs/) has its own retention of 30 files and is not governed here. See Monitoring.

Values verified against the code on 22 October 2026.