> ## Documentation Index
> Fetch the complete documentation index at: https://docs.acrity.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Data handling

> How Acrity processes repository, review, and configuration data without storing analyzed code.

Acrity was designed to review code changes without storing analyzed repository code. The system processes the minimum needed to run reviews, audit, usage metrics, and integrations configured by the workspace.

<Note>
  Acrity does not keep a durable copy of your code tree. Diff content is processed transiently and, for large changes, may be cached at rest for a limited period with automatic expiry (up to 24 hours). Note that suggested-fix snippets can appear in durable review records.
</Note>

## What Acrity processes

During a review, Acrity can process information needed to understand the change:

| Category            | Examples                                                                  | Use                                               |
| ------------------- | ------------------------------------------------------------------------- | ------------------------------------------------- |
| Repository metadata | provider, organization, repository, branch, pull request or merge request | identify the change and apply workspace policies  |
| Change metadata     | author, title, description, changed files, review status                  | run the review and present history                |
| Change diffs        | diff snippets needed during analysis                                      | transiently assess the impact of the change       |
| Settings            | review tiers, language, branch rules, linked credentials                  | respect the policy defined by the workspace admin |
| Results             | findings, severity, decision, suggestions, execution telemetry            | show audit, reports, and history                  |

## What Acrity does not do

Acrity does not clone and store a complete copy of the repository as product data. Acrity does not keep a durable copy of your code tree, publish customer code, expose credentials in API responses, or turn private repositories into public training material.

Diff content is processed transiently. For large changes, it may be cached at rest for a limited period with automatic expiry (up to 24 hours). Suggested-fix snippets can appear in durable review records.

## Durable review records

Durable records prioritize audit and operational information:

* which workspace and repository were reviewed;
* which pull request or merge request generated the analysis;
* review decision, severities, and findings;
* aggregated counts, times, and costs;
* suggested fixes and supporting evidence needed to explain the result, which can include code patches;
* publication state in external providers, when applicable.

These records help workspace admins answer questions such as "why was this PR blocked?", "when did the review run?", and "which configuration was active?" without requiring Acrity to keep analyzed repository code.

## Sensitive data

Credentials, OAuth tokens, connector tokens, and API keys follow separate controls:

* credential and OAuth secrets are stored with strong encryption at rest;
* API keys are not stored in plaintext;
* one-time displayed tokens should be stored by the workspace admin in a secrets vault;
* Console and API responses show metadata, status, and last characters when needed, not the complete secret.

See also:

* [Credentials and tokens](/en/security/credentials-and-tokens)
* [API key security](/en/security/api-key-security)
* [Webhook signatures](/en/security/webhook-signatures)

## Best practices for customers

1. Connect only repositories that should be reviewed by Acrity.
2. Use dedicated credentials for Acrity, with the minimum sufficient permissions.
3. Separate workspaces by environment, unit, or customer when administrative isolation is required.
4. Periodically review credentials, API keys, webhooks, and workspace members.
5. Use connectors for private VCS providers when company policy requires VCS tokens to remain in the customer's environment.