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.

The retired third answer

normalize/2 used to have a third answer, :skip, for an engine trace effect the wire format deliberately did not carry - closed, named, and distinct from an unknown effect. It had exactly one member, Statifier.Effect.Trace.CondsEvaluated, skipped by sui-9fs because v1 had no guard-evaluation message to map it onto. ADR-0018 added that message, sui-e41 moved the effect onto the mapping clause below, and the answer retired with its last member: nothing in this module returns :skip, and normalize/2 no longer offers it.

It was retired rather than kept empty because the empty form is not writable here. A guard over an empty list warns that its clause cannot match, an unused constant warns on its own, and a contract offering a return no clause produces makes every caller's third arm dead code the analyzer refuses. The next trace effect ruled out of the vocabulary reintroduces the answer with the clause that produces it, which is the only form that stays honest.

The fallthrough that answers {:error, {:unknown_effect, _}} is untouched, and deliberately so - a trace effect nobody has considered still refuses. That refusal is the mechanism the skip was always distinct from, and it is the half that has members.