// Why this is different

You would have to work to not have a trace.

In a graph or loop framework, observability is something you add: you wrap calls, thread a context object through every layer, and hope nobody forgets on the one path that matters. The trace is a parallel artifact you maintain beside the program, and it drifts the moment someone adds a branch.

An event-driven system has already done the work. Every interaction crossed one bus in one envelope format, carrying its own id, its trace and the id of whatever caused it. Prism computes everything you see from those three fields and a timestamp. The SDK emits nothing extra for observability’s sake - there is no instrumentation to add, and no way to accidentally leave it out.

Read-only by construction

Ordinary consumers join a queue group, so exactly one of them gets each message. A Doppler joins none, which means it sees every Signal and can never take work away from a participant. The bridge is one-way - server to browser, Prism never sends. So attaching one to production is not a conversation about blast radius.

Causality, not log lines

Every Signal carries its parent. The Signal Tree reconstructs what caused what from TASK to FINAL, with sub-tasks, tool calls and clarifications nested under the step that spawned them - and you never passed a trace ID anywhere to get it. Asking “why did this happen” is walking up a tree, not grepping a log.

Lineage beats guessing

A capability-routed run keeps every step on one trace, so “whoever spoke first” would get credit for the whole thing. Prism attributes each Signal to the worker of its nearest TASK ancestor instead - which is what makes a handoff read correctly, including tasks dispatched undirected, where only the answer reveals who took the work.

The topology you actually formed

Constellation draws one run as its execution graph - the Synapse is transport and never appears as a node. Run the same setup twice and edges that didn’t fire every time go dashed, with a structural consistency score behind them. That is a question you cannot even ask of a system whose topology is a diagram you drew.

// Same shapes, three places

You are watching the thing you drew.

A component keeps one silhouette across the whole suite - Neurons are circles, Engrams diamonds, Effectors triangles, Receptors cups. You place that shape on the Genesis canvas, it is written into your project as a real module, and it is the same shape you watch light up here. Prism even gives Receptors their own outer ring, because they are the boundary of the system and burying the edge in the middle of the graph would misrepresent it.

Brain View

The live neural graph

Watch a running Synapse think in real time.

http://127.0.0.1:7071 · -n agent
Brain View - Signals pulse between participants on the bus as REGISTER, TASK, AGENT_OUTPUT and FINAL fire.

What you see

  • The Synapse sits at the centre as a ringed soma with every participant it has seen orbiting it. Neurons, Engrams and Effectors share the inner ring; Receptors get a ring of their own further out, because they are the boundary of the brain and putting the edge of the system in the middle of it would read wrong.
  • Each node is tinted by the last Signal type it emitted, so the graph is a heat map of what each participant is currently doing - and anything that has deregistered fades to grey instead of vanishing.
  • Signals fire as coloured particles the moment they hit the wildcard bus. A request and the reply it provokes are drawn as one two-leg journey - source, through the Synapse, to destination - rather than two unrelated blips, by holding the outbound leg for a few seconds and pairing it with whatever answers on the same trace.
  • A collapsible side panel streams the raw Signal list beside the graph. It can group by task and pathway or run flat, and any row expands from payload to the full envelope.

Why it's useful

  • Get an intuitive pulse of load and flow without tailing logs.
  • See exactly which Neuron picked up a TASK - and spot one that never registered, never fired, or quietly deregistered mid-run.
  • Hover any participant for its kind, capabilities, Signal count and last activity.
  • Demo a live system: the animation makes distributed cognition legible to people who have never read the protocol.
// Inside Metrics

Eleven sections. Nothing measured on purpose.

Metrics is computed entirely from the rolling Signal buffer. Requests are paired to their replies by explicit lineage where it exists and by nearest-earlier match on the same trace where it doesn’t - so a TOOL_CALL finds its TOOL_RESULT, and a RECALL finds its RECALLED, without either side knowing it was being timed.

Health
Tasks completed, failed and still in flight; success rate over decided tasks; retries and escalations.
Latency
Average, max and count across whole tasks, tool calls and memory operations.
Per-task breakdown
One row per top-level task, rolled up over every sub-task it spawned.
Task time composition
Where a task's wall clock went: tool calls, recall, writes, blocked on a person, and the remainder - which is compute.
Human in the loop
Clarification and permission round-trips, and how often a request was approved rather than denied.
Memory effectiveness
Read and write volume, latency, write errors, and how often a recall actually returned something.
Consistency
Whether repeated runs of the same setup produce the same execution graph, scored across every setup that ran twice.
Participants
Activity per Neuron, Engram, Effector and Receptor - totals, outputs, error rate, capabilities, last seen.
Market / coordination
Offers, bids per offer, time to award, decline rate and who keeps winning. Only appears if you actually run a bidding system.
Longest tool calls
The slowest individual TOOL_CALL to TOOL_RESULT round-trips, ranked.
Longest memory recalls
The slowest individual RECALL to RECALLED round-trips, ranked.
// What it is not

A live window, not a data warehouse.

No cost or token accounting

Prism measures time, structure and outcome. There is no spend attribution anywhere in it today - that is a roadmap item, not something to read between the lines of “metrics”.

The buffer is the horizon

Every view reads the last 500 Signals for that Synapse. That is a deliberate window for watching a system work, not a store for querying last Tuesday. If you need history, put a Kafka Synapse underneath - the log is durable and replayable, and Prism is one of several things that can read it.

Composition is approximate

Task time buckets are summed durations, so overlapping tool calls and recalls can sum past the wall clock. The view says so where it shows the numbers rather than implying a precision it does not have.

It runs locally

cosmo prism serves the UI on your machine and connects out to a Synapse. There is no hosted collector, no account and nothing leaves your network - which is also why there is no retention beyond the buffer.

// How it behaves

Built for leaving open.

Several Synapses at once

Each Synapse you attach is a tab, and every tab stays mounted and streaming even when it isn’t on screen - so a background system keeps its socket, its buffer and its per-view state. Switching is instant and loses nothing, the set survives a refresh, and the URL always points at the tab in front, so a Prism link still means exactly one Synapse.

Pause, clear, reconnect

Pause freezes the buffer while the animation keeps playing, so you can stop the list scrolling out from under you without losing the live picture. Clear resets it. If the bridge drops, Prism reconnects on its own. Every view reads the same buffer, so what you see in Metrics is what you can scroll to in the Signal List.

Housekeeping stays out of the way

REGISTER, DEREGISTER, HEARTBEAT and DISCOVER fold into one lifecycle bucket rather than cluttering the task view. Memory traffic that arrives on its own trace - an imprint fired from a hook, say - gets stitched back onto the task that was in flight at the time.

Receptors are inferred, not registered

A Receptor adds no Signal type and no wire format; it emits the same TASK an orchestrator always did and marks its authorship in the envelope’s metadata. Prism synthesises a node from that, which is why the interface a request came in through shows up in the graph without the protocol growing to accommodate it.