@@ -599,17 +599,18 @@ Available filters: `default`, `join`, `contains`, `map`, `from_json`, `to_json`,
 | `contains`| `{{ text \| contains('sub') }}`           | Substring or membership check                                                                      |
 | `map`    | `{{ list \| map('attr') }}`                | Extract an attribute from each item                                                                |
 | `from_json`| `{{ out \| from_json }}`                 | Parse a JSON string into a typed value                                                             |
-| `to_json`| `{{ obj \| to_json }}`                     | Serialize a value to a JSON string — the inverse of `from_json`                                    |
+| `to_json`| `{{ obj \| to_json }}`                     | Serialize a value to a JSON string — the inverse of `from_json`; mapping keys must be strings |
 | `upper`  | `{{ text \| upper }}`                      | Uppercase a string                                                                                 |
 | `lower`  | `{{ text \| lower }}`                      | Lowercase a string                                                                                 |
 | `split`  | `{{ csv \| split(',') }}`                  | Split a string on a separator into a list of strings                                               |
 | `length` | `{{ items \| length }}`                    | Number of elements in a list, or characters in a string                                            |
 
 Notes on the newer filters:
 
-- **Types are validated, not coerced.** `upper` and `lower` accept strings only, `split` requires both a string value and a non-empty string separator, and `length` accepts lists and strings but rejects mappings. Anything else raises a `ValueError` naming the problem. Coercion is deliberately not performed: a type mismatch nearly always means the workflow is wired to the wrong variable, and a coerced result would hide that. A filter given the wrong number of arguments (`| upper('x')`, `| split` with no separator) is reported as a known filter misused, which is distinct from an entirely unknown filter name. The older filters (`join`, `map`, `contains`) are more permissive and unchanged: `join` stringifies unsupported values and `map`/`contains` return fallbacks rather than raising.
+- **Types are validated, not coerced.** `upper` and `lower` accept strings only, `split` requires both a string value and a non-empty string separator, and `length` accepts lists and strings but rejects mappings. Anything else raises a `ValueError` naming the problem. Coercion is deliberately not performed: a type mismatch nearly always means the workflow is wired to the wrong variable, and a coerced result would hide that. A filter given the wrong number of arguments (`| upper('x')`, `| split` with no separator, `| split(',', 1)`) is reported as a known filter misused, which is distinct from an entirely unknown filter name; arity is checked before the argument expression is evaluated, so the extra argument is what gets named. The older filters (`join`, `map`, `contains`) are more permissive and unchanged: `join` stringifies unsupported values and `map`/`contains` return fallbacks rather than raising.
 - **`to_json` output is deterministic.** Object keys are sorted and non-ASCII characters are left as-is rather than escaped, so the same value always serializes to the same bytes. That buys reproducibility only — it does **not** make the result safe to pass through a shell, because [interpolation adds no quoting or escaping](#interpolation-and-shell-safety). Do not interpolate unconstrained JSON into a `run` field.
 - **`to_json` rejects non-finite floats.** `NaN`, `Infinity`, and `-Infinity` raise a `ValueError` naming `to_json` instead of serializing to bare tokens. None of the three is valid JSON, so emitting them would hand a standards-compliant downstream parser a string it must reject.
+- **`to_json` requires string mapping keys.** JSON objects have string keys, so a mapping with any other key type — `{1: "a"}`, `{True: "a"}` — raises a `ValueError` naming the key type instead. Left to `json.dumps`, an integer key would be coerced to `"1"` and collide with an existing `"1"` key, while mixed key types would fail `sort_keys` with an ordering `TypeError` reported only as "not JSON-serializable".
 - **Trailing comparisons after a filter are rejected.** The parser splits on the top-level `|` before looking for operators, so `{{ items | length > 0 }}` raises rather than evaluating. The count does not exist until `length` runs, so there is no way to write that comparison; the supported branching form is the filter's own truthiness in a `condition:`, since `length` returns `0` for an empty input:
 
   ```yaml
 
@@ -232,13 +232,52 @@ def _filter_to_json(value: Any) -> str:
     is what makes that true for non-finite floats: ``json.dumps`` would
     otherwise emit bare ``NaN``/``Infinity``/``-Infinity``, none of which is
     valid JSON, and hand downstream parsers a string they must reject.
+
+    Mapping keys must be strings, which is what JSON objects have anyway.
+    ``_check_json_keys`` enforces that before ``json.dumps`` is reached, so a
+    non-string key is reported as the authoring mistake it is rather than
+    surfacing as an ordering ``TypeError`` from ``sort_keys=True`` (mixed key
+    types) or as silent ``1`` → ``"1"`` coercion that collides with an existing
+    ``"1"`` key.
     """
+    _check_json_keys(value)
     try:
         return json.dumps(value, sort_keys=True, ensure_ascii=False, allow_nan=False)
     except (TypeError, ValueError) as exc:
         raise ValueError(f"to_json: value is not JSON-serializable: {exc}") from exc
 
 
+def _check_json_keys(value: Any) -> None:
+    """Raise ``ValueError`` if any mapping reachable from *value* has a
+    non-string key.
+
+    Walked iteratively with a ``seen`` set: a self-referential structure is
+    skipped rather than recursed into, so the circular reference stays for
+    ``json.dumps`` to report with its own clearer message instead of the walk
+    exhausting the stack first.
+    """
+    seen: set[int] = set()
+    stack: list[Any] = [value]
+    while stack:
+        item = stack.pop()
+        if isinstance(item, dict):
+            if id(item) in seen:
+                continue
+            seen.add(id(item))
+            for key, sub_value in item.items():
+                if not isinstance(key, str):
+                    raise ValueError(
+                        "to_json: mapping keys must be strings, got "
+                        f"{type(key).__name__}: {key!r}"
+                    )
+                stack.append(sub_value)
+        elif isinstance(item, (list, tuple)):
+            if id(item) in seen:
+                continue
+            seen.add(id(item))
+            stack.extend(item)
+
+
 # Filters that take no arguments and tolerate no trailing tokens. Keyed by name
 # so ``_apply_filter`` can recognize a mis-wired form of any of them from the
 # leading filter name alone, instead of each needing its own branch. ``default``
@@ -252,6 +291,14 @@ def _filter_to_json(value: Any) -> str:
     "to_json": _filter_to_json,
 }
 
+# Parenthesized filters that take exactly one argument. Used to report an
+# extra argument by name *before* the argument expression is evaluated:
+# _evaluate_simple_expression has no comma operator, so ``| split(',', 1)``
+# would otherwise hand split an unparseable fragment, which reads back as
+# "expected a string separator, got NoneType" -- the arity mistake, which is
+# what the author actually got wrong, never surfaces.
+_SINGLE_ARG_FILTERS = frozenset({"default", "join", "map", "contains", "split"})
+
 
 # -- Expression resolution ------------------------------------------------
 
@@ -612,7 +659,15 @@ def _apply_filter(value: Any, filter_expr: str, namespace: dict[str, Any]) -> An
     filter_match = re.fullmatch(r"(\w+)\((.+)\)", filter_expr)
     if filter_match:
         fname = filter_match.group(1)
-        farg = _evaluate_simple_expression(filter_match.group(2).strip(), namespace)
+        farg_text = filter_match.group(2).strip()
+        if fname in _SINGLE_ARG_FILTERS:
+            arg_parts = _split_top_level_commas(farg_text)
+            if len(arg_parts) > 1:
+                raise ValueError(
+                    f"{fname}: expected exactly one argument, got "
+                    f"{len(arg_parts)}: '| {filter_expr}'"
+                )
+        farg = _evaluate_simple_expression(farg_text, namespace)
         if fname == "default":
             return _filter_default(value, farg)
         if fname == "join":
 
@@ -824,6 +824,59 @@ def test_filter_to_json_rejects_non_finite_floats(self):
             ):
                 evaluate_expression(f"{{{{ inputs.{name} | to_json }}}}", ctx)
 
+    def test_filter_to_json_rejects_non_string_keys(self):
+        # JSON objects have string keys only. Without this check, json.dumps
+        # would coerce 1 to "1" -- colliding with an existing "1" key -- and
+        # sort_keys=True would raise an ordering TypeError on mixed key types,
+        # which surfaced as a generic "not JSON-serializable" hiding the real
+        # authoring mistake.
+        import pytest
+        from specify_cli.workflows.expressions import evaluate_expression
+        from specify_cli.workflows.base import StepContext
+
+        ctx = StepContext(
+            inputs={
+                "mixed": {1: "a", "2": "b"},
+                "intkey": {1: "a"},
+                "nested": {"outer": {3: "deep"}},
+                "strkey": {"1": "a", "2": "b"},
+            }
+        )
+        for name in ("mixed", "intkey", "nested"):
+            with pytest.raises(
+                ValueError, match="to_json: mapping keys must be strings"
+            ):
+                evaluate_expression(f"{{{{ inputs.{name} | to_json }}}}", ctx)
+        # String keys, digit strings included, still serialize normally.
+        assert (
+            evaluate_expression("{{ inputs.strkey | to_json }}", ctx)
+            == '{"1": "a", "2": "b"}'
+        )
+
+    def test_single_arg_filters_reject_extra_argument(self):
+        # Arity is checked before the argument expression is evaluated.
+        # split(',', 1) used to evaluate that fragment first, so the reported
+        # error was "expected a string separator, got NoneType" -- the arity
+        # mistake, which is what the author got wrong, stayed hidden behind a
+        # type error.
+        import pytest
+        from specify_cli.workflows.expressions import evaluate_expression
+        from specify_cli.workflows.base import StepContext
+
+        ctx = StepContext(inputs={"s": "a,b,c", "n": 0})
+        with pytest.raises(
+            ValueError, match="split: expected exactly one argument, got 2"
+        ):
+            evaluate_expression("{{ inputs.s | split(',', 1) }}", ctx)
+        with pytest.raises(
+            ValueError, match="default: expected exactly one argument, got 2"
+        ):
+            evaluate_expression("{{ inputs.n | default(0, 'x') }}", ctx)
+        # A comma inside quotes or brackets is still one argument.
+        assert (
+            evaluate_expression("{{ inputs.s | split(',') }}", ctx) == ["a", "b", "c"]
+        )
+
     def test_zero_arg_filters_reject_miswired_forms(self):
         # The strict no-argument branch is shared by from_json/upper/lower/
         # length/to_json. Every mis-wired form — parenthesized, accidental arg,
 
@@ -123,15 +123,15 @@ Workflow definitions use Jinja2-like `{{ expression }}` syntax for dynamic value
 | Filter: `contains` | `{{ text \| contains('sub') }}` | Substring/membership check |
 | Filter: `map` | `{{ list \| map('attr') }}` | Extract attribute from each item |
 | Filter: `from_json` | `{{ steps.emit.output.stdout \| from_json }}` | Parse a JSON string into a typed value (raises on invalid JSON) |
-| Filter: `to_json` | `{{ obj \| to_json }}` | Serialize any value to a JSON string (inverse of `from_json`) |
+| Filter: `to_json` | `{{ obj \| to_json }}` | Serialize a value to a JSON string (inverse of `from_json`; mapping keys must be strings) |
 | Filter: `upper` | `{{ text \| upper }}` | Uppercase a string (strings only) |
 | Filter: `lower` | `{{ text \| lower }}` | Lowercase a string (strings only) |
 | Filter: `split` | `{{ csv \| split(',') }}` | Split a string on a separator into a list |
 | Filter: `length` | `{{ items \| length }}` | Length of a list or string (mappings rejected) |
 
 **Single expressions** (`{{ expr }}` only) return typed values. **Mixed templates** (`"text {{ expr }} more"`) return interpolated strings.
 
-**Filter argument strictness (new filters).** The five filters added in #4766 validate their supported inputs and raise `ValueError` naming the problem rather than leaking a Python `TypeError`/`AttributeError`: `upper`/`lower` accept only strings, `split` requires a string value and a non-empty string separator, `length` accepts only lists and strings, and `to_json` requires a JSON-serializable value and additionally rejects non-finite floats (`NaN`, `Infinity`, `-Infinity`), which `json.dumps` would otherwise emit as bare tokens that are not valid JSON. Coercion is deliberately rejected for these filters: a type mismatch almost always means the pipeline is wired to the wrong variable, and a coerced result (e.g. `"3"` for an int) would hide that. A filter used with the wrong arity — `| upper('x')`, `| split` with no separator, `| join` bare — is reported as a known filter misused, distinct from an entirely unknown name.
+**Filter argument strictness (new filters).** The five filters added in #4766 validate their supported inputs and raise `ValueError` naming the problem rather than leaking a Python `TypeError`/`AttributeError`: `upper`/`lower` accept only strings, `split` requires a string value and a non-empty string separator, `length` accepts only lists and strings, and `to_json` requires a JSON-serializable value whose mapping keys are strings, and additionally rejects non-finite floats (`NaN`, `Infinity`, `-Infinity`), which `json.dumps` would otherwise emit as bare tokens that are not valid JSON. Keys are checked before serialization because `json.dumps` would otherwise coerce `1` to `"1"` (colliding with an existing `"1"` key), while `sort_keys=True` raises an ordering `TypeError` on mixed key types — both surfacing as a generic "not JSON-serializable" that hides the authoring mistake. Coercion is deliberately rejected for these filters: a type mismatch almost always means the pipeline is wired to the wrong variable, and a coerced result (e.g. `"3"` for an int) would hide that. Arity is checked before the argument expression is evaluated, so a filter used with the wrong number of arguments — `| upper('x')`, `| split` with no separator, `| split(',', 1)`, `| join` bare — is reported as a known filter misused, distinct from an entirely unknown name.
 
 The older filters are more permissive and are unchanged: `join` stringifies unsupported value shapes and elements, and `map`/`contains` return fallback values for unsupported inputs rather than raising.
 
 
@@ -414,12 +414,14 @@ Supported filters: `default`, `join`, `contains`, `map`, `from_json`, `to_json`,
 The new filters validate their input types and raise a `ValueError` naming
 the problem instead of coercing — so `upper`/`lower` take strings only, `split`
 takes a string value and a non-empty string separator, `length` accepts
-lists and strings but rejects mappings, and `to_json` rejects values it
-cannot serialize — including non-finite floats (`NaN`, `Infinity`,
-`-Infinity`), which would otherwise serialize to tokens that are not valid
-JSON. A filter used with the wrong number of
+lists and strings but rejects mappings, and `to_json` rejects what it cannot
+serialize: non-finite floats (`NaN`, `Infinity`, `-Infinity`), which would
+otherwise serialize to tokens that are not valid JSON, and mapping keys that
+are not strings, which JSON objects cannot carry. A filter used with the wrong
+number of
 arguments
-(`| upper('x')`, bare `| split`) is reported as a known filter misused, which is
+(`| upper('x')`, `| split(',', 1)`, bare `| split`) is reported as a known
+filter misused, which is
 distinct from an entirely unknown filter name. The older filters are more
 permissive and unchanged: `join` stringifies unsupported values, and
 `map`/`contains` return fallbacks rather than raising. See