What is recorded, and by which type
Each part of the platform records the work it does, so which records exist depends on what you use.
A session’s event log records the session closing and being deleted, and every change to what it holds: an object
written or deleted, an item posted to a thread, a batch of changes applied to a graph. Creating, editing or reopening
a session writes no event, and a run’s start and end are on the run’s own log, not the session’s. A run’s log holds
its flow and component events in order. The data some components attach to an event, such as a model call’s request
and response, is kept only when the run’s tracing turns on
log_data, which is off unless the session or the run
sets it.
Session Events and
Execution Events define every event type.
List Session Thread Items reads a thread,
List Executions a schedule’s fires, and
List Revisions a blob’s revisions with their authors. A scheduler has a single
revision that is never committed, so earlier versions of its schedules are not kept; its fires are its history.
Attribution
Most records name who made them. A revision names the account that created it, and committing it does not change that. A run names who started it, shown as its Caller in the debugger, and a thread item names who posted it. A workflow writes as whoever started its run, so an item a workflow posts names that account. A schedule starts each run with the standing of whoever created the schedule, so everything a scheduled run writes names the schedule’s author. Some records name no one. An event says what happened and when, not who did it, and a session records no author of its own, so who created, closed or deleted a session is not on the record. An API key has no name of its own: work done with a person’s key is signed with that person’s name. A service account gives automation its own. A CI runner, a worker or an app’s orchestrator running on one signs every revision it creates, every run it starts and every item it posts as that account, so its work is never mistaken for a person’s. Retiring an account keeps everything it wrote attributed to it. On a coding agent’s thread, everything the worker posts names the worker’s identity. Under aguarded posture it
also posts a policy_applied item before each turn, naming the rules in force, and a policy_denied item for every
call a rule refused, naming the rule and the call.
Reading the record
Every reader pages the same recorded logs, a page at a time with a cursor, so a reader that was not watching still catches up on everything that happened:- The debugger lists a session’s runs and pages a run’s event log, rereading it while the run goes on.
- A playground pages its session’s event log while its sync runs, so its widgets show what people, runs and agents wrote to the session.
- The SDK’s
run.events()returns a run’s whole event log, andrun.wait()can hand each new event to a callback as it reads it. - The REST API lists each record directly: List Session Events, List Execution Events and the operations linked under the table.
Retention
The table’s last column is the longest each record stays. Two records age out under limits whose defaults BlobHub changes on request, as Changing a limit explains, and the rest stay until something deletes them:- A finished execution, with its events and data, is kept for 90 days after it ends by default, under
workflow.execution_retention_days. - A schedule’s fire record is kept for 30 days by default, under
scheduler.run_retention_days. - A session, with its objects, its threads and their items, and its events, is never removed by retention. It stays until the session is deleted.
- A revision stays until it or its blob is deleted.
null to keep forever.
Deleting what holds a record removes the record with it, whatever its age: a thread takes its items, a schedule its
fire records, and a session everything in it, its runs and their events included.
Retention has the rules.
What is not recorded
The record covers the work, not the administration around it.- Administrative actions have no audit log. Adding or removing a member, minting or revoking an API key, storing or deleting a credential, and changing who can see an organization or a blob are not recorded as they happen. Settings show the state these actions leave behind, not a history of them.
- Earlier values of what is overwritten. Writing a session object replaces it, and a draft revision is edited in place. The session log records that an object changed, and a commit freezes a revision, but the states in between are not kept.
- No search or analysis. BlobHub does not search or analyze the record for you. You read it by paging, in the debugger, a playground, the SDK or the API, and anything you build on top of it starts from those reads.