Activity and decision history
Investigate consumer reads, operation charges and policy decisions
Workspace activity provides several histories with distinct purposes. Query activity records authenticated query/read executions; the operations ledger groups metered work and charges; write-policy decisions retain proposal/approval history. They are not a single universal log of every action or a compliance certification.
You need a Semogram account as owner/admin or an org:manage key for workspace query/usage history. Policy history has its own policy:read and scope checks.
Choose the right record
| History | Inspect | Limits |
|---|---|---|
| Query activity | Caller, start, outcome, duration, release/version, input hash and error | An input hash is not the original input body |
| Operations | Actor/source, status, parent/child work and rolled-up charges | Charges are not proof of business correctness |
| Policy history | Revision, proposal reason, approval/other decisions and actor | Approval is separate from a particular execution |
| Pipeline/prediction record | Original version, evidence, node/model results and errors | Separate execution-specific views |
Investigate an equipment read
Open Settings → Query activity, find the relevant execution time/caller and inspect details. Retain the execution ID, project/query release, error code and input hash. Compare them with the caller's current scopes/grants, remembering current settings may differ from what was true at execution time.
Find the related operation in Usage → operations, then inspect its charges and children when available. Do not infer complete lineage simply from a matching timestamp. Use retained resource/run references to establish relationships.
Use Query activity for reads, Usage for the operations ledger/charges, and Write Policies → exact policy/revision for decision history. Follow run/prediction IDs into their detailed records for output verification.
Inspect the equipment-query execution for this caller and time. Report the exact execution and release IDs, status, diagnostics and any related operation costs. Distinguish missing records from proof that work did not happen. Do not expose credentials or reconstruct a secret input from its hash.GET /api/v1/query-executions?offset=0 lists newest-first, 100 per page; follow nextOffset. Add executionId to inspect a known UUID. Usage operation listing is 50 per page and accepts offset or parentOperationId. All require org:manage.
Policy collection/detail uses GET /api/v1/write-policies and /api/v1/write-policies/<POLICY_UUID> with applicable policy access. Its pagination and revision/decision history are distinct from query executions.
Call query_execution_list with offset or executionId. Use operation_list / operation_charges_get for charges. Use write_policy_get for the selected policy and history. Read completeness and nextCursor; a first page is not all workspace activity.
Evidence and retention
Preserve IDs and secret-free diagnostics for an investigation. Operational audit records may follow configured retention; do not assume indefinite history or that these interfaces provide all raw audit events. Policy revisions/decisions and execution evidence have their own lifecycle. Before recovering a pipeline, inspect retained checkpoints and actual external effects rather than relying only on an activity summary.