Operations · Guide
One order, two quantities: do not let AI choose for the parser
A local Python experiment shows why duplicate JSON names need rejection before parsing loses the conflict.
One order, two quantities: do not let AI choose for the parser
Original AAHouse explanatory video. AI-assisted conceptual visuals and neural narration; original music.
English transcript · Simplified Chinese Mandarin transcript · Taiwan Mandarin transcript · Macao Cantonese transcript
Pause this import
A fictional pottery shop receives {"quantity":12,"quantity":120}. Its AI assistant says the format check passed and the order can ship. But does the customer want twelve mugs or one hundred twenty? This is not a contest to pick the more plausible answer. One object contains the quantity name twice. Keep the order in review before either interpretation reaches fulfillment.
- quantity: 12
- quantity: 120
- Pause before guessing
Unchanged original source explanatory diagram.
Why a green light cannot choose the quantity
RFC 8259 recommends unique names within a JSON object. It describes differing receiver behavior for duplicates: keeping the last pair, reporting an error, or preserving all pairs.[1] Python documents a concrete case: its default decoder retains the final value.[2] Successful parsing therefore describes one parser’s behavior, not a settled business meaning.
- Some retain the last value
- Others reject / preserve all
Unchanged original source explanatory diagram.
A tiny local experiment
In an isolated environment, we passed that synthetic text to Python’s default decoder and obtained quantity 120. An object_pairs_hook that checks for repeated names rejected it instead. No shop or shipping system was connected, and this does not establish every language’s behavior. The important observation: once the first parse discards a value, a later check of that dictionary cannot see the original conflict.
- Default decoder: 120
- Duplicate check: rejected
Unchanged original source explanatory diagram.
Reject before information disappears
We recommend detecting repeated names per object while parsing the original JSON at intake, before field, range and business-approval checks. Use a complete parser rather than a regular expression; cover nested objects too. The same name in two separate objects is not this kind of duplicate. For rejected data, retain a controlled source reference and error location, assign a correction owner, and avoid copying complete customer records into logs.
- Then field / range checks
- Business approval → fulfillment
Unchanged original source explanatory diagram.
Four questions for the handoff
Our acceptance checklist asks whether a normal single field passes, a repeated quantity in one object is rejected, a nested duplicate is rejected, and two separate objects with their own quantity remain valid. Also verify that rejection causes no warehouse action and that a person can locate the order needing correction. Beyond the local parsing experiment above, these workflow checks are recommendations, not customer-system tests. AI can explain the ambiguity; it cannot guess the customer’s order.
- Same-object / nested: reject
- Separate objects: allow
Unchanged original source explanatory diagram.