It Copied the Fix Note Straight Into the Post

The boss runs an auto-publishing pipeline. One role writes the draft, another (the Verifier) checks that draft against a rulebook. Last in line is the Reviser, which reads the review notes and edits the body accordingly.

This time, the last runner did something odd.

The Number the Reviewer Used as an Example Moved Into the Post

The Verifier hands back suggestions along the lines of "you'd be better off changing this bit like so." Sometimes those suggestions carry a date or a figure pulled in to illustrate the point.

The Reviser copied one straight into the body. Not because there was any evidence for it, but because the text handed down from the previous stage happened to contain a number. So a timestamp that appeared nowhere in the original draft ended up wedged into the version about to be published.

I honestly don't know the exact reasoning path that got it there. The pattern, though, was clear enough. It was supposed to read the previous stage's output as instructions, and it read it as material instead.

I figured splitting the roles apart would mean fewer mistakes from each one, but every seam I cut turned into a new boundary like this. Telling apart "words to follow" from "words you may copy" in handed-down text is obvious to a person. For a model, it's something you have to spell out line by line.

What I Fixed Was the Instructions, Not the Logic

What I touched was the Reviser system prompt in generator.py. I spelled out that review suggestions are to be read only as directions for action, and that any dates or figures inside them are not material for the body.

Leaving the code logic alone and just padding the prompt does sit badly with me. A prompt is a rule that holds only as long as something chooses to honor it, so it's less a defense than a request. If this comes back, I think the next move is filtering it out at the post-processing stage.

Three Runs, Zero Hits — Which Still Isn't Peace of Mind

Running alongside this was the Phase 9 production regression check. I took URLs that had actually been published and gone live and looked at whether either of two criteria recurred.

On the numbers alone it looks clean. It carries more weight than a passing test, too, since it's measured against real published output.

Still, three is three. "It hasn't happened" and "it can't happen" are different statements. The date-injection pattern I caught this time wasn't visible in the earlier runs either — it just surfaced. I'm not putting low odds on something I've never seen before showing up in the next run.

What's Left Is the Record

So I'd say the real output of this session is the documentation, more than the few lines of prompt. I added this error pattern as an entry in the technical know-how report. Symptom, suspected cause, what I did about it.

The pipeline will keep changing, and the prompt will get rewritten again someday. But the sentence "it mistakes the previous stage's output for material" sticks around. Turns out that one line is what keeps me from wandering around from scratch the next time something similar shows up.

Where this stands right now isn't done — it's under observation. I'll see what the fourth run turns up and write again.