> For the complete documentation index, see [llms.txt](https://docs.scorable.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.scorable.ai/concepts-and-examples/usage/execution-auditability-and-versioning.md).

# Execution, Auditability and Versioning

The requests any evaluator or judge makes to a model, and the responses it receives, are traceable within the execution logs on the Scorable platform.

You may export logs at any point for your local storage. Access to execution logs is restricted based on your user role and resource-specific access permissions.

## Data retention

Organization admins control how long the **content** of execution logs is kept. Content means the data flowing through a run — prompts, model responses, input variables, retrieved contexts, evaluator justifications, and tool calls. Setting a retention policy strips that content while always keeping the **metadata**: scores, cost, token counts, timing, model name, tags, and timestamps. Dashboards, trends, and analytics therefore keep working even after content is removed — a sanitized log still shows what was evaluated and how it scored, just not the underlying text.

The setting lives under **Organization settings** (admin only) and offers three policies:

* **Keep forever** (default) — content is retained indefinitely.
* **Delete after N days** — once a log is older than the window you choose, its content is removed automatically. The platform enforces this on a daily schedule.
* **Never store content** — content is never written to the database; only metadata is recorded, from the moment of execution.

Removing content is **irreversible** — there is no way to recover it afterwards, so the interface asks you to confirm when you shorten a window or switch to a stricter policy. Export anything you need to keep before reducing retention.

A note on insights: features that analyze the text of your runs (such as issue classification and insights) operate on log content. With **Never store content**, that content never exists, so these content-based analytics do not run for the organization; score-based metrics are unaffected.

Objectives, evaluators and test datasets are strictly versioned. The version history allows keeping track of all local changes that could affect the execution.

To understand reproducibility of pipelines of generative models, these general principles hold:

* For any models, we can control for the exact inputs to the model, record the responses received, and the evaluator results of each run.
* For open source models, we can pinpoint the exact version of the model (weights) being used, if this is guaranteed by the model provider, or if the provider is Scorable.
* For proprietary models whose weights are not available, we can pinpoint the version based on the version information given by the providers (such as gpt-5.5-2026-04-15) but we cannot guarantee those models are, in reality, fully immutable
* Any LLM request with 'temperature' parameter above 0 is *guaranteed not* to be deterministic. Temperature = 0 and/or a fixed value of a 'seed' parameter usually mean the result is deterministic, but your mileage may vary.