DEV Community: Mr.Rain

Your MDX Blog Will Throw EvalError on Cloudflare Workers. Here's the Fix.

Mr.Rain — Sun, 01 Nov 2026 08:30:42 +0000

Our bilingual product blog had a bug that never appeared locally, never appeared in
next build, and turned every blog post into an HTTP 500 in production — on exactly one
runtime. The error:

EvalError: Code generation from strings disallowed for this context

If you are shipping a Next.js app to Cloudflare Workers (we run
Christmas Photo AI on Workers via OpenNext) and your
content pipeline uses next-mdx-remote, this post is your future. Here is what happens,
why, and the surprisingly small fix.

The bug that only exists in production

The stack: Next.js 16 App Router, React 19, MDX posts rendered through
next-mdx-remote/rsc. Everything was green locally with next dev, green in CI, and the
build itself succeeded. Deployed to Workers, the home page, style pages, and pricing all
worked — but every single blog URL returned a 500.

That gap is the first lesson: the compile step that hurts you doesn't run where you
test. next build pre-renders what it can, but request-time rendering on a different
runtime is a different execution environment with different rules.

Why Workers disallow it

Cloudflare Workers run with V8 isolates configured to forbid dynamic code evaluation —
eval() and new Function(...) both throw EvalError. It is a security posture, not a
bug, and it will not change.

next-mdx-remote's whole job is turning MDX source into executable JavaScript at runtime.
Under the hood it compiles the MDX and evaluates the result as a function. On Node.js
that's fine. On Workers it is precisely the operation the platform forbids.

So the 500 was correct behavior. Our dependency was doing the one thing this runtime
refuses to do — at request time, in production only.

The audit that made the decision easy

Before choosing a replacement, we asked a simpler question: do we actually render any
MDX?

The answer was no. The posts were plain GFM — headings, paragraphs, lists, tables, links.
No imported components, no custom JSX inside the content. We were paying for a runtime
MDX compiler to render… markdown.

That reframed the fix from "find an MDX compiler that works on Workers" to "use a
markdown parser." Which is a much smaller problem.

The fix: marked + sanitize + one CSS block

We switched to marked — a pure parser, no code generation —
and ran its HTML output through a sanitizer before injecting it. Rough shape:

import { marked } from 'marked';
import { sanitizeHtml } from '@/lib/security/sanitize';

export function renderPostBody(markdown: string): string {
  const raw = marked.parse(markdown, { async: false }) as string;
  return sanitizeHtml(raw);
}

The component layer renders that with dangerouslySetInnerHTML, and a .blog-prose
style block (semantic tokens, table overflow handling for narrow screens) keeps the
typography looking like the rest of the site.

next-mdx-remote and remark-gfm left package.json the same day.

Three gotchas from the migration

1. Sanitizer allowlists eat attributes silently. Our sanitizer stripped unknown
attributes, and rel wasn't on the allowlist — so the transform adding
rel="noreferrer" to external links ran, and then the sanitizer stripped it right back
off. If you sanitize, audit the allowlist against the transforms you actually apply.

2. Soft 404s hide behind optimistic UI. While testing the migration we found retired
blog URLs were rendering the not-found page with a 200 status. The culprit was a
locale-level loading.tsx boundary that swallowed notFound() semantics. If a URL
should be gone, verify it returns a real 404 — not a friendly page with a 200.

3. Test on the runtime you ship. The entire class of bug disappears if your CI or a
pre-deploy step runs a smoke test on the actual Workers runtime (or wrangler dev with
the Workers-compatible mode). next dev on Node proves nothing about EvalError.

When you should keep MDX

To be clear: if your content genuinely embeds React components, MDX is the right tool,
and there are compile-at-build-time approaches that work on Workers. The mistake wasn't
using MDX — it was shipping a runtime compiler for content that never used the
compiler's features.

The rule we took away:

Ship a parser for content, a compiler only for code — and know which one your
dependency actually is.

The blog this fix landed on belongs to Christmas Photo AI
— turn one photo into a private AI Christmas portrait in about two minutes. First
portrait is free.

Your MDX Blog Will Throw EvalError on Cloudflare Workers. Here's the Fix.

Mr.Rain — Sun, 01 Nov 2026 08:02:31 +0000

Our bilingual product blog had a bug that never appeared locally, never appeared in
next build, and turned every blog post into an HTTP 500 in production — on exactly one
runtime. The error:

EvalError: Code generation from strings disallowed for this context

