145 words shipped on inheritance tax. 949 words fixed it. The gate measured the wrong thing.

The IHT-rate article landed in the publish queue at 145 words. Not a stub — a draft that had survived two redraft attempts, cleared the Haiku extraction step, and passed the verifier. 145 words on UK inheritance tax rates: a YMYL topic where thin coverage isn’t just inadequate, it’s a net-negative authority signal. PR #156 shipped it. Shipping the thin version was correct; it made the problem legible.

Later that same session the article was 949 words. PR #157, same topic. That gap is what this post is about.

What the automated path does

The ukcalculators content pipeline runs on a cluster-then-extract loop. Haiku pulls claims from source URLs, the verifier checks each claim against its source, and the drafter assembles the passing sentences into an article. The intent is publishable, verifiable content without operator time.

On YMYL topics, the intent runs into a structural constraint. The verifier only passes what Haiku can match back to sources. If source density on a cluster is thin, or if Haiku claim-extraction is running under B-076 (the current unresolved extraction bug), the draft is whatever the verification layer permits. No more. T-004 was originally scoped as an NRB + RNRB explainer, position 11 in the topic-authority backlog. After two redraft attempts, what Haiku could extract verbatim was 145 words.

The pipeline had done its job. 145 words is what the job produced.

What 2026-06-29 and 2026-06-30 confirmed

Monday’s cron fired on-time at 07:00 UTC on 2026-06-29 and produced zero publishable drafts. Same structural cause: Haiku claim-extraction underfire on the one cluster that survived the ground stage. B-076 still open.

On 2026-06-30 the cron produced one draft. 10 of 13 sentences passing. The slug it chose was mortgage-abandoned-about-above; the title-mangling step is mid-fix, so the slug comes from the raw token stream rather than a normalised form. The draft is usable; the slug needs a manual override before it ships.

Two weekday cron runs: zero drafts, then one with a broken slug. That’s the automated path’s current ceiling under B-076. The bug is tracked.

What the operator path does

After PR #156 landed, CJ invoked ultracode to strengthen rather than revert. The workflow:

  • Six parallel URL scouts fetching from live sources
  • One synthesis agent processing the combined output
  • One Opus structure designer assembling the article

Result: 949 words. 26 sentences, all verified against source, verifier overall=pass. PR #157 merged same day.

The structural difference is what the scouts fetch. Automated extraction only works from the cluster the pipeline already holds. Scouts reach further. Raw material Haiku never saw means more verifiable claims, and a longer article that still passes the verifier. 145 words to 949 words is not editing; it’s a different evidence base.

That costs session time. The operator has to be present, scope the scouts, review the synthesis output. It isn’t automatable in the same sense as the cron. But on a YMYL topic where the automated path produces something net-negative, it’s the only path to a publishable article.

The second publish on the same day

The IHT-rate article was not the only publish on 2026-06-25. The second was UK Property Tax Reform 2026: council tax administration changes, mansion tax proposals, second-homes premium notice rules. CJ scoped it from a direct brief: “an article regarding the changes in government and the impact, especially with the removal of council tax.” CJ then researched the full topic scope directly. Operator-invoked from a brief rather than rescued from a thin automated draft, but the same operator path.

Two publishes in one session: one rescued, one fresh. Neither would have come from the 07:00 cron that day.

What the tradeoff is

The pipeline has two operating modes. They have different cost profiles and different output ceilings.

Automated: Haiku cluster → extract → verify → draft → publish. No operator time. Works when source density is high and B-076 isn’t degrading extraction. Thin on YMYL topics; adequate on informational ones with dense clusters. One draft per weekday on a good day, zero on a bad one.

Operator: Brief or rescue → ultracode scouts → synthesis → Opus design → verify → publish. Requires session time. Produces 900+ words with full citation coverage. Mandatory on YMYL topics where automated extraction yields sub-200-word drafts.

These modes are not in competition. Operator mode is the fallback when automated produces something net-negative, and the primary path when a topic requires depth from the start. The output of the automated draft makes the routing decision: sub-150 words on a YMYL topic means operator path; adequate verified article means ship it.

The constraint on operator mode is not the pipeline. It’s session availability. Two publishes in one session is the ceiling, and that’s what 2026-06-25 showed. On days when the session is not open, the cron is the only path, and under current B-076 conditions that means one draft, maybe, with a slug to fix manually.

What’s not yet built

The pipeline knows which cluster it’s working from. It does not know whether that cluster will yield enough verifiable claims to pass the YMYL bar before it attempts the draft. Discovery currently happens at publish time: you ship the thin draft, then decide to strengthen. That’s one extra step per YMYL article that a pre-draft density check could eliminate.

The routing decision, automated or operator, is currently made by inspecting what the automated path produces. Ideally it happens before extraction runs. A source-density estimate on the cluster before the Haiku step: enough coverage, proceed automatically; below threshold, flag for operator rather than generating a thin draft that needs manual rescue. PR #156 was avoidable. Not because the pipeline did something wrong, but because the pipeline had no signal that it was heading for a net-negative result until it arrived there.

That’s the routing layer. It’s not urgent. But the 2026-06-25 sequence made the cost of not having it visible.

Where the cadence clock sits

The fresh 14-day cadence clock started 2026-06-29. Day 1: two operator-path articles, T-006 (60% tax trap) and T-029 (Mortgage Guarantee Scheme 2025). Day 2: one cron draft with a slug to fix.

The cadence target is achievable. Fixing the slug and closing B-076 removes two known friction points. Beyond that, the pre-draft density check is the next architectural question worth raising.

The devlog has the daily record. This post is the pattern that sits above it.

All writing