Skip to main content
A Session execution graph is a projection over accepted Session execution facts. It relates Turns, Runs, RunAttempts, actors, child work, checkpoints, waits, and accepted external evidence without creating another execution aggregate.
The graph preserves one Session position for accepted facts. It does not absorb the authority of the specialized resource that produced them. The graph does not represent provider caches, credentials, process memory, or an uncommitted output suffix. A native harness may retain provider-supplied thinking and opaque replay signatures in protected continuation records under standard retention. Public text output alone does not establish what that harness retained or erased.

​
One Session writer, replaceable execution lanes

The serialized Session authority appends canonical Session events and advances Session lifecycle. Native harnesses, queues, and supported connected runtimes execute or observe bounded work. Their records do not become another writable Session history. A report must match the original Session and public Run, the current native task and authority, and the expected committed position. Where a RunAttempt is exposed, its generation must also match. A delayed or replaced worker cannot publish into newer work or resurrect settled work.

​
Execution lineage

A SessionThread records execution lineage. A Turn groups a user-meaningful interaction. An independent input or follow-up owns its own public Run intent; supported steering contributes to its targeted Run. Matching wait responses, internal tool rounds, and recovery keep the original Run.
Supported child work keeps its parent relationships. A native helper or subagent does not automatically become an independent public Run. Independent requests remain separate even when their configuration matches. A RunAttempt, where exposed, records an execution attempt. Replacing a worker or restarting a harness can change internal generations without creating a new user request, public Run, or transcript.

​
Event log vs Session Bundle

GET /v1/sessions/{id}/export returns the owned event log: every persisted envelope plus explicit unavailable positions. That is the format checkfu.session-export. It is a complete tape of ordered Session events, not the full graph. A Session Bundle (checkfu.session-bundle) is the signed offline artifact: events or unavailable positions for 1..end_sequence, plus actor, work, interaction, context-snapshot, artifact, and continuation-capsule sections. Each section names its source and any typed gap in the signed manifest, so an empty section never silently means “nothing happened”. The event log alone cannot render every graph, recovery, or learning view. See Export and own your logs.

​
Recovery frontier

Recovery starts from a known accepted position. It preserves the original public Run, resolved inputs, and provider-effect identities. Continuing requires the exact retained state, current resource and action authority, and support for that execution path. A wait or recovery does not select newer context in place of the original pins. Readable history, native continuation, files, and live processes are separate capabilities. Restoring one does not establish the others. Missing authority, state, compatibility, or effect evidence must be visible; the graph cannot invent continuity.

​
External effects are not ordinary replay

Suppose a request reached an external provider and the worker died before the trusted capability or effect boundary accepted its receipt. Restoring a checkpoint does not reveal whether the provider performed the action. The effect remains indeterminate. Recovery keeps the same effect identity and reconciles it through authoritative provider lookup, provider idempotency, an accepted receipt, or an explicit governed decision. Issuing a fresh identity can hide uncertainty and duplicate the effect. An ActionApproval remains the human-decision authority for the exact frozen action. A trusted receipt remains provider-effect settlement. The graph correlates them without collapsing either authority.

​
Portable continue vs native resume

Switching an existing Session thread to a different harness (Session handoff) is not available.

​
Adapter fidelity is evidence-gated

Collaboration, steering, checkpoints, native continuation, portable rebuild, and post-ready replacement are tuple-specific capabilities. A vendor UI, tool name, or self-attested feature list is not proof. Use the current Harness extensions support snapshot for the exact release, driver, sandbox provider revision, policy, and execution target. Unsupported or unobserved collaboration remains explicit; Checkfu does not infer teams or workflows from timing.

​
Retention and ZDR

Standard retention can preserve the content and custody needed for graph and recovery projections. Zero-data-retention and later erasure can leave structural event identities while omitting content, filesystem snapshots, wire evidence, or continuation bytes. The graph does not reconstruct deleted bytes from traces, Usage projections, summaries, a harness transcript, or a provider dashboard.

​
What this does not promise

  • A public Session Bundle operation merely because the domain Bundle format exists.
  • A public operation that switches an idle Session onto another harness unless the current contract serves it.
  • Native resume or post-ready replacement without current exact qualification and retained compatible material.
  • Complete representation of private or unstable vendor collaboration internals.