Documentation

Data handling

Dokima runs from your workspace. Its configuration, review state, logs, prompts, accepted findings and generated HTML report are stored locally.

Local files

Dokima creates:

.dokima/
  config.json
  state/
  prompts/
  logs/
  backups/

dokima-report/
DOKIMA.md

The exact state files grow as review work is accepted. Backups are compressed, kept for up to 30 days and capped to the newest 50 archives.

Source processing

Dokima delegates bounded analysis roles to the command-line AI runner you configure. That runner receives source and project context as required by the task.

How that material is transmitted, processed and retained depends on:

• the runner and model you choose;
• your provider account and organisation settings;
• provider terms and data-retention policies;
• any regional or enterprise controls you have enabled.

Do not treat “runs locally” as meaning source can never leave the computer. Review your runner configuration and provider commitments.

Runner permissions

Default profiles use read-only or sandboxed execution where supported. Dokima also makes canonical .dokima/state read-only during a runner call, restores direct mutations and rejects the run if the runner attempted to change that state.

The customer can configure custom runner arguments. Any move away from the shipped read-only defaults is the customer’s decision and should be reviewed.

Logs and deletion

Lifecycle logs are stored under .dokima/logs/. Detailed failure logs can include the generated prompt, runner command and runner output, so handle them as project-sensitive material.

To remove Dokima data from a workspace, remove .dokima/, dokima-report/ and the optional DOKIMA.md file. Remove the installed binary separately. Back up any finding history you need before deletion.