Preserve Missing, Null, False and Zero in AI Data Handoffs

A data handoff can lose meaning without losing a single row. An assistant may turn an unanswered field into no, replace a missing count with zero, or present an empty string as if it were an explicit refusal. The file can remain valid JSON and the summary can remain fluent while those changes alter the business question. The first review is therefore about what was supplied, what was absent and what each state is allowed to mean.

This guide uses six original fictional records for a teaching field called response. The records contain an omitted property, null, false, zero, an empty string and the string zero. They are not client data, model outputs or examples of a particular vendor's application behavior. The downloadable JSON and CSV preserve those deliberately different inputs. No executable utility, destination update or model test is supplied. The purpose is to define a reviewable handoff before adapting the idea to an authorized workflow with its own field contract.

Separate field presence from field value

Fictional case A is an object with an identifier A and no response property. Case B has an identifier B and a response property whose value is null. The distinction can be stated without assigning any business meaning: A does not contain that property, while B does contain it. If an assistant reports both as a customer declining a request, it has added an interpretation that neither record supplies. If it reports both as zero responses, it has changed both a structural fact and a counting definition.

JSON Schema's null reference distinguishes an explicit null value from an absent property. Its object reference describes properties and required-property validation. These technical distinctions do not define what a null means inside a specific business application. For the authored cases here, the contract says only that null is explicitly supplied without a substantive response value, while omission leaves the field unsupplied. Unknown, not applicable, withheld and cleared are possible application meanings, but none should be selected unless the relevant contract actually assigns it.

Ask two questions in order. Is the property present? If it is, what value and type does it carry? A presence check should not be implemented mentally as whether the value looks useful. Zero, false and an empty string can all be explicitly present. Keeping the two questions separate makes it easier to see why a column titled missing needs a definition. It might mean absent from the object, present without a substantive answer, or excluded under an analysis rule. Those are different categories.

Case C: keep an explicit false separate from no evidence

Case C supplies response as the boolean false. The teaching contract labels that state as an explicit boolean value with no further business interpretation. It does not say that the record concerns marketing consent, a purchase decision, an account setting or a completed task. An assistant can accurately say that false was supplied. It cannot infer that a person refused contact or that a process failed without additional evidence about the field's purpose and the event represented by the record.

A common reporting shortcut is to group all values that an application treats as false-like. That can be useful inside a deliberately defined programming expression, but it is not a safe substitute for the field contract. A boolean false, the number zero and an empty string can have separate roles in an input schema. They might each need a different validation message. Before using a shortcut, explain which question it is intended to answer and which distinctions it intentionally discards.

An original AI brief for this case could say: State the JSON type and supplied value for each record. Do not infer a customer action, permission or outcome from the field name. Preserve false as a boolean and distinguish it from omission. This is proposed teaching wording, not an observed model response or a tested safeguard. If an actual application maps false to a named business status, include that mapping as a separate supplied rule and identify its scope rather than relying on familiar language.

Case D: zero is a supplied number

Case D supplies response as the number zero. The record contains a numerical value. It is neither omitted nor null. Under the teaching contract, zero is not automatically converted into missingness, refusal or an empty answer. The name response is intentionally generic so that a reader has to ask about units and meaning. A real count of zero qualifying events differs from an unknown event count, even when both might display as a blank cell in a poorly specified report.

Consider an original fictional extension in which response represents a count of completed checks. If the contract and data collection support a count of zero, a report can include zero in the appropriate arithmetic. If the count is absent, including it as zero would invent evidence. This guide does not claim that case D actually represents completed checks; the extension demonstrates why the unit statement must accompany an interpretation. Preserve the original record before deriving a field for an analysis.

The arithmetic consequence can be large even in a tiny example. Suppose an independently authored known count is four and a second supplied count is zero. Their mean over two known observations is two. If the second count is unknown instead, the mean for the known subset is four and the overall two-record mean is unresolved. Replacing an unknown with zero produces a calculable number while changing the evidence. Neither a valid JSON parser nor a well-formatted paragraph can justify that substitution.

Case E: an empty string still has a type

Case E supplies response as an empty string. The property is present and its value is a string with zero characters. The teaching contract preserves that fact without deciding whether the application intended a blank answer, a cleared field, a placeholder or a collection error. Those possibilities require context. Reporting the empty string as an omitted property would be structurally inaccurate, while calling it an explicit negative response would add a business interpretation not supplied by the case.