The bug that only exists in production

Why Workers disallow it

So the 500 was correct behavior. Our dependency was doing the one thing this runtime
refuses to do — at request time, in production only.

The audit that made the decision easy

Before choosing a replacement, we asked a simpler question: do we actually render any
MDX?

That reframed the fix from "find an MDX compiler that works on Workers" to "use a
markdown parser." Which is a much smaller problem.

The fix: marked + sanitize + one CSS block

We switched to marked — a pure parser, no code generation —
and ran its HTML output through a sanitizer before injecting it. Rough shape:

import { marked } from 'marked';
import { sanitizeHtml } from '@/lib/security/sanitize';

export function renderPostBody(markdown: string): string {
  const raw = marked.parse(markdown, { async: false }) as string;
  return sanitizeHtml(raw);
}

next-mdx-remote and remark-gfm left package.json the same day.

Three gotchas from the migration

When you should keep MDX

The rule we took away:

Ship a parser for content, a compiler only for code — and know which one your
dependency actually is.

The blog this fix landed on belongs to Christmas Photo AI
— turn one photo into a private AI Christmas portrait in about two minutes. First
portrait is free.

What's the Average Reading Speed? 238 WPM, and How to Measure Your Own Honestly

Mr.Rain — Tue, 20 Oct 2026 08:52:33 +0000

Quick answer before any code: the average adult reading speed in English is about 238 WPM for nonfiction, 260 WPM for fiction, and 183 WPM reading aloud — from a 2019 meta-analysis of 190 studies. If your homemade WPM meter says you read 600, the meter is more likely broken than you are exceptional. This post covers what the benchmark actually measures, the three ways reading-speed tools lie, and how to build an honest one in a few dozen lines.

Where the 238 WPM number comes from

In 2019, Marc Brysbaert published a meta-analysis of reading-rate research in the Journal of Memory and Language — 190 studies pooled into reference numbers per reading mode:

Reading mode	Average pace	Why it differs
Silent reading, nonfiction	238 WPM	Reading for understanding — the default "reading speed"
Silent reading, fiction	260 WPM	Predictable narrative carries the reader
Reading aloud	183 WPM	Speech production caps the pace

Two properties of these numbers matter for how you use them:

They are population medians with wide spread, not thresholds. Plenty of healthy adults sit below or above with full comprehension.
They are mode-dependent. Quoting "the average reading speed" without the mode and material is like quoting "the average HTTP response time" without mentioning which endpoints.

If you want the full breakdown — age curves, the fiction/nonfiction split, and why Chinese reading speed is a different metric entirely — the full benchmarks article breaks it down.

The three ways WPM meters lie

I've benchmarked a few reading trackers, and nearly every wrong number traces back to one of three bugs:

1. Wall-clock time. The timer runs while you're answering Slack. Your "reading time" inflates, your WPM deflates, and nobody notices. Fair measurement counts active visible reading time — pause the clock when the tab loses focus or the user stops scrolling. This is the single biggest error, and it's pure code.

2. The stopping-point assumption. Dividing total word count by elapsed time assumes the reader finished. If they bailed at 40%, you're computing their speed over text they never read. Use the actual furthest position reached.

3. Segmentation. text.split(" ") is not word counting. It mangles punctuation, em dashes, and — completely — any CJK text. The same article counted by a regex tool and by a proper segmenter can differ by several percent. That's before we even discuss languages without spaces (more below).

Counting words the way browsers do

The platform gives you a proper tokenizer for free: Intl.Segmenter, which implements UAX #29 word boundaries — the same standard browsers use for double-click word selection. If it's good enough for text selection, it's good enough for a WPM meter:

const text = (await Bun.file("article.txt").text()).replace(/\s+/g, " ").trim();

const words = [...new Intl.Segmenter("en", { granularity: "word" })
  .segment(text)].filter(s => s.isWordLike).length;

const minutes = activeReadingSeconds / 60;
console.log(Math.round(words / minutes), "wpm");

Node 16+, all modern browsers, and Bun support it. isWordLike filters out whitespace and punctuation segments, so "state-of-the-art" and "don't" get counted the way a reader experiences them.

Counting active time like a benchmark study

The measurement-method section of the average-reading-speed research summary makes the same point the meta-analysis data shows: studies that time self-paced silent reading and count only real reading produce the trustworthy numbers. In the browser, that's a visibility listener plus an idle check, roughly:

