The quarantine queue: a product argument

Here is the position this essay defends: when software classifies something you care about as junk, it owes you the ability to check its work. Concretely, in our product: a form submission that trips our content heuristics is not deleted. It is held in a quarantine queue where one click reviews it and one click approves it, delivering the row to your sheet as if nothing had happened. Only the honeypot - a hidden field no human can see, let alone fill - marks a submission as spam outright.

This sounds like a feature description. We want to argue it is something more: a philosophy about what software may and may not do silently.

Every spam filter is a classifier, and every classifier has exactly two failure modes. A false negative lets junk through: a bot's link-stuffed message lands in your sheet. A false positive blocks the real thing: a legitimate inquiry - oddly worded, sent fast, from a strange network - gets flagged.

No filter escapes this tradeoff; tightening one error loosens the other. The design question is never "how do we avoid mistakes" but "which mistake do we make survivable." Most form products answer by accident, inheriting whatever their filter vendor does. We think it deserves to be answered on purpose.

The two errors are not the same size. A false negative costs seconds: you see the junk row, you delete it, mildly annoyed. A false positive that is silently dropped costs a lead - a customer who wrote to you and concluded you ignored them - and it costs it invisibly. There is no error message, no log entry you will ever look at, no moment where anyone learns a mistake occurred. The customer thinks you are rude; you think it was a quiet week.

When one failure mode is cheap and self-evident while the other is expensive and undetectable, the design conclusion follows almost mechanically: never let the expensive, invisible error happen silently. That single sentence is most of our spam architecture.

The strongest evidence for reviewable holds is that billions of people already rely on one daily. Email's spam folder is exactly this pattern: the filter classifies aggressively, but classification means set aside, not destroy. When an expected message goes missing, everyone on earth knows the ritual - check the spam folder. Recovery is self-service and takes seconds.

It is worth noticing what email did not do: it did not silently delete suspected spam, even though storage was once expensive and filters were once crude. The folder survived because it makes the filter's mistakes recoverable, and that recoverability - not accuracy - is what lets users tolerate an imperfect classifier. The reviewable quarantine is not our invention. It is the most battle-tested trust pattern in software, applied to forms.

To be fair to the other side: silent dropping is not malice, it is optics. A filter that discards junk invisibly produces a beautiful artifact - a clean sheet containing only real leads. The product looks accurate precisely because its errors are unobservable. A quarantine queue, by contrast, puts the filter's uncertainty on screen, which reads as weakness even though it is honesty.

There is also a real cost argument: review requires a reviewer, and "fully automatic" demos better than "mostly automatic plus a queue." Vendors optimizing for the demo choose silence rationally. We just think the optimization target is wrong - the demo lasts ten minutes, the false positive costs a customer.

The general principle underneath: when software makes a judgment call about something the user cares about, the judgment should be inspectable and reversible. Version control keeps history so a bad merge can be unwound. Trash folders hold deletions before purging them. Email quarantines rather than deletes. In each case the software is allowed to act on its own judgment precisely because its judgment can be audited and overruled.

Silent classification breaks this contract. It asks for trust while destroying the evidence that would justify or refute that trust. Our position is that a form backend - whose entire job is custody of messages that belong to you - has less license for unauditable judgment than almost any other category, not more.

Mechanically: submissions pass through layered checks - per-form and per-IP rate limits, the origin allowlist, the timing signal from sl.js, and content heuristics that look at link stuffing, disposable email domains, and empty payloads. A per-form strictness dial (loose, normal, strict) sets how suspicious the heuristics are allowed to be, which matters because a portfolio contact form and a high-traffic ad landing page face very different threat profiles.

Whatever the heuristics hold lands in the queue. Review is deliberately boring: read, click approve, and the row delivers to your sheet through the normal pipeline; or discard it. The full architecture is laid out in the spam protection guide.

The quarantine model has a price and we will not pretend otherwise: someone must review the queue. On a noisy form with a strict dial, that is a recurring chore - a minute here, a minute there, forever. Silent dropping has no such chore; that is its entire appeal.

We accept the cost for two reasons. First, the asymmetry argument: minutes of review are cheap insurance against invisible lost customers. Second, we pay it ourselves - our own forms run on the product, and we review their queues like anyone else, which keeps us from romanticizing the burden. If the chore ever becomes unreasonable, the honest fix is better heuristics and a looser dial, not a switch that makes mistakes invisible.

Quarantine handles ambiguity; it does not reduce volume. If your form is under sustained automated attack - hundreds of junk submissions a day, a queue growing faster than anyone can skim it - review stops being a safeguard and becomes a job. That is the point where we would tell you, without hedging, to enable the optional Cloudflare Turnstile integration and challenge automation before it ever reaches the heuristics.

Turnstile is a gate at the door; quarantine is due process inside. They compose rather than compete - the gate cuts the flood to a trickle, and the queue keeps the trickle's edge cases recoverable. Our comparison of the two approaches is in quarantine vs CAPTCHA.

Classifiers err. The two errors are asymmetric: junk in your sheet costs seconds, a silently dropped lead costs a relationship and leaves no trace. Email's spam folder proved at planetary scale that users forgive an imperfect filter when its mistakes are visible and reversible, and never learn to forgive the invisible kind. So: hold, review, approve - and reserve outright rejection for the honeypot, the one signal with no innocent explanation.

That is the whole philosophy. You can watch its pipeline run on the live demo, read the operational details on the security page, or start free and put a queue of your own to work.

What happens to a submission SheetLink thinks is spam?

Why is the honeypot allowed to reject outright?

What is failure asymmetry?

How is this like an email spam folder?

Doesn't reviewing a queue take time?

When should I turn on Turnstile?

Can I control how aggressive the heuristics are?

Does approving a quarantined submission lose any data?