Viewport Docs

What Viewport records for runs, approvals, provider actions, and team administration.

Viewport records decision and execution evidence so a team can answer:

what triggered this
what policy applied
who approved it
what the worker did
what provider side effects happened
what it cost or used

For the current launch path, treat the audit log as operational evidence for early partners. Do not describe it as SOC 2 evidence, tamper-proof audit, or a full enterprise export system until those programs are complete.

What Is Logged

Surface	Examples
Workspace and team administration	workspace created, member invited, team membership changed.
Pairing and runners	machine/worker paired, runner revoked, worker status changes.
GitOps sync	sync source created, route/policy synced, validation failed.
Workflow run lifecycle	run queued, claimed, blocked, resumed, completed, failed.
Plan and approval decisions	plan proposed, request changes, approved, rejected.
Provider side effects	GitHub PR proposal/execution, Slack completion receipt.
Security denials	wrong workspace, missing reviewer tag, missing credential, stale claim.

Each event should include enough metadata to identify the workspace, team, run, node, actor, timestamp, and denial/receipt code without storing raw secrets.

Run Evidence

A launch-quality run detail should show:

matched route and policy source;
policy hash or composed workflow version;
worker claim and lease/cleanup state;
plan node and gate decision;
approver, decision, message, and timestamp;
provider action receipt with external URL or permalink;
usage and cost when the adapter reports them;
redacted failure details when something fails.

The run detail is usually the fastest audit surface during onboarding. Use the audit log when you need a chronological view across runs and team changes. For a guided first-run inspection, see Read run detail. For the storage boundary between live session frames, workflow run receipts, transcript excerpts, logs, and artifacts, see Trust and privacy.

What Must Not Be Logged

Do not put these in screenshots, support packets, or proof files:

raw provider tokens;
Slack bot/user OAuth tokens;
GitHub installation access tokens;
worker private keys;
pairing codes that have not expired;
bootstrap, claim, or lease tokens;
model API keys;
private repo bodies unless your team explicitly approved that capture.

The product should redact known token-like values in runtime sync and provider failure details. If you see one of the values above in UI, logs, or exported evidence, treat it as a security bug.

Retention And Export

Retention and export are still early-partner surfaces:

run detail and audit rows are available in the hosted app;
support can help collect scoped evidence for a launch partner;
broad self-serve audit export, long-term retention controls, SIEM streaming, and legal/compliance retention policy are enterprise work.

If your rollout needs formal retention or export guarantees, keep that requirement in the launch plan and do not treat the current gated proof as enterprise-ready.

Common Investigations

Who approved this plan?

Open the run detail or plan review item. The approval row should show the actor, decision, timestamp, and reviewer context.

Why did the worker not claim the run?

Check the run readiness/claim denial and then Runner won't claim work. Hosted Viewport, not local vpd, decides whether a worker may claim.

Did Slack/GitHub actually receive the side effect?

Open the provider receipt on run detail. It should include a Slack permalink, GitHub PR URL, or provider reference when the provider returned one.

Did request changes run implementation anyway?

It should not. Request changes should keep implementation queued until the revised plan is approved. See Approval or plan revision is stuck.

Where To Go Next

Launch checklist. What a first team must verify.
Read run detail. How to inspect the first governed run.
Provider integrations. Provider receipts and side effects.
Support packet. What to collect without leaking secrets.
Security. Current launch security boundaries and non-claims.

Audit log