Request observability
Purpose
Syndicate Code exposes request-centric observability so operators can pivot from a checkpoint or audit question to the exact gateway execution history for that request.
This is not a second enforcement path. Enforcement still happens at the control plane and execution boundary. Observability provides correlated evidence after and during execution so teams can investigate what happened.
Correlation model
The observability model is built around a shared request_id.
- gateway telemetry emits accepted, completed, failed, and stream-finalized events keyed by
request_id - checkpoint projections preserve the same
request_id - operator query surfaces resolve by
request_idrather than forcing direct event-store or database access
This lets an operator move from checkpoint review to execution evidence without reconstructing joins manually.
Operator surfaces
Syndicate Code now exposes request observability through these interfaces:
| Surface | Purpose |
|---|---|
checkpointPending | Returns checkpoint detail along with correlated gateway events when request context exists |
gatewayEventsByRequestID | Fetches gateway telemetry directly for a specific request |
syndicate telemetry events --request-id <id> | CLI lookup for request-scoped investigation |
These surfaces are intentionally read-focused. They help with incident review, support triage, and audit evidence collection.
GraphQL correlation
The GraphQL API remains the primary read surface for interactive clients. For observability, two request-level queries matter:
checkpointPending, which now preservesrequestIDgatewayEventsByRequestID(requestID, limit), which returns canonical gateway event records for the specified request
This keeps TUI and automation clients on the same evidence model instead of inventing separate ad hoc APIs for request tracing.
CLI workflow
Typical operator flow:
syndicate telemetry events --request-id req_123 --output table
syndicate telemetry events --request-id req_123 --output json
The CLI is the fastest path for support and compliance workflows where an operator already has a request ID from a checkpoint, audit review, or customer report.
Relationship to Syndicate Gate
When Syndicate Code runs through Syndicate Gate, the shared request_id links:
- the Code-side checkpoint and control-plane state
- the Gate-side inference and routing events
- deployment-specific dashboard surfaces used by hosted and enterprise operators
That cross-product linkage is what turns raw logs into usable evidence.