SITREP Signal Map

Where signals start, how they move, and where truth lives.

This page is the shortest accurate explanation of SITREP’s signal model. It separates matter changes, synthesis execution, live UI state, and diagnostic logs. Those were too easy to blur together in the old page.

7
Signal classes
3
Authoritative stores
2
Workflow steps today
1
Rule: logs are not truth
Jump to

Signal map

Read this left to right: matter changes enter from DMS, specialists reshape them into structured views, the orchestrator runs synthesis inside a workflow, and different outputs are then read by different surfaces. The main distinction is between execution history, live runtime state, and published SITREP state.

gustav-dms emits matter ingress events email · tasks · documents · status MatterOrchestratorAgent ingestEvent() routes updates tracks runtime + publication state CorrespondenceAgent email-derived specialist facts WorkstreamAgent tasks, docs, status workstreams Flex specialists domain overlays like regulatory MatterSynthesisWorkflow Step 1: execute-core-synthesis Step 2: execute-tail-work progress + state sync via Agents SDK runtime_events authoritative per-run execution history used by the runtime timeline Agent live state phase · subphase · runtimeState publication + workflow ids Published SITREP cache DMS matter_insights_cache latest published matter SITREP Observability diagnostic only not matter truth RuntimeHubAgent thin overview projection for the matter grid

What each surface reads

Live runtime

Uses synced MatterOrchestratorAgent state for phase, subphase, runtime state, workflow ids, and publication state.

Runtime timeline

Reads runtime_events. This is the historical execution log for the selected run.

Report content

Fetches the heavy report separately: world model, traces, evals, specialist detail, history.

Static inventory

Fetches the matter list and summary inventory normally. This is not a live stream.

Live overlay

Uses synced RuntimeHubAgent state for active runtime rows only.

Latest published SITREP

Reads the latest published matter SITREP from matter_insights_cache.

What was simplified

  • Matter detail live state now uses direct Agents SDK routing instead of a custom live proxy route.
  • Overview live runtime now comes from synced RuntimeHubAgent state instead of custom SSE.
  • Synthesis is workflow-backed, and the workflow is now split into durable core and tail-work steps.
  • Repetitive runtime dual-emission has been collapsed into shared helpers instead of hand-written pairs.
  • The custom workflow execution table is removed; workflow tracking now relies on Cloudflare workflow tracking plus orchestrator state markers.

Next SDK-native cuts

  • Split core synthesis further into workflow-safe stages: specialists, pass 1, provisional publish, refinement, pass 2, final publish.
  • Reduce remaining UI/API report glue where agent state already provides the live truth.
  • Keep pruning custom orchestration scaffolding whenever Cloudflare Agent or Workflow primitives already cover it.

Which signals are truth, and which are just telemetry

Most confusion came from mixing runtime history, live UI state, and observability logs. This table is the operating contract.

Signal Emitted by Authority Examples Meaning Stored / read from
Matter ingress gustav-dms Authoritative email_received
task_created
task_status_change
document_uploaded
A matter changed. SITREP must ingest new state. MatterOrchestratorAgent.ingestEvent()
Specialist facts Correspondence / Workstream / Flex specialists Authoritative waitingOn
needsAttention
regulatory items
workstream status
Structured specialist views over matter facts. Specialist agent state + section outputs
Runtime lifecycle MatterOrchestratorAgent Authoritative synthesis.started
orchestrator.pass1.completed
world_model.written
Execution history for one synthesis run. runtime_events in the orchestrator
Live runtime state MatterOrchestratorAgent Authoritative phase
subphase
runtimeState
publication state
What this matter is doing right now. Synced agent state to the matter page
Overview runtime projection RuntimeHubAgent Authoritative active matter rows
stuckReason
synthesisVersion
Compact live overlay for the Observatory grid. Synced agent state to the overview page
Published SITREP MatterOrchestratorAgent Authoritative latest published world model
latest provisional world model
Lawyer-facing latest published matter SITREP. DMS matter_insights_cache + report fetch
Diagnostic observability Agents + AI calls + alarm scheduler Diagnostic ai.gateway_error
ai.call_completed
alarm.scheduled
ingestion.routed
Operational debugging and correlation, not matter truth. Cloudflare Workers Observability

SITREP now uses Cloudflare Agents and Workflows more directly than before: live UI state comes from agent state sync, long-running synthesis is workflow-backed, and the overview runtime overlay is an agent projection rather than custom transport. The remaining work is to break core synthesis into more granular durable workflow stages without rebuilding a second custom orchestration layer.