A store for finished requests and their timings.

Observe

After an application request finishes, ObserveContext can keep the story of that request: which service, which route, how long, and the named steps inside it (login, SQL prepare, execute, scan, snapshot build, encoding). You inspect that store with SQL, or with a dashboard. A personal dashboard can run on your own machine at 127.0.0.1:8766, with no hosted site.

It is a small store on the same PocketContext server the other applications use. It is not a replacement for Langfuse or OpenTelemetry, and a timing is not evidence that the application's own result was correct.

How a trace arrives

sequenceDiagram
  participant You as You, via an app CLI
  participant Wrap as observecontext capture
  participant App as The app server
  participant Store as ObserveContext

  You->>Wrap: capture -- dealcontext sql "SELECT ..."
  Wrap->>App: the real command, tracing opted in
  App-->>Wrap: result plus server timing
  Wrap->>Wrap: one operation grouping client and server
  Wrap->>Store: upload
  Note over Store: operations, traces, and spans stay immutable

Other apps have to turn tracing on and use a server commit that supports it. Observe does not change their pins.

SQL text is stored only when both sides ask for it, and it is capped at 16 KiB. A SQL statement can contain private values, so only people allowed to read the trace should see it. Headers, passwords, URL queries, REST bodies, and result rows stay out.

Who can see a trace

flowchart TD
  user[Ordinary Workspace user]
  own[Their own operations and traces]
  flag[Operator sets can_view_all_traces]
  all[Broader read access]

  user --> own
  flag --> all

One deployment admits verified Google Workspace identities. You read and append your own data. An operator can grant a wider read. The account that uploaded a trace is stored separately from the user and service the producer claimed. A trace is diagnostic data. It is not proof that those claims were authentic.

Stored traces have no automatic expiry in this first release.

What the timings cover

The server measures authentication, SQL prepare / execute / scan, filtered-snapshot work, and result encoding. Ordinary REST calls get a total time, without a split for each app hook. The client wrapper adds HTTP time, including reading the response.

A coding agent's prompt and the full chat session are not collected.