The pure mapping from Statifier.Effect.t() (and the session's own lifecycle messages) to StatifierUI.Trace.Message.t(), matching docs/wire-format.md field for field. No process, no session, no %Statifier.Machine{} - the whole vocabulary is testable from a struct literal.

Value handling

Anything from the engine that occupies a value position - Event.data, Log.value, Trace.Done.donedata, Effect.Done.donedata, Send.data, SendDelayed.data, Invoke.params, Invoke.content, DatamodelChange.new_value, DatamodelChange.prior_value - goes through StatifierUI.Value.encode/1; its {:error, _} is propagated, never rescued. Everything structural is reduced first (decision 6): MapSets to sorted lists (configuration/1), atoms to "kind"-tagged objects (origin/1, owner/1). This ordering matters - StatifierUI.Value.encode/1 rejects any term outside predicator's closed value domain with {:error, {:unsupported_value, term}}, so handing it a raw tuple or a bare atom would produce a wrong error (:unsupported_value instead of a normalizer-specific one) rather than the structural, purpose-built handling this module gives those shapes. A %Statifier.Evaluator.Error{} in Event.data gets the same structural treatment, one step further: it never reaches StatifierUI.Value.encode/1 at all, because it is not a predicator value - it is reduced by StatifierUI.Trace.Diagnostic.object/4 into the wire error object and lands on the event's "error" key instead of "data". The two keys are alternatives, never siblings. An error.execution or error.communication event's data gets the same treatment for the same reason (ADR-0014): the engine's raise site puts an unconstrained reason term there, StatifierUI.Value.encode/1 rejects the tagged tuples it is in practice, and the whole message used to be dropped rather than rendered. It is reduced by StatifierUI.Trace.Diagnostic.reason_object/4 onto the same "error" key instead.

Absence

_event.data keeps ADR-0005's three-way rule unchanged: :undefined omits the key, nil is present as JSON null, %{} is present as {} (put_defined/3). DatamodelChange.new_value and DatamodelChange.prior_value follow the same three-way rule, because they share _event.data's property: the engine spells "unbound" as :undefined there (ADR-0037), so nil genuinely means a stored null. Every other nullable field in this vocabulary has no engine-side way to distinguish "no value" from "a genuinely null value" - Statifier.Effect.Log.value and the two donedata fields default to plain nil for "nothing here", never :undefined - so put_present/3 and put_value/3 generalize the rule (decision 5) by treating nil and :undefined alike as absence for those fields, applied uniformly instead of remembered clause by clause.

Skipped trace effects

normalize/2 has a third answer, :skip, for an engine trace effect the v1 wire format deliberately does not carry. It is not a failure and it is not an unknown effect: the set is closed, named in @skipped_trace_effects, and every member has been looked at and ruled out of v1 on purpose. Today the set is Statifier.Effect.Trace.CondsEvaluated alone - statifier 2.5.0's guard seam, emitted once per selection round that evaluated a written cond. The vocabulary has no guard-evaluation message to map it onto, and inventing one is a wire-format change with an ADR in front of it (sui-e41 will add trace.conds_evaluated), so until then the producer passes over the effect rather than refusing the stream it appears in. Refusing it is what this skip replaces: a chart with a single guarded transition used to fail the whole offline replay on its first branch.

The fallthrough that answers {:error, {:unknown_effect, _}} is untouched, and deliberately so - a trace effect nobody has considered still refuses.