Data, Privacy, and Analysis

Ansight keeps normal app-session captures and workspace quality history on the developer machine. The captured data belongs to you: it is stored as ordinary session files and a local SQLite database, and it can be exported without using Ansight cloud sharing.

This page covers host-side evidence collected by Ansight Studio or the headless CLI. Your source-controlled ansight/ workspace remains in the directory you manage, whether that is the app repository or a separate location.

Local by default

During normal capture, the instrumented app sends evidence to the local Ansight host. The host writes it to the current user’s application-data directory. Normal local capture does not use a cloud relay, and opening a capture in Studio or the loopback session explorer does not upload it.

Capture data can include sensitive information:

• app, device, build, and runtime metadata;
• logs and application events;
• screenshots and visual-tree text;
• telemetry and performance measurements;
• touch input;
• annotations and analyses; and
• app-requested artifact files.

These capture files are not an encrypted vault. They are ordinary local JSON, images, artifacts, and SQLite data protected by the operating-system account, filesystem permissions, and any full-disk encryption you have enabled. Treat the data directory and every exported copy as sensitive development data.

Test secret values are separate. Definitions contain aliases only, while values are kept in the operating-system credential vault, a configured encrypted CLI store, or an environment variable whose name matches a declared alias. Secret values are not written into workspace JSON merely because a test uses them. The app itself can still display or log sensitive content, so capture review and sanitization remain important.

When data leaves the machine

Local storage is the default, but these explicit workflows create another copy:

• ZIP export writes a portable archive to the path you choose.
• Sanitized export writes a new filtered archive and leaves the local capture unchanged.
• Cloud sharing exports and uploads a replay to the selected team, authenticated audience, or public audience.
• Cloud trend upload copies selected local quality measurements and trend decisions into organisation history.
• Cloud test tracking uploads run summaries and counts, not prompt or validation bodies, logs, screenshots, secrets, or source files.
• Hosted workspace testing can send model inputs and tool interactions to the configured hosted runner or model provider; that processing is separate from local capture persistence.

Cloud features require sign-in, an exact registered App ID for product-data uploads, and the relevant organisation entitlement. They are never required for local analysis. ansight session share sanitizes by default; --no-sanitize deliberately uploads the raw capture and should be used only after review. See Sanitizers and Exports and Handoff.

Find the data directory

Studio and the CLI have separate defaults. Both use a base folder containing data/, logs/, and temp/.

When the CLI uses --data-dir <path> or ANSIGHT_DATA_DIR, application data is stored beneath <path>/data.

Ask the CLI which base directory it is using instead of guessing:

ansight doctor
ansight host status --json

ansight doctor prints Data: <base-directory>. Append data to that base to locate the application-data files described below. A resident host’s structured status includes the same base path as dataDirectory.

If Studio cannot write its preferred platform directory, it can fall back to a .cache/data directory beside the installed executable. Check the active installation before scripting an absolute path.

Storage layout

The important local paths are:

<base-directory>/
  data/
    session-captures/
      <app-id>/
        <session-id>/
          session.json
          device-profile.json
          logs.json
          log-streams.json
          application-events.json
          metric-channels.json
          telemetry/
          images.json
          images/
          touches.json
          visual-trees/
          artifacts/
          annotations.json
          analyses.json
          quality-results.json
    quality/
      quality.sqlite
  logs/
  temp/

Folder names are filesystem-sanitized forms of the App ID and session ID. A capture contains only the evidence that was enabled and received, so some files or folders may be absent. While a session is active, the store can also contain append-oriented JSONL files and segmented data that are compacted later.

quality-results.json is the per-session quality sidecar when workspace quality evaluation ran. The SQLite database is separate historical state used for cross-run measurements and trends.

Preferred: export a complete session

Use the versioned session archive when another tool or person needs a complete, portable snapshot. This avoids reading a directory while the host is still writing or compacting it.

Find the session ID and export it:

ansight session list --json
ansight session export <session-id> session.zip

The ZIP preserves session metadata and the available logs, telemetry, screenshots, visual trees, touches, annotations, analyses, and artifacts. It can be unpacked for your own Python, R, SQL, notebook, or command-line workflow, and it can later be re-imported:

ansight session import session.zip

For sensitive evidence, create a sanitized copy instead:

ansight session sanitize <session-id> sanitized-session.zip