let activeMs = 0;
let lastTick = performance.now();

document.addEventListener("visibilitychange", () => {
  // pause when the tab is hidden; reading stopped
});

setInterval(() => {
  const now = performance.now();
  if (document.visibilityState === "visible" && userIsReading()) {
    activeMs += now - lastTick;
  }
  lastTick = now;
}, 1000);

Divide segmenter-counted words by that number, and your meter stops lying. One more honesty rule from the research playbook: treat results under ~60 seconds or under 80% completion as low-confidence samples, the same way you'd distrust a benchmark that exited before the warmup finished.

If you read Chinese or Japanese

Then "words per minute" is the wrong unit, and no conversion factor fixes it. Chinese-primary text is measured in CPM — characters per minute, counting Han characters and excluding punctuation and whitespace. Japanese similarly counts Han characters plus kana. A property test for your counter:

function countHan(text: string): number {
  return (text.match(/\p{Script=Han}/gu) ?? []).length;
}

The key discipline is separation: WPM for space-delimited languages, CPM for Han-script languages, and never a fixed ratio between them. Comparing your English WPM to a Chinese CPM number is a category error, not a stat difference. The benchmark guide covers the CPM side in detail.

So what's a good reading speed?

The engineering answer: there is no SLA for reading. 238 WPM on typical nonfiction is the reference point, not the bar — a dense spec read at 180 with full comprehension beats a 400 WPM skim you can't recall. The useful "benchmark" is a personal baseline: same kind of text, same purpose, honest active-time measurement, tracked over weeks. If you want to see where you stand against the research numbers — one unpaced read of a reviewed article, no sign-up, quiz optional — the full guide and test are here.

FAQ

Is 200 WPM slow?
Slightly under the nonfiction average and, on its own, meaningless. On dense material with strong comprehension it's a healthy result. Compare sessions on similar material before worrying.

Why is my tracker's number 40% lower than the average?
Almost always wall-clock time or pause handling. Fix the measurement before concluding anything about your reading.

Can I trust speed-reading tools claiming 1,000+ WPM?
The reading research reviewed in the meta-analysis doesn't support dramatic multipliers: past roughly twice the average pace, comprehension degrades faster than speed improves. Skimming is real; "full-comprehension 1,000 WPM" is not.

Cross-post note: this summarizes research written up in full at LumenRead's average reading speed guide — that's the canonical version if you want to cite one link.

Validate LLM Output: Catching AI-Invented Emoji

Mr.Rain — Wed, 07 Oct 2026 13:30:20 +0000

If an LLM generates structured output for your product, any string it emits can be fiction, and "looks right" is not validation. On my site emoji-combos.net, a language model drafts decorative emoji combos for bio text, and it kept producing emoji that don't exist in the Unicode standard: valid-looking sequences that no platform actually supports. The fix is deterministic and cheap: a Set of every real emoji sequence, Intl.Segmenter to split strings into user-perceived characters, and a pipeline that fails closed when validation rejects too much. This post walks through all three, with the code.

We'll cover:

Why LLMs hallucinate emoji (and why a better model is not the answer)
Why [...str] and str.split('') break emoji, and the correct segmentation
Building the ground-truth dictionary from Unicode's official data
The full validator: skin tones, ZWJ sequences, invisible characters
Pipeline policy: batch minimums, dedupe, fail-closed behavior
Two gotchas that cost me an evening each

The stack is TypeScript, but nothing here is stack-specific. The concepts port to Python, Go, or wherever your AI feature lives.

The feature and the lie

The pipeline behind this is deliberately boring. When a visitor searches a "vibe" the site hasn't curated, the server calls an OpenAI-compatible chat endpoint (DeepSeek in production, any /chat/completions provider works) with JSON mode on:

response = await fetch(`${base}/chat/completions`, {
  method: 'POST',
  headers: { authorization: `Bearer ${key}` },
  body: JSON.stringify({
    model: 'deepseek-chat',
    messages: [
      { role: 'system', content: SYSTEM_PROMPT },
      { role: 'user', content: `Generate 10 emoji combos for the vibe ${JSON.stringify(query)}.` },
    ],
    response_format: { type: 'json_object' },
    max_tokens: 4000,
    temperature: 1.2,
  }),
  signal: AbortSignal.timeout(20_000),
});

The system prompt asks for {slug, name, description, combos[]}: ten short decorative strings for social bios. Temperature runs at 1.2 because variety is the product.

