Database

We persist evaluation artifacts in MongoDB so they can be replayed, inspected, and surfaced in dashboards.

CLI access

The ct CLI has no direct MongoDB access. Every read and write goes through the viewer's HTTP API, authenticated with a per-user token: run ct login to cache one, or set CONTROL_TOWER_API_TOKEN (the same token for reads and writes). MONGOURI lives only in a viewer deployment's server environment and in the ops/ operator tooling.

Uploads (ct run eval, ct runs make, ct run monitor) need only the API token, with no AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY, because the data host presigns an add-only S3 PUT for the client. Reading a .eval back is a direct S3 GET and uses your own AWS credentials, which must be able to GET the eval-log bucket. Runs uploaded before the S3 migration carry an eval_log_url on the eval-log viewer instead, and reading those needs LOGS_AUTH_PASSWORD; ask the linuxarena maintainers for the current value.

ct run eval --no-upload, ct run monitor <file> --no-upload, ct live commands, and ct run side-task-review operate on local files and touch no remote service. ct traj download and ct traj list read through the website API.

Local caches

Trajectory bundles cache in ~/.cache/control-tower/trajectory-bundles/ and run metadata in ~/.cache/control-tower/runs/; downloaded trajectories default to data/traj/ and run exports to data/run_trajs/. Use the helpers in control_tower.trajectories.io and control_tower.agent_runs.io rather than editing these directories by hand, so the cache stays consistent with Mongo.

Publishing Trajectories to the Website

Uploaded runs appear in the website viewer, where the team can browse them.

Upload while a script runs

All eval entry points, such as ct run eval, upload the .eval log and create the run as soon as the evaluation finishes. Pass --no-upload to disable this.

Upload a saved .eval

For a completed run, ct runs make logs/<file>.eval uploads the eval file (best effort), creates a run document, and uploads the derived trajectories.

Add descriptions and tags in the UI

  • Each run has an optional name and description that you can edit on the website.
  • The upload's metadata (environment, main task, side task, models, scores, etc.) appears as filterable facets, the "tags" in the UI. You can extend them by editing metadata in the web interface.

Guidance on Assigning Tags

  • Each new main task needs a trajectory that passes its scorer; tag it qa.
  • Tag the sabotage trajectories built for each side task (at least one per side task) qa.
  • Add the ai or human tag to these according to who produced them.
  • Tag every sabotage trajectory (one that attempts a main and a side task) straj.

Uploading Sabotage Trajectories (strajs)

For creating and uploading human sabotage trajectories, see Making Sabotage Trajectories.

Terms

See Trajectories for how ct run, ct runs, and ct traj relate.