> ## Documentation Index
> Fetch the complete documentation index at: https://docs.checkfu.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Session execution graph

> How Checkfu relates actors, work, checkpoints, effects, and recovery through one Session sequence.

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.

```text theme={"theme":{"light":"github-light","dark":"github-dark"}}
Session event log  ← durable Session order and lifecycle
       │
       ├── SessionThread, Turn, Run, and RunAttempt lineage
       ├── actor generations and child work
       ├── recovery frontiers
       └── Session-visible evidence from specialized authorities
            ├── ActionApproval decisions
            ├── trusted provider-effect receipts
            ├── model-plane Usage receipts
            └── Connection, Memory, Audit, export, and retention references
```

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.

```text theme={"theme":{"light":"github-light","dark":"github-dark"}}
SessionThread
├── Turn: draft a reply
│   └── Run A
│       ├── tool calls and model generations
│       ├── wait → matching response → same Run A
│       └── recovery → same Run A, when supported
└── Turn: shorten the finished reply
    └── Run B
```

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](/guides/export-your-log#session-bundle).

## 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

| Phrase | Means |
| - | - |
| **Portable continue** | Rebuild canonical semantic context from retained Session truth on a compatible, currently qualified lane. Hidden model or harness state is not pretended to exist. |
| **Native resume** | Restore qualified, credential-free continuation material whose exact importer and compatibility coordinates still match. |
| **SSE reconnect** | Resume a dropped event stream with `Last-Event-ID`. That is a cursor, not execution continuation. See [Resume a stream](/guides/resume-a-stream). |

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](/concepts/harness-extensions#generated-harness-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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.