Whitespace raises a related question. A string containing a space is not the same sequence of characters as an empty string. An application may deliberately trim whitespace before validation, but that is a transformation that should be named. Do not silently trim, normalize or substitute values during an evidence-preservation exercise. If a workflow needs a cleaned field, keep the original value and describe the cleaning rule separately so that a reviewer can understand how the derived value was produced.

The blank appearance of a spreadsheet cell does not resolve this distinction. A file exporter, importer or viewer may display multiple underlying states similarly. A CSV teaching file therefore needs explicit labels if it is meant to preserve the difference between omission, null and an empty string. In this batch's CSV, a state label and a JSON-literal column make that intention visible. The CSV is a companion description, not a claim that ordinary CSV has a universal native null representation.

Case F: the string zero is text

Case F supplies response as the string zero, written as a quoted digit in JSON. It is text, while case D supplies a number. The two can look alike after a display layer removes quotation marks. A summary that says both records contain the same numerical value would need a declared conversion rule. The original teaching contract performs no such conversion. It preserves F as a string and leaves any numerical interpretation to a separately specified task.

This matters when text fields contain identifiers, codes or values that resemble numbers. A leading zero may be part of an identifier rather than insignificant numerical formatting. A decimal-looking string may use a locale convention that the importer does not understand. Those broader cases have their own requirements. The narrow lesson here is to keep a JSON string as text until a task explicitly defines a justified conversion, including what should happen when conversion fails or changes the original representation.

An assistant can help prepare a proposed conversion specification. It can list the source field, expected input type, allowed characters, desired output type and unresolved examples. That draft is different from executing a migration or changing a destination record. The source may also contain values outside the six teaching states. Do not claim complete schema coverage from these cases. They provide a small set of contrasts that make a common ambiguity visible, not an exhaustive catalogue of every possible data state.

Write the field contract before the summary

A useful original contract for the teaching exercise states that the object identifier is required, the response property may be omitted, and any supplied response must retain its original JSON type and value in the preservation output. The output description separately labels absent, explicit null, boolean, number and string states. This is an invented exercise rule. It is not a universal business standard or a production schema, and the article does not run a JSON Schema validator against a destination application.

For a real workflow, the contract should explain what the field represents, which states are permitted and what each permitted state means. It should also explain whether a missing field means keep an existing value, reject a request, ask a question or perform some other defined action. An assistant cannot infer that behavior from JSON syntax. A field that is optional in a data exchange can still be essential for a particular business task, so distinguish structural validity from task completeness.

Version the contract when its meaning changes. If an earlier export used an empty string for an unanswered question and a later export uses null, combining them requires a documented interpretation. The change might be harmless for one analysis and material for another. Keep the export version or collection period with the records when it is available. Do not turn a newly discovered convention into a claim about every historical record unless the evidence actually establishes that history.

Do not infer update behavior from representation alone

A payload with an omitted property and a payload containing null can have very different effects in different APIs. Some interfaces may leave an existing field unchanged when it is omitted. Others may require the field on every request. A null might clear a value, be rejected or be stored as an explicit state. This guide does not specify those effects because the teaching records are static examples, not requests to a particular service. Read the destination's actual contract before proposing an update.

A draft handoff should therefore separate source description from intended action. It can say that record B contains explicit null, then leave the proposed destination treatment unresolved until the application rule is supplied. It should not say that the destination was cleared or that the customer requested deletion. A generated mapping table is a proposal. It does not establish permission to modify records, confirm an API response or demonstrate that a downstream system preserved the intended meaning.

When a destination supports only a smaller set of states than the source, identify the information loss explicitly. Mapping absent, null and empty string to one blank destination value collapses three source conditions. That may be a deliberate product choice, but it should be reviewable before execution. Keep enough source information to explain the mapping where the authorized workflow allows it. Do not promise reversibility if the destination cannot distinguish the original states after they have been combined.

Count records using a declared inclusion rule

The six authored records contain five present response properties because A omits the property. Four supplied values are non-null because B contains null. Three supplied values are non-null and are not empty strings: false, zero and the string zero. These are different counts with different inclusion rules. None is automatically the number of meaningful customer answers. The field contract deliberately does not supply a business definition of a meaningful answer, so that broader count remains outside the exercise.

A report can show multiple counts when the labels make the definitions clear. For example, present property count can be five while non-null property count is four. Keep the denominator alongside each count. Five out of six records is a statement about property presence in this fixture. It is not a response rate for a real survey, a completeness score for an organization or a model accuracy result. The authored inputs are too narrow to support those interpretations even if the arithmetic is exact.

