The interesting engineering in a data product was never the happy path. It is what you print when the good data is not there, and that decision belongs in the code, visibly, where the next person tempted to fill the blank will find it.
I build RegWatch, a property records product, alone. Part of it is a Title Search Abstract, which is the deliverable most likely to hurt someone if I get the missing-data question wrong. So before anything else, the boundary: instruments print as recorded. The document never decides whether a mortgage is open or satisfied. It is a data deliverable for an examiner, not a title opinion, not insurance. The examiner concludes. The core of that rule sits as a comment at the top of the assembler, verbatim: "No open/satisfied mortgage verdicts. Instruments as recorded; the examiner concludes."
Everything below is about what happens when a value is not there. Every claim has a file behind it.
Grey is not yellow
The abstract's field map (`lib/v2/abstract-fields.ts`) carries 69 fields. The map began as a teardown of five incumbent title packages and grew as the abstract gained searches. A coverage page runs any address against all 69 and grades each cell. The grading is where the design lives.
Fifty-three fields are produced from my data. Three belong to the underwriter's contractual layer. One is typed by the preparer. And twelve are marked `not_produced`, each with its reason written next to it.
A field that was expected and rendered nothing gets flagged yellow. The twelve deliberate blanks render grey, never yellow. The comment in the file says why, verbatim: "Neither is a defect, and colouring them like one would train the eye to ignore the colour that means something."
That sentence is the whole argument. If an on-purpose blank looks like a broken field, an examiner scanning the page soon learns that the warning colour is noise. Then the one yellow cell that actually matters, the expected value that failed to render, gets the same glance as everything else. The honesty of the blanks protects the credibility of the warnings.
The number I hold and refuse to print
One of the grey fields is the tax rate. I hold a number for it. The field prints nothing anyway, and the note in the field map starts with the reason: "Held, but its only source is a stale v1 snapshot."
A stale tax rate on a title document is not a small error, because somebody will quote it in a closing. Holding a number and being able to stand behind it are different things, and the gap between them is exactly what a data product is selling. So the field is suppressed, permanently, with the justification checked into the repo where the temptation will be found.
The conclusion an examiner signs
Another grey field is estate or interest, the line that usually reads "Fee Simple." The note in the file calls that phrase "a legal conclusion an examiner signs," and a conclusion is not a fact the product holds. It also records that the value is derivable from the property class code, and deliberately not asserted. That is the part I want a builder to sit with. The tempting version is one line of code: class code says single-family, print Fee Simple, be right nearly every time. But nearly every time is the wrong standard for a field that a person with a licence attests to. The blank is not a gap in my data. It is the seam between a data deliverable and a professional judgment, drawn on purpose, in a file, with a comment.
Tenancy is blank for a different reason: ACRIS indexes the parties to a deed, not the tenancy clause. Joint tenancy versus tenants in common is written in the body of the instrument, and the index does not carry it. And judgment or bankruptcy searches by person name are blank because person-scope searching sits next to consumer-screening regulation. That is a scope decision, not a data gap, and the note says so.
Zero rows is not "none found"
The laziest bug in any aggregation product is treating an empty query result as a finding. The abstract's coverage type refuses the shortcut by construction. It is a three-state enum in `lib/v2/title-abstract.ts`: `covered`, `partial`, `not_covered`.
The distinction does real work. Zero deed rows in a county I fully ingest is a finding, and the document prints the affirmative "none of record" line. Zero rows in a county I do not ingest is nothing at all, and the document prints a coverage wall saying so instead. In between sits `partial`, where found rows render but the negative assertion degrades, because a clean-result claim over a half-walked feed is a false clean. The per-search municipal documents apply the same rule harder: the affirmative no-record line renders only at full coverage, since a standalone letter asserting no fire violations is a stronger claim than a section inside a combined abstract.
This matters where my coverage is honest about being uneven. It runs deep for New York City and Connecticut, and thin for New Jersey and upstate New York. New Jersey owner names are blank by law under Daniel's Law, and no version of this product gets them back. A quiet page for a Bergen County parcel is a coverage boundary, not a clean building, and the enum is what keeps the document from saying otherwise.
The same discipline applies to freshness. When a search can be topped up live against the agency feed, it stamps "new filings checked live" only when every live feed mapped to that search answered at render. One unanswered feed and the search prints no freshness claim at all. None on gap. And when no certificate of occupancy turns up, the empty finding names its own scope: which feeds were searched, that buildings finished before 1938 may lawfully lack a certificate, an explicit hedge when no construction year is published, and a referral to the borough office microfilm where pre-digitization certificates live. A bare "no CO found" would be shorter and worse.
A benchmark that says what it is
The rent tool (`lib/v2/rent-fairness.ts`) applies the same rule to a consumer surface. Its benchmark is Zillow's ZIP-level asking-rent index, scaled by HUD bedroom ratios. When the index has no row for a ZIP, it falls back to HUD's Small Area Fair Market Rent, then the metro figure. And here is the detail I care about: those fallback tiers relabel themselves. The methodology sentence the user sees calls the number "a 40th-percentile program benchmark" and says asking rents often run higher, because an FMR is a housing-assistance payment standard, not an asking rent, and printing one as the other is a confident wrong number wearing the previous tier's clothes. Confidence drops a grade at each step, and a gap at the end of the ladder returns null, not an estimate.
That null is not theoretical caution. The previous rent tool at the same path was retired on 2026-07-06, in the code's own words, "for showing simulated data as real." I deleted my own tool for the failure this whole article is about. The rebuilt one carries the source, vintage and confidence of every number it prints.
Where the decision lives
None of this is a disclaimer page. Disclaimers live in footers and get ignored. These decisions live in enums, producer tags, render guards and field notes, which means they are versioned, diffable, and enforceable in review. When someone eventually asks why a field is blank, the answer is a file path, not a memory.
The coverage page is the whole idea in one screen: pick an address, see exactly what the abstract would print there, and see every hole graded honestly, grey where the blank is deliberate, yellow only where something actually failed. It ships on the partner side of the product, for the people who order these searches. The rest of RegWatch is at regwatch.nyc.