And the model lies. Not always, and less with each model generation, but reliably enough that shipping on vibes alone is malpractice. The lies take a specific shape: emoji-shaped sequences that aren't in the Unicode standard. A "family" with zero-width joiners in the wrong order. A skin-tone modifier glued to a base that doesn't accept one. Two emoji fused into something no consortium ever approved.

This isn't a malfunction. An LLM predicts plausible token sequences; a plausible sequence that's fake is a successful prediction by its own lights. Emoji make the problem unusually crisp because validity has a public ground truth: Unicode's emoji-test data defines exactly which sequences are real. That turns "is this AI output acceptable?" from a judgment call into a lookup.

That's the position you want to be in with any AI feature. A registry exists for your domain (Unicode, IANA, ISO codes, your product database), so the model proposes and the registry disposes.

Step 1: Split strings like a human sees them

Before validating anything, you need the right unit. This is where nearly everyone starts wrong, including me.

Emoji are multi-code-point. A family emoji like 👨‍👩‍👧‍👦 is man + ZWJ + woman + ZWJ + girl + ZWJ + boy, where ZWJ (U+200D) is an invisible joiner. The two classic JavaScript string-splitting idioms both operate below that level:

// Splits by UTF-16 code units: destroys ANY emoji with a surrogate pair
const byCodeUnit = '🎀🫧✨'.split('');

// Splits by code points: keeps solo emoji, SHREDS joined sequences
const byCodePoint = [...'👨‍👩‍👧‍👦'];
// ['👨', '\u200D', '👩', '\u200D', '👧', '\u200D', '👦'] — 7 fragments

Code-point splitting sounds like the fix and demos fine on 🎀. Then it quietly dismantles every ZWJ sequence into components that are individually valid emoji but collectively wrong, and your validator flags good output as garbage (or worse, passes fragments through as "known" and reassembles nonsense).

The correct tool is Intl.Segmenter, which has been baseline in Node and browsers for a while now and asks the platform's own ICU for user-perceived characters:

const segmenter = new Intl.Segmenter('en', { granularity: 'grapheme' });

export function splitGraphemes(content: string): string[] {
  return [...segmenter.segment(content)].map((s) => s.segment);
}

splitGraphemes('🎀👨‍👩‍👧‍👦✨');
// ['🎀', '👨‍👩‍👧‍👦', '✨'] — 3 units, family intact

One API call, and the unit of validation matches the unit of meaning. Everything downstream now operates on graphemes, never on spread results.

If you're in Python, the equivalent is grapheme or a regex with \X. The language doesn't matter; the principle does: validate at the granularity your user perceives, or your checks measure the wrong thing.

Step 2: Build the dictionary from the source of truth

Unicode publishes the complete list of valid emoji sequences in the emoji-test.txt file. Every line describes one sequence the standard considers fully-qualified emoji. That file is your registry.

I wrote a small import script that parses it into a JSON array of sequence strings, checked into the repo as src/data/emoji/sequences.json, 3,564 of them at the time of import. Regenerating is one command when Unicode ships a new revision.

At runtime it becomes a Set, because membership checks are O(1) and the whole thing fits in memory comfortably:

import sequences from '@/data/emoji/sequences.json';

const KNOWN_SEQUENCES = new Set<string>(sequences);

Three properties of this approach deserve emphasis:

It's complete by construction. Whatever the model invents, if it isn't in the file, it isn't an emoji. No fuzzy matching, no embedding similarity, no second model scoring the first.
It's auditable. When validation rejects something, "why" has a one-line answer: not in Unicode's list. Try getting that clarity from a moderation model's score.
It's swappable. New Unicode revision → re-run the import. The validation contract never changes.

Note what we did not do: ask the LLM to "only use valid emoji" harder. Prompt constraints are suggestions; a Set.has() is a fact. Use prompts to steer quality (variety, style, tone) and code to enforce correctness. Conflating the two is how teams end up with prompt paragraphs doing a schema's job.

Step 3: The validator

Here's the whole thing, lightly trimmed from production:

// Skin tone modifiers are valid components, but only glued to a person emoji.
// Matching the tone-stripped form covers every mixed-tone combination
// (🧑🏻‍🤝‍🧑🏿) without enumerating hundreds of variants.
const TONE_MODIFIERS = /[\u{1F3FB}-\u{1F3FF}]/gu;
const EXTENDED_PICTOGRAPHIC = /\p{Extended_Pictographic}/u;

