The direct answer
Treat parsed AI metadata as data with an independently reviewed own-field inventory. Require the two selected fields to be own, bounded strings, reject every extra key, and reconstruct only those fixed fields into a trusted null-prototype data record. Keep inherited values and arbitrary input keys out of configuration decisions. Actual intake, runtime, builder and consumer evidence remains necessary.
A successful parse is only the start of this handoff
A fictional AI preview service accepts two text fields, note_text and style_label. Its JavaScript adapter must prepare preview metadata without allowing that data to choose application configuration. The useful question comes after syntax intake: what counts as a supplied field, and which later operation receives its name and value?
This proposed profile selects one already bounded, ordinary JSON data record. It excludes nested structures, arrays, dynamic configuration keys and action flags. The raw parser contract remains a separate prerequisite. No JSON payload, object, merge or JavaScript runtime was constructed here; the references below are paper labels.
Separate parsed data from the later prototype-changing sink
MDN’s prototype-pollution guide, modified 17 October 2025, distinguishes JSON parsing of a __proto__ key from later assignment or merging that can trigger a setter. Its example changes the target object’s prototype, not necessarily the global Object.prototype. The guide discusses rejecting unneeded properties, checking own properties and using null-prototype objects.
For this worksheet, successful intake does not admit a later generic defaults merge. Record each handoff separately. An adapter that passes its initial shape review can still leave the selected profile when another component copies arbitrary keys into an application settings destination. The review must identify that destination and its purpose.
Do not turn a list of suspicious names into permission to merge everything else. Our policy owns exactly two names and two text contracts. It rejects an unfamiliar key before reconstruction, even when that key looks harmless. This is a narrow application choice, not a general-purpose pollution detector or sanitizer.
Membership, value validity and authority are separate decisions
MDN’s Object.hasOwn reference, modified 26 October 2026, defines an own-property check that excludes inherited properties. An own null or undefined value still counts as present. The static method also works with null-prototype objects and objects that shadow hasOwnProperty; the in operator includes inherited properties.
The selected parsed-JSON record can contain null, but undefined is not a literal JSON value. Our countercard therefore uses an own null field: membership succeeds while the required text contract fails. An inherited style label also fails because it was not supplied as an admitted own field. Neither case permits substituting a convenient default and calling it model output.
The adapter must not ask an input-owned method to certify its own record. Nor does a trusted membership result authenticate the text, establish the allowed-key inventory or grant the user permission to use it. Those are separate cells in the review sheet.
Use a fixed data destination and keep its consumers in scope
Invent intake revision D-A, builder B-A and destination N-A. These labels describe the proposed association, not implemented objects. B-A owns the two destination names. Only after the complete own-key and bounded-string review would it reconstruct those two admitted values into a fresh null-prototype data record. It does not accept a name list or defaults object from the model.
| Evidence cell | Question before admission |
|---|---|
| Input and lifetime | Is this the exact stable, admitted ordinary data record? |
| Complete own-field inventory | Are both required names present and all other names excluded? |
| Value contracts | Are both values permitted bounded strings, rather than merely present? |
| Trusted builder and destination | Does the fixed builder produce only the selected data representation? |
| All later consumers | Does every handoff preserve data use without arbitrary configuration merging? |
| Current use rights | May this user use this revision for the selected preview? |
Null-prototype reconstruction supplies neither an immutability promise nor permission for a new sink. The sheet does not admit recursive copies, arbitrary classes, accessors or proxies. A later rendering stage still needs its existing text and HTML policy; a preview record cannot choose a command, network destination or privileged setting.
Eight paper cards before an actual adapter exists
All eight cards are PROPOSED_UNRUN. They express required dispositions for a separately implemented adapter, not observations from JavaScript execution.
| Card | Proposed condition and disposition |
|---|---|
| 1 — positive | Both own fields are valid strings and every sheet cell has independent evidence. Admit only the reconstructed preview metadata for separate sink checks. |
| 2 — inherited field | A required name is available only through inheritance. Reject the supplied-field claim instead of borrowing that value. |
| 3 — own null | The field is own but null. Record presence separately and reject the required text value. |
| 4 — unknown key | An additional name, including a prototype-sensitive name, appears. Reject the closed shape before any generic merge. |
| 5 — later merge | A reviewed record is subsequently proposed for arbitrary assignment into defaults. Hold that consumer; the earlier review does not cover it. |
| 6 — method assumption | A reader depends on an input-owned hasOwnProperty method. Reject that reader; supported trusted static membership remains an implementation prerequisite. |
| 7 — changed profile | A proxy, accessor-bearing instance or untrusted realm replaces ordinary data. Stop this profile without claiming that property inspection has no effects. |
| 8 — denied use | Fields pass but preview rights or a downstream sink fail. Deny that use independently of the data representation. |
Keep the conditional result honest
The ordinary positive requires evidence for the complete intake contract, plain own-data representation, stable lifetime, trusted realm and intrinsics, fixed builder, all downstream readers and writers, and current rights. These remain unimplemented or unknown here. A matching-looking record cannot fill those gaps.
Boundary is prelaunch. This guide proposes a review aid, not a tested redactor, whole-process defense or compatibility certificate. Preserve the existing raw-JSON, business-validation and rendering profiles. Review the evidence boundary before treating any proposed card as an observed result.
Primary sources
Official references supporting the guidance. Examples in this guide are synthetic and are not reports of a production incident.