That guarantee is not delivered by prompting, model choice, or luck. It's delivered by architecture: a ground-truth registry enforced at a validation boundary, entity state that treats AI output as untrusted until reviewed, a caching layer that makes the model the cold-start path rather than the hot path, and failure modes that fail closed. This piece walks through that architecture, from the layers to the request lifecycle to the trade-offs I considered and rejected, in a way you can lift for any feature where an LLM produces checkable output.

The stack for context: Next.js on Cloudflare Workers, SQLite locally and D1 in production, a single OpenAI-compatible LLM endpoint (DeepSeek) behind a thin client. Small site, small budget, and I'd argue that's exactly where this architecture shines: it spends nothing on runtime and moves all the trust questions into places where answers are cheap.

The core design decision

Most "AI safety" discussions in product teams start with model behavior. This architecture starts one level down, with a question: what does the system already know to be true?

For emoji, the answer is unusually clean. The Unicode standard publishes the complete registry of valid emoji sequences, 3,564 of them in the revision I imported. That transforms the safety problem from "assess output quality" (hard, fuzzy, model-flavored) into "verify output membership" (exact, computable, free). The entire architecture falls out of refusing to solve the hard version of a problem that has an easy version.

Generalize it: any domain with a canonical registry (country codes, drug names, SKUs, airport codes, your own accounts table) gives you the same leverage. The model proposes; the registry disposes. Where teams get into trouble is treating registry-checkable facts as if they needed judgment, or worse, inventing judgment systems (model-scoring-model) to approximate a lookup they could have had for free.

Everything below is the machinery around that one decision.

The four layers

The pipeline separates trust into four layers, each with a single responsibility. The separation matters more than any individual check: when a bad thing ships, you want to know which layer's contract broke, and when you swap the LLM provider (I've done it once already), only one layer even notices.

Layer 1: The contract layer

The model speaks through one function, a single-turn chat completion with JSON mode (response_format: { type: 'json_object' }), a fixed response shape ({slug, name, description, combos[]}), and a generous token ceiling. Two decisions in this layer are load-bearing.

First, the contract is tolerantly parsed. Even in JSON mode, models occasionally wrap the payload in markdown fences or open with a sentence. The parser strips fences, then falls back to slicing from the first { to the last }, then validates the payload's shape field by field before any value is trusted. payload.combos being null should be an explicit, named error, not a TypeError three frames later.

Second, the token ceiling budgets for hidden reasoning. The production model spends reasoning tokens before emitting JSON, and reasoning plus body share one max_tokens budget. A ceiling sized for the visible output alone produces intermittent empty completions that look like network flakes. (This cost me an evening once; the ceiling is now 4,000 tokens for output that needs a few hundred.)

The layer's philosophy: the model is a helpful but sloppy API client. Treat its output like user input, because it has the same relationship to truth that user input does.

Layer 2: The validation boundary

Validation runs before anything persists. Three checks, in one pass over each proposed combo:

1. Grapheme segmentation via Intl.Segmenter: the unit of validation is the user-perceived character, never the code point, because joined sequences (families, multi-person poses) shatter under [...str] into fragments that individually look valid and collectively aren't.

2. Dictionary membership: every emoji-looking grapheme (detected via \p{Extended_Pictographic}, with skin-tone modifiers stripped to collapse mixed-tone variants onto enumerated bases) must exist in the imported Unicode registry, held as an in-memory Set.

3. Invisible character rejection: zero-width and bidi control characters are rejected outright; on platforms that parse pasted bios for mentions and tags, they're a known injection primitive.

The boundary's contract is absolute: anything crossing it is either registry-verified or nonexistent to the rest of the system. Downstream code never re-checks emoji validity, because upstream made the question meaningless.

Layer 3: The persistence layer

The database gets three rules the model cannot talk its way past.

AI output lands in a draft state. A generated vibe is created with status: 'draft', which excludes it from public listings, the sitemap, and featured placement. It becomes a permanent, indexable page only when an admin promotes it from the review queue. The searcher who triggered the generation sees results in their session; the site commits to nothing until a human has said yes.

