Skip to main content
Open Audit from the Plainrouter sidebar to read past action records for the current workspace. Use Actor and Outcome to narrow the on-screen list, or Download JSON to inspect the underlying workspace audit events. You need a signed-in browser session with access to the workspace. Select the intended workspace before investigating a proposal or exporting its history.

​
Filter action history

Each row summarizes an action and its outcome. Select an Actor or Outcome to narrow the list, and scroll to load older records. The list is an action summary, not a row for every security or lifecycle event. If the list is empty, clear the filters and confirm the workspace. Token, grant, and policy events may exist in the export even when there are no matching action rows.

​
Download workspace audit events

Choose Download JSON. The response contains a data array of workspace audit events ordered by sequence. This export includes the workspace’s event history; the on-screen Actor and Outcome filters do not restrict it. Each exported event includes:
  • event_type, summary, actor type, ID, and name.
  • workspace_id, and related action_batch_id and proposed_action_id when applicable.
  • Structured payload and created_at.
  • sequence, event_hash, previous_hash, and hash_version.
Search the export by batch or action ID to follow a proposal across multiple events. Treat the file as workspace data: it can contain actor identities and action details. Token lifecycle events contain metadata, not plaintext credentials.

​
Download an action decision receipt

For an action with a stored decision receipt, its Audit row shows Download decision receipt. Select it while signed in to the same workspace. This downloads the persisted decision record for that action; Download JSON remains the separate workspace event export. The receipt response contains four top-level fields: Read the terminal status and verification result before drawing a conclusion. A receipt can record failure or compensation; its existence alone does not establish Landed. Provider request IDs and other evidence can be unavailable and are recorded accordingly. The document is stored when issued, rather than rebuilt from current action settings at download time. Later restoration can appear in the separate disposition without rewriting the document, its digest, or chain reference. Read the disposition fields and preserve the historical outcome. Its hash and chain reference support audit inspection; they are not an external signature or independent proof of completeness.

​
Why is the receipt missing or forbidden?

  • No download button: that action has no stored decision receipt. Pending actions and older records may not have one; inspect the workspace event export instead.
  • Access denied: use a signed-in browser session with access to the action’s workspace. An MCP workspace key or Signals secret cannot substitute for the browser session.
  • Receipt not found: confirm the workspace and action. A receipt from another workspace or a missing receipt cannot be downloaded through this action’s link.
For a server integration, use the Actions decision-receipt endpoint or get_action_decision_receipt with a properly scoped Write Workspace key. These are separate from the signed-in download link and do not export the entire workspace audit history.

​
What does an exhausted reconciliation mean?

A receipt with receipt_status: "reconciliation_exhausted" records provider work that could not be settled within the recovery window. The associated action can be execution_uncertain; a batch can remain rollback_incomplete. It is not proof of a successful write, absence of a write, or completed compensation. Use the action’s target and recorded provider evidence to check Meta Ads Manager. Preserve earlier verified or compensated outcomes when assessing a partially completed batch. See stalled-batch guidance.

​
Integrity versions

The JSON export retains the hash and predecessor fields. The current Audit page does not display an integrity verdict or recomputation panel; downloading the file is not itself a verification of the chain.
The hash chain has no external tail anchor. Even successful recomputation of a snapshot cannot independently prove that no tail events were deleted outside that snapshot.

​
Events to follow

Measurement-only events explicitly say NOT LANDED. Do not count them as production execution acceptance.

​
Interpret unavailable outcomes and recovery

An execution verification and a later performance outcome answer different questions. outcome.check_exhausted reports an unavailable outcome with reason outcome_check_exhausted; the execution receipt’s outcome_status is unavailable. It does not undo an already verified action, change its completed batch to failure, or establish a performance improvement. For Resume and budget changes, inspect the stored outcome’s comparison days, counted arrivals, spend, loss threshold and held or lost verdict when present. An eligible lost result can record a separate inverse proposal under outcome_payload.inverse; inspect its batch and verification rather than treating it as completed compensation. See inverse proposal behavior and API payload fields; the immutable decision document and current disposition remain separate. Recovery events can include payload.compensation_recovery_disposition. Read the exact value alongside the action, receipt, and provider proof: Older events may omit this field. Missing evidence means unknown, not restored. Investigate rollback_incomplete rather than repeating a provider write to try to clear the status.

​
Investigate unexpected execution

1

Confirm the principal and scope

In the JSON export, find batch.proposed. Confirm the agent, account, evidence provenance, target-selection boundary, and execution-mode snapshot.
2

Trace both policy decisions

Read the proposal-time result and, for executable work, the execution-time result recorded before the provider call.
3

Confirm the mode and decision

In Ask mode, find the approval or rejection event and confirm the named person and time. In Full mode, trace the automatic admission decision; a per-change human approval is not required.
4

Follow the receipt evidence

Trace execution, raw provider observations, classifications, and terminal verification. An awaiting-verification event is not Landed.
5

Confirm restoration when needed

For failed work, find the compensation and provider-read proof. Escalate any rollback_incomplete event.
6

Revoke access if necessary

Revoke the Plainrouter agent connection or workspace token. Confirm the intended credential or grant is revoked. Revocation does not undo earlier provider actions.

​
What happens to history after account deletion?

Deleting an eligible login account does not erase retained Actions evidence. Approval, audit, batch, and receipt records remain; where they reference the person, Plainrouter retains a disabled user record labeled Deleted user. Historical snapshots are preserved rather than rewritten, so an older export can still contain the actor details captured at the time. The deleted identity cannot sign in or continue using its credentials. Registering again with the same email creates a new identity and does not restore the old access. Account deletion can still be refused when the person owns a team whose workspaces hold retained Actions records. Do not treat deleting a login as a way to delete workspace evidence or undo provider changes. Use Inbox for the human decision and action policy to interpret blocks. If access must end, revoke the workspace token. Drive ownership events apply only to legacy Launcher where enabled.