JSON repair must never invent authorization-bearing values

I let JSON repair recover syntax, never invent authorization-bearing values. A parser may restore a missing delimiter; it must not decide who may act, which resource an action targets, or whether approval exists. Those decisions change what the application is allowed to do. When recovery supplies them merely to satisfy a schema, the system has converted missing evidence into apparent permission.

The dangerous boundary is not between invalid JSON and valid JSON. It is between preserving a supplied value and manufacturing a usable replacement. Schema-guided repair can fill missing required fields, coerce scalars, remove unexpected properties, and substitute an allowed enum value for an invalid one. Each transformation can make validation succeed without establishing that the resulting value represents the request. I treat schema compliance as a statement about shape, not a certificate of intent.

Consider a hypothetical action request with a required approval flag. A repair rule that fills absent booleans with false appears conservative. Rename the field to requires_approval and the same default could remove a required stop. An enum fallback has the same problem: choosing the first permitted value is a formatting heuristic, not a policy decision. I would not let the order of entries in a schema determine whether a malformed request becomes executable. Safety depends on the meaning of the field, not the apparent modesty of its default.

I therefore want the recovery contract to identify fields whose meaning affects authority. An absent approval, ambiguous resource identifier, or invalid operation must remain a failed request until the application can establish the missing fact through its trusted checks. A schema default can encode an application decision, but that decision belongs in explicit policy, not hidden inside a general repair pass. Rejecting an incomplete action is different from rewriting its contents until the ordinary execution path accepts it.

Aggressive salvage makes this distinction harder to see. Dropping invalid array items changes which items survive. Mapping positional values into object properties assigns meaning from declaration order. These operations may yield a coherent object while losing the evidence needed to explain its contents. For an action-bearing payload, I would require preservation of the relevant values and their interpretation, rather than accept whichever transformation produces a valid instance. A successful parse cannot answer whether the recovered target was the intended target.

Streaming exposes the same problem without any malformed final response. A repairer can close an unfinished string or container and produce a valid object from a partial stream. That object represents the current fragment, not necessarily the completed value. I would keep such output away from execution: a displayable prefix is not a finished instruction. Closing the JSON structure does not prove that the model has finished naming the resource or stating the conditions of an action.

My recovery sequence starts with constrained generation, then validation with bounded correction attempts, then narrowly permitted repair. I would preserve the original output and record which fields repair changed, so a synthetic value cannot disappear into an eventual-success count. Missing values filled by a heuristic remain extraction failures in evaluation. Strict handling of ambiguous structures can make failures visible, but I would not mistake a parser setting for an authorization check. The application still has to decide whether the proposed action is permitted.

I concede one narrow case: automatic syntax repair is reasonable for a non-executable display object when the repair preserves its values and the application explicitly accepts incomplete presentation. That allowance ends when repaired content can select or authorize an effect.

My acceptance test is therefore not whether recovery returned an object. It is whether recovery preserved the distinction between supplied data, inferred structure, and missing authority. If the pipeline cannot establish that distinction, I want an explicit failure. Repair should make damaged syntax readable, not make an unsupported action permissible.