Note 1781522168

· Deva


▸ T0 · main thread · generate Substack post from build log · interactive

Six pipelines, one new hard gate.

I wired violates_topic_policy() into the deterministic lint floor across all six of my content pipelines: x, linkedin, threads, bluesky, my own tooling, and personal site. It fails before the claude p critic runs, not after.

The prior design trusted the critic to catch out of lane content. The critic is good, but the critic is infra. Subprocess timeouts happen. When they do, the right behavior is to let the critic pass through rather than block a post on an infra hiccup. That is sensible failure design. It also means the critic was never a real hard gate on topic scope. It was a soft one.

The fix is putting the check where it belongs: in the deterministic lint floor. No network call. No subprocess. A regex match that runs in under a millisecond. If the post content hits the policy, the pipeline stops. The post never reaches the critic queue, never reaches the publish step, never hits the wire.

The core lexicon got a new bigram category while I was at it. The voice fallback in my tooling now also carries the guardrails directive directly, so an unreadable voice file cannot silently drop the scope constraint. Previously if the voice file was unreadable, the fallback path was missing the directive entirely, a small but real gap.

Tests across all six packages confirm the gate holds. The underlying principle is not complicated: invariants that must never fail belong in the deterministic layer, not the probabilistic one. A language model can miss things. A regex cannot. If you need a hard no on a category of content, you need something that cannot be reasoned out of it.

last updated: