Jern Cloud docs

Receipts and evidence.

Every attempt ends with a receipt: tokens against cap, files touched against the blast radius, policy decisions, network contacts, which sandbox held. The receipt is a check on the pull request, and the exact trace behind it is encrypted evidence you can open from the session.

The receipt on the pull request

Every attempt that publishes a pull request puts its receipt on that pull request as a GitHub check run named Jern receipt, so a reviewer sees what the attempt was allowed to do and what it did without opening the dashboard. The check's summary is a table of the facts the receipt pins, and nothing from the trace's content:

Row	What it says
Outcome	The runner's completion report and the attempt's status.
Policy	The pinned path, digest, and source: the repository's baseline or a workspace profile.
Model	The session's model and the number of gateway calls.
Tokens	Gateway-metered input and output against the session's cap.
Estimated spend	A list-price estimate; your provider bills the tokens, Jern bills none.
Files touched	The changed files against the blast radius: `src/a.py +3 −1; 1 of at most 5 files, 4 of at most 200 lines changed, protected: migrations/`.
Services	The declared services and which the agent started.
Network	The allowed hosts and how many times each was contacted.
Sandbox	The runner's confinement, stated.
Receipt digest	SHA-256 of the receipt the runner derived.

The conclusion is success for a successful or unchanged attempt, neutral for an interrupted one, and failure otherwise. The details link opens the session. The check is created from the App's identity with a token scoped to checks alone; if it cannot be created, the pull request still opens, only without the check.

The blast radius

A baseline may bound a run's edits beside the paths it allows: paths no edit may touch, a maximum number of files edited, and a maximum number of lines changed. The runtime enforces them at edit time and the tightest source wins; a denied edit tells the model which limit it would have reached. The session header shows the limits with the policy, and the receipt reads them against what happened.

The trace

Behind the receipt is the exact trace the runtime wrote: every model call, every tool call and its result, every policy decision. It is encrypted before it reaches a database, under keys held in a key management service, and can be opened from any assistant turn in the session. What the session shows live while an attempt runs is a projection relayed by the gateway and is never stored; the trace is the record.

Retention

Evidence is kept for the number of days the workspace sets under Settings › Evidence, then purged by a daily sweep; the audit log records each purge. Your messages and the agent's replies are stored in plaintext so the dashboard can show them, and are redacted after the same window. The security page describes the full data flow, including what is not defended against.

The audit log

Every workspace keeps an append-only audit log: sessions started by triggers and schedules, refusals, approvals, merges, memory edits, settings changes, purges. Refusals and merges are also notifications in the dashboard, each opening the session or repository it is about. Admins can export the log under Settings › Evidence.