Skip to main content

Reading Input Data

This page explains what happens to the data a connected system sends in, before any rule ever runs on it.

The JSON ingestion contract​

Ratified at plan 02-01's Task 0 checkpoint (option-a): a plain-JSON job payload becomes engine values typed by JSON type, never by content. No rule anywhere inspects a string's characters to decide whether it looks numeric — that is the boundary rule made concrete, and it is why a locale-ambiguous string such as "1.234,56" can never be guessed at. This is the section a systems integrator should read before sending a payload, because it states plainly what the engine will and will not do with their data.

  • A JSON string becomes a string value. Always. There is no option under which it becomes a number — an author who wants a number from a string writes the explicit conversion, PARSENUMBER, naming a locale/format on the Number page.
  • A JSON number becomes an exact decimal built from the host's own shortest round-tripping decimal rendering of that value — ECMA-262 specifies that rendering exactly, so every supported runtime agrees digit for digit. No host arithmetic runs on the number at any point; it is rendered to text and the text is parsed into the exact decimal type.
  • A number that is not finite, or that is a whole number whose magnitude exceeds the largest exactly-representable integer, is refused with a coded ingestion diagnostic rather than silently coerced.
  • true/false become booleans. An explicit JSON null becomes the null value (present, but null); a missing key is not ingested at all — the path resolver reports it as absent, per the value model.
  • A JSON array becomes an array value, elements ingested in the same order. A JSON object becomes an object value built from its own enumerable properties only, never an inherited one.
  • undefined, a function, a symbol, a big integer, a host date object, a cyclic reference, and any other value that is not plain JSON are each refused with the same coded ingestion diagnostic. None of them is JSON, and coercing any of them would be the engine silently choosing a representation nobody asked for.

Documented remedy for lost precision. A caller who sends more significant digits as a JSON number than a host double can hold has already lost them in their own parse, before this engine ever sees the value — no check here can detect that after the fact. The remedy is the engine's own idiom: send the value as a string and convert it explicitly with PARSENUMBER, which reads the source text digit for digit rather than round-tripping through a host double.