Simulation Maintenance: Record a Nonfinite JSON Export

A simulation summary is exported and accepted by one viewer, but another consumer rejects the same material as invalid JSON. The maintenance question is not yet whether the simulated robot performed correctly. It is whether the exchange represents its values in a form the recipient expects. This fictional investigation examines nonfinite-value handling without running a simulation, supplying invented metrics or changing a learning exercise.

Start with the disagreement between consumers

The initial report should identify the retained export and the actual response of each consumer. If the recipients used different copies, that relationship needs clarification before comparing their behaviour. A label such as JSON supported describes too little: it does not identify which values were emitted or what the receiving implementation accepted.

Imagine that an exercise coordinator has a rejected summary and a screenshot from a successful-looking viewer. Preserve both observations, including the input each one concerns. A viewer displaying part of the summary does not establish that every exported value has a portable representation. Equally, a rejection does not explain how an unusual value arose in the underlying simulation.

The number grammar provides a narrow factual boundary

RFC 8259 excludes numeric forms such as NaN and Infinity from its JSON number grammar. This is an exchange-format fact. It does not decide whether a particular simulation calculation was meaningful or diagnose why a producer generated a nonfinite value. Those are separate questions requiring the actual model and calculation context.

For the fictional record, retain the original spelling of any questioned value within the permitted evidence scope. Do not replace it with zero, an empty string or a plausible score just to make a consumer proceed. Each substitution would add meaning that has not been justified. A maintenance note should make the unresolved interpretation visible rather than hiding it in a tidy exported table.

Acceptance by a library can reflect an extension

The Python JSON documentation describes its allow_nan serialization behaviour and notes that emitting the corresponding nonfinite spellings is not compliant with the JSON specification. This supplies a concrete example of why a producer's successful serialization is not enough to establish portability. It is not proof that the exercise exporter uses Python or that its configuration is known.

Ask the responsible developer which serializer and policy were actually used, and retain that explanation with the export revision. If the implementation is unknown, record it as pending. Do not assign a library's documented default to an unrelated application merely because the observed symptom resembles a familiar example.

The recipient's policy also matters to the account of the disagreement. A consumer might reject an unsupported token, while another implementation permits an extension. Record the actual observations without assuming that one consumer silently corrected the data. The handover should let a later investigator distinguish representation acceptance from the meaning of the simulation summary.

Decide the intended missing-result meaning before changing output

If the responsible team proposes another representation, its meaning needs an explicit agreement. An unavailable result, a calculation outside its intended domain and an omitted measurement can require different explanations. This article does not assign any of those meanings to a real field. The maintenance team should obtain the exercise's own definition rather than infer it from an error token.

A revised export should identify the change and retain the original issue. If a field becomes optional or gains a separate status explanation, that is a schema or interface decision, not just a cosmetic edit. The receiving side needs to know how the revised material should be interpreted. Replacing a token without documenting that relationship can make a file easier to parse while making the result less understandable.

Any numerical investigation belongs to its own authorized analysis. An exchange-format correction cannot certify the physics model, validate every experiment or turn an undefined result into a successful trial. Keep those decisions out of the export-maintenance conclusion unless the responsible team supplies separate evidence for them.

Recheck the agreed exchange and preserve open questions

An authorized follow-up can identify the revised input, the intended representation policy and the actual receiving result. Keep the first rejection alongside the recheck. If only a document was clarified, say so; if a new export was examined, identify it. No recheck has been performed here, and no performance number is supplied.

The original illustrations show exchange relationships rather than experimental output. Related material appears in the reproducible simulation learning section and the article directory. A maintenance record that separates number grammar, serializer choices and simulation meaning gives learners a useful explanation without inventing a successful numerical result.