Status: research / design note, ahead of building a live view.
Context
Tilth's observability is offline-first: tilth visualize renders a finished run's events.jsonl (+ seed-meta.json) into a static chat.html after the fact, by re-parsing the event log. The plan is to investigate real-time rendering of events in a UI (a live session view).
The concern to bake in (Pi §2.4)
Pi's tools return two payloads — text for the model, structured data for the UI — so the UI never has to re-parse tool text. Tilth already got the high-value half right: submit_case / submit_verdict are typed schemas, not prose the visualizer has to scrape. But raw tool outputs (bash, file reads) are rendered by re-parsing events.jsonl after the fact — exactly the pattern Pi designed against.
That's fine for offline rendering. But if a live UI becomes a goal, the split-payload pattern (per-tool-result: model-content vs UI-content) is the move, and retrofitting it is more expensive than designing for it from day one.
Recommendation
When we build the live view, design tool results as split payloads at the source rather than re-parsing the event stream in the UI. Treat the existing events.jsonl renderer as the offline consumer of the same structured data, not the source of truth the live UI scrapes.
Related
Source
Pi-harness considerations doc, §2.4.
Status: research / design note, ahead of building a live view.
Context
Tilth's observability is offline-first:
tilth visualizerenders a finished run'sevents.jsonl(+seed-meta.json) into a staticchat.htmlafter the fact, by re-parsing the event log. The plan is to investigate real-time rendering of events in a UI (a live session view).The concern to bake in (Pi §2.4)
Pi's tools return two payloads — text for the model, structured data for the UI — so the UI never has to re-parse tool text. Tilth already got the high-value half right:
submit_case/submit_verdictare typed schemas, not prose the visualizer has to scrape. But raw tool outputs (bash, file reads) are rendered by re-parsingevents.jsonlafter the fact — exactly the pattern Pi designed against.That's fine for offline rendering. But if a live UI becomes a goal, the split-payload pattern (per-tool-result: model-content vs UI-content) is the move, and retrofitting it is more expensive than designing for it from day one.
Recommendation
When we build the live view, design tool results as split payloads at the source rather than re-parsing the event stream in the UI. Treat the existing
events.jsonlrenderer as the offline consumer of the same structured data, not the source of truth the live UI scrapes.Related
Source
Pi-harness considerations doc, §2.4.