Event log design
A well-shaped event log is the difference between an LLM pipeline you can debug at 3 AM and one that silently rots. Meridian treats every recipe run as an append-only stream of facts — prompts, tool calls, model outputs, verdicts — so you can replay, audit, and cost-attribute any decision after the fact.
1.Pick a schema that survives schema drift
Treat the log row as an envelope, not a record. Hard-code onlyrun_id,step_id,ts,kind, and a free-formpayloadJSON blob. New event types ship without a migration.
2.Make every event causally addressable
Each event carries the parent_idof the event that triggered it. Replaying a run is a depth-first walk from the root prompt — no guessing which tool call belonged to which model turn.
3.Log cost and latency at the edge, not in aggregation
Stamp prompt tokens, completion tokens, dollar cost, and wall-clock latency on every model event when it lands. Roll-ups in the dashboard then become a cheap SQL SUM— not a reprocessing job that drifts out of sync.
{
"run_id": "run_01HXY...",
"step_id": "evt_01HXZ...",
"parent_id":"evt_01HXY...",
"ts": "2026-06-27T14:02:11.482Z",
"kind": "model.completion",
"payload": {
"model": "azure/model-router",
"prompt_tokens": 812,
"output_tokens": 144,
"cost_usd": 0.0031,
"latency_ms": 1840,
"verdict": "SHIP"
}
}