The built-in sanitizer writes a report into the archive. A workspace-owned sanitizer can be selected with --sanitizer ansight/sanitizers/team-safe.ts.

Extract one kind of session evidence

CLI inspection commands return versioned structured JSON without requiring raw filesystem access:

ansight session show <session-id> --json
ansight session logs <session-id> --limit 10000 --json
ansight session metrics <session-id> --limit 10000 --json
ansight session images <session-id> --limit 10000 --json
ansight session touches <session-id> --limit 10000 --json
ansight session trees <session-id> --limit 10000 --json
ansight session artifacts <session-id> --limit 10000 --json
ansight session annotations <session-id> --limit 10000 --json
ansight session analyses <session-id> --limit 10000 --json

Redirect the JSON output to a file when feeding another analysis tool. These host contracts are preferable to depending on internal filenames that may evolve.

Read a per-session folder directly

Direct reads are useful for exploratory scripts because most capture metadata is JSON and binary evidence remains in named subfolders.

Use a completed session, or stop the writer before copying the directory. Do not edit files in place: Studio indexes session.json, and partial writes or manual mutations can make the capture inconsistent. If you need a stable raw working set, copy the entire <session-id> directory and analyze the copy.

Treat JSONL, segmented logs, image filenames, and other internal layout details as implementation formats rather than a long-term API. Prefer a session ZIP or CLI --json contract for repeatable tooling.

Export quality and trend history

The supported path is the host’s versioned JSON response:

ansight test quality-history --limit 10000 --json
ansight test quality-history \
  --app-id com.example.app \
  --measurement login-responsiveness.fps-p10 \
  --json
ansight test quality-history \
  --trend login-responsiveness.fps-p10 \
  --group "Secret Garden" \
  --json

The result includes the database path plus per-run measurement records and separate historical trend decisions. The trend ID is the monitored measurement key because its authoring policy is embedded on that measurement. Use this route when building durable integrations because it follows the current host contract even if the underlying SQLite schema changes.

Analyze the SQLite database directly

The database is stored at:

<application-data>/quality/quality.sqlite

Its primary tables are:

• quality_measurements for numeric measurement results and run, app, device, cohort, group, and status context; and
• quality_trend_results for current/baseline comparisons, regression state, deltas, and app-version context.

The database uses SQLite WAL mode. If Ansight is running, do not copy only quality.sqlite and ignore its -wal file; that can produce an incomplete snapshot. Stop the host first, or use SQLite’s backup command to create a consistent analysis copy:

sqlite3 "/path/to/quality.sqlite" \
  ".backup '/path/to/analysis/quality-copy.sqlite'"

Then query the copy without risking the live store:

sqlite3 -header -csv "/path/to/analysis/quality-copy.sqlite" \
  "SELECT evaluated_at_utc, app_id, app_version, measurement_key, value, unit, measurement_status FROM quality_measurements ORDER BY evaluated_at_utc" \
  > quality-measurements.csv

sqlite3 -header -csv "/path/to/analysis/quality-copy.sqlite" \
  "SELECT evaluated_at_utc, app_id, trend_id, comparison, status, current_value, baseline_value, relative_delta_percent FROM quality_trend_results ORDER BY evaluated_at_utc" \
  > quality-trends.csv

Use read-only queries against your copy. The schema has an internal PRAGMA user_version and can evolve with Ansight, so inspect .schema and avoid writing records back into the live database.

Retention, backup, and deletion

Pin important sessions before cache cleanup:

ansight session metadata <session-id> --pin
ansight session cache status
ansight session cache compact --compaction-age-days 30
ansight session cache plan --retention-days 90 --max-cache 5GiB

Compaction preserves inactive captures in ZIP archives and reduces their disk footprint. Opening a compacted session expands it automatically and restarts its 30-day compaction age. Live sessions are skipped; pinned historical sessions may be compacted but remain protected from deletion. cache plan and cache prune are previews unless --apply is supplied. Export or copy data before intentionally deleting it:

ansight session delete <session-id>

Session folders and quality history are separate stores. Deleting a capture removes its per-session directory; it does not rewrite the independent quality history database. Plan retention for both stores when your project has legal or organizational data-lifecycle requirements.

Related docs

• Workspace 101
• Quality
• Trends
• Sanitizers
• Session Capture
• Exports and Handoff
• Security