// Zero-width and bidi control characters are never legitimate in a combo:
// platforms use them for mention/tag injection tricks.
const INVISIBLE = /[\u{200B}-\u{200F}\u{202A}-\u{202E}\u{2060}-\u{206F}\u{FEFF}]/u;

const segmenter = new Intl.Segmenter('en', { granularity: 'grapheme' });

export interface ComboValidationResult {
  /** Graphemes that are emoji-like but not in the official dictionary. */
  invalidEmoji: string[];
  /** Zero-width / bidi control characters are present. */
  hasInvisible: boolean;
}

export function isKnownEmoji(grapheme: string): boolean {
  return KNOWN_SEQUENCES.has(grapheme)
    || KNOWN_SEQUENCES.has(grapheme.replaceAll(TONE_MODIFIERS, ''));
}

export function splitGraphemes(content: string): string[] {
  return [...segmenter.segment(content)].map((s) => s.segment);
}

export function validateComboContent(content: string): ComboValidationResult {
  const invalidEmoji = new Set<string>();
  let hasInvisible = false;

  for (const grapheme of splitGraphemes(content)) {
    if (INVISIBLE.test(grapheme)) {
      hasInvisible = true;
    }

    // A cluster built only from tones is junk: presentation needs a base.
    const toneStripped = grapheme.replaceAll(TONE_MODIFIERS, '');
    const toneOnlyCluster = toneStripped !== grapheme && toneStripped.trim() === '';
    const looksLikeEmoji = EXTENDED_PICTOGRAPHIC.test(grapheme) || toneOnlyCluster;
    if (looksLikeEmoji && !isKnownEmoji(grapheme)) {
      invalidEmoji.add(grapheme);
    }
  }

  return { invalidEmoji: [...invalidEmoji], hasInvisible };
}

Four things are happening, and each one earns its keep:

Skin-tone stripping. A handshake between people with different skin tones is a single grapheme, but Unicode doesn't enumerate every tone mix in emoji-test. Stripping modifiers before the lookup collapses all variants onto a base sequence that is in the dictionary.

Extended_Pictographic as the "looks like emoji" test. The Unicode property \p{Extended_Pictographic} matches emoji-ish characters broadly, broader than the official emoji set. That asymmetry is exactly the hallucination signature: emoji-shaped, but not in the registry. Plain text (letters, digits, punctuation) fails the property and passes through for length/content rules elsewhere; fake emoji trip it and get checked against the Set.

The tone-only cluster guard. After segmentation, a cluster of only tone modifiers (sometimes glued to a stray space) is garbage with no base character. It doesn't match Extended_Pictographic on its own, so the explicit check catches it.

Invisible character rejection. Zero-width joiners, word joiners, and bidi controls are legitimate in some writing systems, which is precisely why they're a documented trick for splitting @mentions in pasted bios. For a site whose output gets pasted into profile fields on other platforms, this is a real attack surface, not paranoia. The regex rejects the lot.

Per combo, all of this runs in microseconds. The LLM call it guards costs five orders of magnitude more. Guard rails are cheap; use them everywhere.

Step 4: Pipeline policy, the part that makes it a system

A validator is a function. A pipeline is a policy about what happens to the function's answers. Ours, in production:

Request 10, require 4. Each generation asks for ten combos. If fewer than four survive validation, the entire batch fails. No "serve whatever made it." A 60%+ rejection rate means something upstream is wrong (bad prompt drift, a model regression), and shipping the survivors means shipping a biased sample of a broken process.

const valid = filterValidCombos(generated.combos);
if (valid.length < MIN_VALID_COMBOS) {
  throw new AiGenerationError('generation produced too few valid combos');
}

Dedupe at the database, not just in memory. The in-memory filter drops exact duplicates within a batch, but the model also regurgitates combos that already exist on a vibe. A unique constraint at the persistence layer is the last line of defense, and unique-violation errors during insert are tolerated as "already have it," not propagated as failures:

try {
  await repository.createWithTags({ combo: { /* ... */ }, tagIds: [tag.id] });
} catch (error) {
  // A combo that already exists must not sink the batch.
  if (!isUniqueViolation(error)) throw error;
}

Fail closed on the provider. No API key configured? The route returns 503 and the frontend shows its normal empty state. Provider down or timing out? Same. The failure mode of an AI feature should be "honestly unavailable," never "confidently degraded."