Uniqueness is a constraint, not a hope. Combo content carries a database-level unique constraint. The model regurgitating a combo that already exists produces a tolerated unique-violation on insert, not a failed request. Dedupe is enforced where it's race-proof: two concurrent generations of the same vibe can both write, and the constraint arbitrates.

Batches have a floor. A generation requests ten combos; fewer than four valid survivors fails the whole batch. This is the subtlest rule and the one I'd fight for. "Ship whatever survived validation" is tempting and wrong: a batch that mostly failed is a signal that something upstream drifted (prompt regression, model swap, provider quirk), and its survivors are a biased sample of a broken process. The floor converts rejection rate from silent quality decay into an observable event.

Layer 4: The review queue

The human layer is deliberately scoped. The queue reviews taste: variety within the set, on-theme-ness, whether the auto-written vibe description is any good. It never reviews correctness; dictionary membership, length, invisible characters, and duplicates were all settled deterministically before persistence.

That scoping is what makes a one-person review queue viable at all. Humans are the most expensive validators in the system; pointing them at questions a Set answers faster is architecturally wasteful, and pointing them at nothing (full auto-publish) is how "the site is legally a robot now" happens. The draft-until-reviewed state is the compromise: live results for the visitor, permanence gated on judgment.

The request lifecycle

Putting the layers in motion, for a visitor searching "haunted library":

1. Search runs against curated vibes. No match → the generation path activates (if the feature is enabled at all; an absent API key disables it end to end, returning 503 and a static empty state, which is the fail-closed posture).

2. The query is normalized (trimmed, lowercased, length-capped) and slugified. Cache check: if that slug exists and already has six or more approved combos, serve them. The model is not called. Most requests on mature vibes die here, happily.

3. No cache → the contract layer requests ten combos, passing the existing vibe slugs along to the model so it can reuse a canonical slug for synonym queries ("可爱" should land on cute, not spawn a duplicate vibe).

4. Validation runs over the response. Dictionary, segmenter, invisible characters, within-batch dedupe.

5. Canonical re-check: because the model may map the typed query onto an existing vibe's slug, the cache is consulted again under the canonical slug before creating anything. This closes the duplicate-entity race that simple "check cache → generate → insert" flows miss.

6. The vibe is ensured in draft state (with an idempotent create-and-read-back on unique races), valid combos persist under it, and the visitor gets their results.

7. Eventually, a human promotes or discards the vibe in the queue. Promotion makes it permanent and public; nothing else does.

Step 5 is the one I'd highlight in any design review. Two cache checks around one model call looks redundant until you notice the model is also a canonicalizer, turning arbitrary human queries into canonical entity slugs, and the second check is what prevents "cute," "kawaii," "可爱," and "cute aesthetic" from becoming four vibes with four pages competing for the same intent in search.

Cache economics: the model as cold-start path

The threshold-six rule reframes what the LLM is for. It's not the serving layer; it's the bootstrap. A vibe's first few searches may hit the model; everything after serves stored, validated, human-reviewed data.

The economics compound in the right direction. Validation made stored output trustworthy enough to serve; serving stored output made the model rare; rarity capped both cost and hallucination surface. Meanwhile the review queue converts each cold-start generation into permanent inventory. The feature gets cheaper per request as it gets older, which is the opposite of the naive "AI feature" cost curve (stateless model-per-request) and, I suspect, the only shape that makes sense for a small site.

Runtime notes from the edge

Two deployment realities shaped the design and generalize beyond Workers.

Data ships with the artifact. The edge runtime has no filesystem, so the emoji registry (and the blog manifest, and everything else content-shaped) is bundled into the build and imported as a module. That's a feature wearing a constraint's clothes: the registry loads once at isolate start, membership checks hit an in-memory Set, and there is no "dictionary service" to page you at 3am. Ground truth that travels with the code can't drift from it.

