Skip to main content
SimpleFunctions attaches trace ids to long-running and async work so a request, monitor cycle, alert, or portfolio operation can be correlated later. Trace ids are useful when you need to answer:
  • Which user action or monitor cycle produced this result?
  • Which webhook delivery or portfolio tick should support inspect?
  • Which support request or audit note refers to this operation?

​
What gets a trace

Trace ids can appear on:
  • thesis evaluations and monitor cycles,
  • execution intents,
  • portfolio ticks and trades,
  • alert deliveries,
  • public computation outputs where reproducibility matters.
Not every public read needs a trace id. Stateless reads can be reproduced by URL, timestamp, and response metadata.

​
Reading a trace

When a surface returns a traceId, keep it with the user-visible result: 
{
  "ok": true,
  "traceId": "0f8fad5b-d9cb-469f-a165-70867728950e"
}
If you need help debugging a result, include the trace id in the support request. Internal audit tooling can use it to reconstruct the relevant operation.

​
Why this exists

Prediction-market workflows often mix market data, LLM-backed synthesis, user-owned state, and async actions. Trace ids keep those pieces connected without exposing internal storage or implementation details as the public contract.

​
Next steps

Heartbeat

Per-thesis monitor settings.

Snapshots

Public data exports and reproducibility.