Anti-Spam Boundary
An anti-spam boundary defines the minimum spam and abuse controls a production intake surface must hold before being enabled — rate limiting, honeypot fields, server-side verification (Turnstile-style), suppression handling, and complaint monitoring. The current OmniLabs prototype intake is mock-mode by default with no production endpoint; the anti-spam boundary is what an endpoint stage must implement before it ships.
Definition
An anti-spam boundary names the specific spam, abuse, and complaint controls the intake surface must hold. It is one of four operating boundaries — intake, consent, anti-spam, retention — that together define the production intake posture. The controls are concrete: rate limit window, honeypot field name, verification provider, suppression list source, complaint feedback loop.
Why it matters
A real intake surface attracts adversarial submissions immediately. Defining the anti-spam controls before enabling the surface avoids the failure mode where the endpoint ships, gets abused, and has to be hardened in production while degraded.