Agent operations · Workflow receipt trails
Workflow receipt trails: every run and every step, sealed
Services 74 and 75 in the services catalog, productized together: an account records each workflow or scheduled-task run once — its label, kind, status and the SHA-256 of what it produced; the output itself is not stored, only its hash — sealed to the ledger, appends a sealed step for each step of the run, and reads a verification summary grouped by workflow, kind and schedule back from those sealed runs. So far 0 runs have been recorded (0 workflow and 0 scheduled task; 0 completed, 0 failed and 0 partial) and 0 steps appended (0 runs carry an output hash, 0 have steps) — every count computed live at this read, labels and summaries never shown here.
74. Workflow receipt trails
seal every step of a multi-agent pipeline. State: live.
75. Scheduled-task verification
prove a cron/job actually ran and what it produced. State: live.
Kinds: workflow, scheduled_task. Statuses: completed, failed, partial.
Run rule: An account records a workflow run once: a workflow_label (text up to 120 characters), a kind — exactly workflow or scheduled_task (default workflow) — an optional schedule_label (text up to 120 characters, for example the cron or job label a scheduled task ran under), a status — exactly completed, failed or partial — an optional summary (up to 2000 characters), an optional output_sha256 — the lowercase hex SHA-256 of what the run produced — and optional started_at and finished_at ISO timestamps (finished_at defaults to the recording time). The output itself is NOT stored, only its hash. Recording seals the run to the ledger and returns its ledger_seq. The sealed run is immutable: its workflow label, kind, schedule label, status, summary, output hash, started-at and finished-at times can never be edited. Later, the account may append steps to the run — each step sealed the same way and appended to the run's steps in order; recording a second or later step is allowed and never rewrites an earlier one (append-only).
- GET /v1/workflow-trails (free, no key) — this index document: the services, their callable surfaces, the run, step and verification rules, the limits and the live usage counts
- POST /v1/workflow-trails/runs (account key, owner only) — record a run: a workflow_label, a kind (workflow or scheduled_task, default workflow), an optional schedule_label, a status (completed, failed or partial), an optional summary, output_sha256 (the SHA-256 of what the run produced; the output itself is not stored), started_at and finished_at
- GET /v1/workflow-trails/runs/{id} (account key, owner only) — read one of this account's runs: its sealed fields, its ledger_seq and its appended steps
- GET /v1/workflow-trails/runs (account key, owner only) — list this account's runs, newest first
- POST /v1/workflow-trails/runs/{id}/steps (account key, owner only) — append a step to a sealed run: a step_label, a status, an optional summary and an optional output_sha256; steps are append-only and the run itself never changes
- GET /v1/workflow-trails/verification (account key, owner only) — this account's verification summary: its runs grouped by workflow_label, kind and schedule_label with run, status and step counts, runs with output, and the last run time and status per group, computed live at read time
- GET /v1/services (free, no key) — the full services catalog these services are pulled from
- GET /v1/bookkeeping (free, no key) — sealed bookkeeping + tax-ready evidence packs (services 39 and 40): the sealed ledger a recorded workflow run can sit beside
A step is appended to a sealed run: a step_label (text up to 120 characters, required), a status — exactly completed, failed or partial — an optional summary (up to 2000 characters) and an optional output_sha256, the lowercase hex SHA-256 of what the step produced (the output itself is not stored, only its hash). Appending seals the step to the ledger as its own entry and appends it to the run's steps in order; steps are append-only and the run's sealed fields never change.
The verification read groups this account's sealed runs by workflow_label, kind and schedule_label and computes live at read time, from the sealed runs only: the run count, the completed, failed and partial counts, the total steps recorded, how many runs carry an output hash, the last run time (the latest finished_at in the group) and the last status (the status of that latest run). Groups are returned in a deterministic order — workflow_label, then kind, then schedule_label. It is a summary of what the account recorded; what sealing does and does not prove is stated in the limits note.
Limits, stated plainly: sealing proves a record was made at that time under that account key — it does NOT prove the underlying job ran on its own, that a schedule fired, or that the recorded output is what the job actually produced. Records are account-supplied and unverified: workflow labels, schedule labels, summaries, statuses and times are what the account recorded, and output_sha256 is the hash the account supplied for output that is not stored here. This is an evidence trail only: it does not run, schedule, monitor or retry any workflow or task.
Related surfaces
The sealed ledgers a recorded workflow run can sit beside: /cap-table and /bookkeeping.
For agents
This service as data: GET /v1/workflow-trails. The full catalog: /services. Start as an agent: /for-agents. Pricing: /pricing. Verification stays free and needs no key.
Every number in this document is computed live from the platform state at the moment of the read — the usage counts from the workflow runs of live accounts (sandbox and canary accounts excluded). Nothing is cached or stored for this document, no number is invented, and zeros are shown as zeros. The public document shows aggregate counts only — never a tenant, a credential, a label, a summary or a run id. Nothing in this service is charged today; verification is free and needs no key. Markdown twin: /workflow-trails.md.