What a Form Can't Record, Policy Can't See

Forms built for fast processing leave out whatever doesn’t fit their fields. Benefits agencies, lenders and hospital billing all convert messy human reality into machine-readable schemas. We assume cleaning the data clarifies the truth, but often it erases the part of the truth that mattered.

Strict schemas trade signal integrity for predictable computation. We want dropdowns instead of text fields, integers instead of descriptions, standard codes instead of what people actually say. Data collected that way is clean for the database and often useless for whoever has to act on it.

The information that matters most is often the residue: the friction, the outliers and the unmodeled details at the boundary between the world and the model. Sanitizing input to fit a category chosen in advance strips out the first signs of a systemic failure.

The schema decides what exists

A schema is a data structure and also a claim about what exists, so leaving something out of it is an ontological erasure. If something cannot be expressed within its constraints, the institution’s records don’t show it, and its decisions proceed as if it were absent.

Long COVID is a recent case. By mid-2020 patients were describing symptoms lasting months after infection. The WHO released the emergency code U09.9 for post-COVID conditions in September 2020, but the US version of the classification didn’t adopt it until October 1, 2021. Until then the American Hospital Association’s coding guidance told coders to use B94.8, “sequelae of other specified infectious and parasitic diseases,” a bin that held the aftermath of every other infection too.1 For more than a year, American billing data could record the fatigue and the breathlessness but couldn’t cleanly say that they came together or what they followed.

Welfare eligibility works the same way. A household getting through a crisis by pooling income across relatives or trading care for rent has no field for the arrangement on a form built around household income and assets. The system sees a data mismatch where a person is getting by, and flags it.

Diagram

The sanitization filter and the high-fidelity sensor

View source

%% title: The sanitization filter and the high-fidelity sensor
%% caption: A lossy pipeline discards what does not parse and never learns it did; the high-fidelity sensor keeps the raw residue where a person can detect the failure the record missed.
graph TD
    classDef actor stroke-width:1.6px;
    classDef binding stroke-width:3px,font-weight:bold;
    classDef failure stroke-width:2.2px,stroke-dasharray:6 3;
    subgraph "The Sanitization Filter (Lossy)"
        A[Raw reality] --> B{Schema Match?}
        B -- "Yes" --> C[Sanitized Record]
        B -- "No" --> D[Discarded/Error]:::failure
        C --> E[Database/Model]
        D -.->|Erasure| E
    end

    subgraph "The High-Fidelity Sensor (Resilient)"
        F[Raw reality] --> G[The Sensor/Buffer]
        G --> H[Parsed Record]
        G --> I[Raw Signal Residue]:::binding
        H --> J[Database/Model]
        I --> K[A person who can read the residue]:::binding
        K -->|Detects Failure| J
    end

Designing for the residue

Letting people describe their situation in their own words and having a language model sort it afterwards doesn’t escape the problem. A language model is another categorizer, trained on the patterns it has already seen, and will fold an unfamiliar case into the nearest familiar one as readily as a dropdown does. Extraction by a model can be useful as an index. It cannot stand in for the record.

A rule that the original input is never thrown away works better. The person who has to judge the case must always have access to the original, unparsed input, and the database record is treated as a representation of it. When a result feels wrong, the system must be able to go back to the source and inspect the residue. Keeping the raw signal changes nothing unless the person who reads it can force the schema to change, so a finding from the raw stream has to reach the rule behind the erasure, and not only the case in front of her.

Categories can also be built to report their own failure. Every dropdown can carry an “other, describe” option whose free text is kept, and the count of “other” answers in each field can be watched. When the count rises, the categories have drifted from the world, and someone has to redraw them.

An intake pipeline’s main job is to keep what people report, in their own words, when the system is failing them. A clean database is at best a by-product. A record that keeps only the parsed version cannot show anyone that its categories have stopped fitting the world.