Writes are idempotent by construction. Edge deployments scale horizontally, and two isolates can receive the same empty-search query concurrently. The design never assumes single-flight: generation is safe to repeat, inserts race on unique constraints, and the canonical-slug re-check keeps entity creation convergent. Any correctness that depends on "only one request at a time" is correctness you don't have.

What to measure

The pipeline's health signal is one number: validation rejection rate per batch. Steady-state single digits; a spike means prompt drift, a provider change, or a Unicode revision the dictionary hasn't imported yet. The batch floor (four-of-ten) turns that signal into an enforced threshold rather than a dashboard you stop reading. Rejection reasons are nearly as cheap to log: invalid graphemes versus invisible characters versus shape failures tell three different stories about what's wrong upstream.

What I deliberately don't measure: model-side scores, self-reported confidence, "quality" percentages. In a registry-validated pipeline, those are noise adjacent to a ground truth you already own.

Trade-offs and rejected alternatives

A second model as judge. Rejected: it has the same failure mode as the first (predicting plausibility, not consulting truth), adds latency and cost, and creates a second thing to monitor. Chains of LLMs checking LLMs are theater when a Set.has() is exact.

A hosted moderation/classification API. Rejected for this use: moderation models assess acceptability, not existence, and the requirement here is existence. (Moderation APIs are the right tool when the risk is tone or policy, not ontology.)

Prompt-only containment ("only use valid emoji, double-check each one"). Rejected as a category: prompts are suggestions executed by a token predictor. This layer still exists (the system prompt asks for variety and reuse of canonical slugs), but it steers quality, never correctness.

Full auto-publish with post-hoc cleanup. Rejected: the cost asymmetry is wrong. A bad vibe page is indexed, shared, and linked before cleanup; the draft gate costs one human minute per vibe and makes that class of accident structurally impossible.

Takeaways for your own pipeline

• Find the registry first. If your domain has a canonical list of what's real, validation is a lookup and "AI safety" becomes an engineering problem with a right answer.

• Draw a hard validation boundary and let nothing cross unverified. Downstream code should be able to forget that AI was involved.

• Treat the model as a sloppy API client: tolerant parsing, shape validation, budgets sized for hidden reasoning, fail-closed on absence.

• Use the model as a cold-start path, cache into reviewed inventory, and let the feature get cheaper as it ages.

• Keep humans where judgment lives. Scoping review to taste (not correctness) is what makes a one-person queue sustainable.

• Enforce idempotency in the data layer; never trust single-flight on horizontally scaled runtimes.

The system in the wild is emoji-combos.net: the AI-assisted search exercises this pipeline end to end, and the field guide shows the human-curated side it feeds into. If you're designing something similar, I'm genuinely curious where your registry hides; the comments are open.

FAQ

Can this architecture reach literally zero hallucinated emoji in production? For the property "published emoji exist in the Unicode registry," yes, because the check is deterministic and enforced before persistence. What it can't guarantee is taste or on-theme-ness; that's the review queue's job, and it's subjective by definition. The honest claim is "zero checkable defects," which happens to be most of what users would call broken.

How does the pipeline handle a new Unicode emoji release? Re-import the registry, rebuild, redeploy. The dictionary is bundled data, so the validation boundary itself never changes shape. Between releases, brand-new real emoji are treated as invalid until imported, a safe default since the alternative is accepting unverified sequences.

Doesn't the second cache check add latency? One indexed slug lookup against a warm database, negligible next to the LLM call it precedes, and it only runs on the generation path, which the cache usually short-circuits anyway.

What breaks if the provider silently changes behavior? The contract layer's tolerant parsing absorbs format drift; the batch floor catches quality drift by failing loudly; the review queue is the final net for whatever is technically valid but wrong. The design assumes provider drift is a when, not an if.

Is the human review queue a scaling bottleneck? It's a deliberation point, and it's automatable in tooling without automating the decision. What shouldn't scale away is the draft-until-reviewed state itself: bulk-approve tools are fine, auto-publish is the line, because the queue is the only layer that can notice "everything is correct and none of it is good."