Cache past the model. Once a vibe has six approved combos stored, generation is skipped entirely for that query. The model is the cold-start path, not the hot path. (This also means validation made the feature cheaper: trustworthy stored output is worth serving, and serving it skips the expensive, hallucination-prone step.)

Human gate on permanence. Generated vibes are created as drafts, excluded from public listings and the sitemap until an admin promotes them from a review queue. The code validates correctness; the human validates taste (variety, on-theme-ness, non-cringe descriptions). Visitors who triggered a generation see their results immediately; only permanence is gated.

Testing the gate

The repo uses fast-check for property tests, and the validator is a property-test target from heaven: for any string, validation should never accept an emoji-ish grapheme absent from the dictionary. Sketch:

import fc from 'fast-check';

test('rejects every non-dictionary emoji-shaped grapheme', () => {
  fc.assert(
    fc.property(
      fc.array(fc.constantFrom('🎀', '✨', '🎃', '\u200D', '\u{1F3FF}', 'x'), {
        minLength: 1,
        maxLength: 20,
      }),
      (parts) => {
        const input = parts.join('');
        const result = validateComboContent(input);
        // Any emoji-looking grapheme in the result must be a known sequence.
        for (const g of splitGraphemes(input)) {
          if (/\p{Extended_Pictographic}/u.test(g) && !KNOWN_SEQUENCES.has(g)) {
            expect(result.invalidEmoji).toContain(g);
          }
        }
      },
    ),
  );
});

Generative testing shines here because the input space (all strings) is infinite and the property is crisp. It caught the tone-only cluster case during development, which I had not thought of manually.

Two gotchas worth your evening

JSON mode is not a fidelity guarantee. Even with response_format: { type: 'json_object' }, models occasionally wrap the payload in markdown fences or lead with a chatty sentence. Parse tolerantly: try JSON.parse on the trimmed body; on failure, slice from the first { to the last } and parse that. And validate the shape (string slug, string array of combos) before touching values, because payload.combos being null is not an exception until you make it one.

Reasoning tokens eat your completion budget. On some providers, hidden reasoning happens inside the same max_tokens budget as the visible JSON. A ceiling that's generous for ten emoji strings can be too small for ten emoji strings plus the model's private scratchpad, and the symptom is not an error but an empty completion, intermittently, which looks exactly like a network flake. If your structured calls come back empty on a reasoning-flavored model, raise the ceiling before you blame the network. (The system prompt in my pipeline also asks the model to reuse an existing vibe slug when the query is a synonym, "cute" vs "可爱", which cuts duplicate entities; canonicalization logic and JSON tolerance together mean the pipeline assumes the model is helpfully sloppy, never precise.)

Takeaways

An LLM's job is plausible output; your job is a truth source. Where a registry exists (and it exists more often than you'd think), validation is a lookup, not a model.
Segment with Intl.Segmenter before validating anything emoji-adjacent. [...str] silently destroys exactly the sequences most likely to be hallucinated.
Reject the shape mismatch: \p{Extended_Pictographic} matches but the dictionary misses. That's your hallucination signature.
Policy beats function: batch minimums, DB-level dedupe, fail-closed provider handling, cache past the model, human gate on permanence.

The site is emoji-combos.net; the AI-assisted search is worth a try, and the curated field guide is the human-picked counterpart. Questions, corrections, and stories of your own model's inventions: comments are open.

FAQ

How much latency does validation add?
Microseconds per combo. The expensive step remains the LLM call itself; the dictionary is a static Set, the segmenter is a platform API, and the regexes are linear scans over a few dozen graphemes.

What if Unicode publishes new emoji?
Re-run the import against the new emoji-test file and redeploy. The validation contract is unchanged; the dictionary is data, not code. Ship the data with the app (or load it at boot) so the runtime never depends on fetching it.

Does this work for non-emoji LLM output?
The mechanism generalizes to any domain with a canonical registry: check output against the registry at the unit users perceive, and reject on mismatch. The emoji-specific parts are the segmenter settings and the tone-stripping rule; everything else is domain-neutral policy.

Why reject the whole batch below four valid combos?
Because survivors of a bad batch are a biased sample, and "ship whatever passed" hides upstream regressions. A hard floor turns the rejection rate into an observable signal instead of silent quality decay.

Why not use a second model to check the first?
A second model has the same failure mode as the first: it predicts plausibility, it doesn't consult truth. Chains of models checking each other add latency, cost, and new hallucination surface, while a Set.has() is exact. Use models for proposal; use registries for verdicts.