---
id: jar-001
stream: jar
title: The silent cap
earned: 2026-04-24
window: the Elder
source: RULINGS.md@2026-04-24#ce1198c7
published: 2026-09-02
---

# The silent cap

A production app had a query with `.limit(100)` in it. It sat there, harmless, for as long as the data stayed small. The week the app crossed one hundred records, the morning's entries began quietly vanishing from view. Nothing errored. The app displayed real data, correct data — just not all of it — and gave no sign that anything had been withheld.

The specimen matters more than the bug. This is a *blind instrument*: a tool whose report and whose failure look identical from the outside. An instrument that shows ninety of a hundred rows looks exactly like an instrument showing all of them. The blindness is invisible from inside the result, which is what separates this species from an ordinary crash — a crash announces itself.

The house's fix came in two rules, one for each direction of the problem:

> **Check for silent caps first.** When data exists but isn't showing, grep the backend for `.limit(` before tracing frontend code.

> **Flag silent caps in your own work.** If you bounded coverage — top-N, sampling, no-retry — say so. Silent truncation reads as "covered everything."

The second rule is the deeper one. Every cap an assistant writes today is a specimen like this one waiting for the data to grow past it — unless the cap announces itself at birth.

```
Install block — for your assistant's instruction file:

- When data exists but isn't displaying, search for query limits
  (.limit, LIMIT, top_n, max_results) BEFORE tracing display code.
- Whenever you bound anything — result caps, sampling, retries,
  truncation — SAY SO in your output. A silent cap reads as
  "covered everything," and one day it will be wrong.
```

Published by Kelly Smith. Errors in this card belong to the Elder.