What
renderOptions() in server/instruments/judge.js presents the label set to the worker as keys only for multi-category constructs:
multilabel → "Label is an array of zero or more of: a | b | c"kclass (nominal) → "Allowed labels: a | b | c"
Only likert renders each option's anchor (its meaning). The construct's per-category anchor text is never sent to the worker for nominal/multilabel — and {{definition}} is only the construct-level definition, {{criteria}} only the include/exclude.
Impact
A multi-category construct is coded by label name alone unless you duplicate each category's meaning into definition/criteria. In practice an 8-theme multilabel over-fired badly (one category acting as a catch-all) until the definitions were folded into criteria.include — i.e. the codebook's substance was invisible to the worker.
Fix
Render category anchors for kclass/multilabel the way likert already does (e.g. option: anchor lines), so the worker sees what each label means.
What
renderOptions()inserver/instruments/judge.jspresents the label set to the worker as keys only for multi-category constructs:multilabel→"Label is an array of zero or more of: a | b | c"kclass(nominal) →"Allowed labels: a | b | c"Only
likertrenders each option's anchor (its meaning). The construct's per-categoryanchortext is never sent to the worker for nominal/multilabel — and{{definition}}is only the construct-level definition,{{criteria}}only the include/exclude.Impact
A multi-category construct is coded by label name alone unless you duplicate each category's meaning into
definition/criteria. In practice an 8-theme multilabel over-fired badly (one category acting as a catch-all) until the definitions were folded intocriteria.include— i.e. the codebook's substance was invisible to the worker.Fix
Render category anchors for
kclass/multilabelthe waylikertalready does (e.g.option: anchorlines), so the worker sees what each label means.