Avoid labels such as valid, complete or usable unless their rules are stated. A boolean false can be a valid supplied value under one contract and the wrong type under another. An empty string can be present but fail a task-specific minimum-length requirement. A property can be required yet allow null as a value if the applicable schema says so. Keep the structural, semantic and task-specific checks separate so that a reader knows what a reported count actually measures.

Give an assistant an instruction that preserves uncertainty

An original practice brief can read: Use only the supplied JSON objects. For each identifier, state whether response is present. If present, state its JSON type and exact value. Keep null, false, numeric zero, empty string and the string zero distinct. Do not trim, coerce or fill missing values. Do not infer consent, customer intent, completion or destination behavior. Report the defined counts separately and state that their meaning is limited to these authored records.

A second task can ask for a proposed mapping only after the source description is complete. Supply the destination contract, then request a mapping table with unresolved cases. This ordering makes it harder to hide a transformation inside a supposedly faithful summary. It is still a proposed workflow, not a security guarantee or evidence of model reliability. An actual evaluation would need its own authorized cases, model configuration, observations and review criteria, which this static teaching exercise does not provide.

Ask for examples of uncertainty in the draft explanation. A useful answer can say that omission is established but its business meaning is unknown, or that null is explicit but clearing behavior is unspecified. Those are precise limitations. A vague statement that the data is unavailable can erase the fact that a value was supplied. Conversely, forcing every record into a positive or negative business status can fabricate certainty. The desired output should allow an unresolved interpretation when the contract is incomplete.

Review the downloaded fixture as a preservation exercise

The JSON file contains the original six objects and manually specified state expectations. The companion CSV labels each case and includes the expected literal representation, with an explicit absent marker for case A. The local checks inspect property membership before examining values. They use exact type distinctions so that Python's boolean relationship to integers does not accidentally make false interchangeable with zero. That is a check of the authored fixture, not a test of an assistant or a claim about all JSON-processing libraries.

After publication, the same consistency checks run against the exact downloaded files. Matching bytes establishes that the released asset matches the authored asset. Rechecking the parsed records establishes that the visible case labels agree with the declared states and counts. Neither check validates a real customer's records, a production export, an API update or a full JSON Schema implementation. If adapting the exercise, replace the invented field contract with the actual authorized one and keep any additional transformations visible.

Frequently asked questions

Is a missing property the same as null?

No. A missing property is absent from the object, while an explicit null is a supplied value. The business meaning of either state depends on the field contract. In the original fixture, A omits response and B supplies response as null. The exercise preserves that distinction without inferring that either record represents a refusal, a deletion request or an unsuccessful operation. A destination's treatment of those states must be established separately from the source representation.

Can false and zero be grouped together?

Only for a deliberately defined purpose that accepts the loss of their type distinction. The fixture keeps false as a boolean and zero as a number. A convenience test inside a programming language should not silently define business meaning. If an analysis groups them, explain the rule and retain the original states where appropriate. Neither state alone establishes a customer's intention, an account permission or whether a process succeeded; those interpretations require additional supplied context.

Does an empty CSV cell tell me the original JSON state?

Not by itself. A particular exporter may use an empty cell for several source conditions, or may define a special marker. Read that exchange contract. This teaching CSV includes explicit state labels and a literal column so that its intended distinctions remain visible. It does not establish a universal CSV null convention. If the original source was already flattened without a mapping record, a later assistant cannot reliably reconstruct the lost distinction merely from a blank display.

Can I replace missing counts with zero before averaging?

That substitution needs a supported rule. A supplied count of zero differs from an unknown count. In the independent two-count example, four and zero average to two; if the second count is unknown, only the known-subset mean of four is available and the overall mean is unresolved. Do not label that subset result as the overall result. The example illustrates an arithmetic consequence, not a recommended missing-data method for every dataset or a professional statistical finding.

Will null clear a field when sent to an API?

That depends on the endpoint and its update contract. The static records here are not API requests and have no destination effects. Check the applicable method, field rules and error behavior before proposing a mapping. Keep a proposed clearing action separate from the observation that a source value is null. This guide does not perform an update, supply authorization, validate a provider's behavior or establish that an omitted field leaves an existing value unchanged.

Do the fixture checks measure AI accuracy?

No. They check six authored records, their manual state expectations and the defined counts using ordinary parsing and exact type distinctions. No model was run and no production data was inspected. The files can help prepare a later authorized evaluation, but they do not supply its observations. Preserve that boundary when sharing the worksheet, and keep schema validation, business interpretation and permission to change destination records as separate questions.