We never wrote our format down, so it took our old drafts as the spec

The thing sat in front of me for a couple of extra seconds before I sent it. What I was looking at was the date field.

It said "Wednesday".

That is how our team writes dates. For a job scheduled by the day we never write the month and the date; we write the weekday, because then how many days are left is right there and nobody has to do the subtraction. It is a provincial habit. Nobody thought it was worth explaining to anyone, and nobody had ever said it to the thing.

I had handed the job over a little past ten at night. Opened it in the browser, pasted a few pages in, said one sentence: needed by morning, one page, not too stiff.

The pages were ones I had stitched together myself. A stretch from here, a stretch from there, and in the middle two lines written to a colleague that I never deleted. Pasting them in I felt a small unease. This messy — it will probably ask.

It didn't ask.

The first pass I put down to coincidence. The document was about that Wednesday. Writing "Wednesday" was not evidence of anything.

So I checked the names. A handful of clients, a handful of ways we call them, not one of them off — including the one we ourselves keep writing in the wrong order.

Then I read the page again from the top. How the unfinished items were marked. Which sentence came before which. Those were in our places too, and that is harder to explain away. It was like someone took an old draft of mine, copied it out, and copied it cleaner than I do.

Which means the interesting question is not whether it got lucky. It is where the rule came from, because we never typed it.

What was actually in the input

I dug out what I had pasted that night. Not much. The previous one-pager, which we wrote. A few lines of instruction. And a note copied over from a chat log, half-coherent, messy enough that I had winced at it while copying.

"Wednesday" was in there. The names were in there. The note was in there too.

Put those pages beside what came back and what it did is plain: we never gave it a style guide. We gave it a pile of our own old writing, and it used the pile as the ruler.

This is the part I want to write down properly, because it is a small engineering event that happens quietly and then never gets discussed.

An example is a specification you did not write

In ordinary software the spec comes first. Somebody writes down what the output should look like, the implementation is checked against it, and when they disagree you go and read the spec.

Here the order was reversed. The artifacts came first — they existed because we had been doing the work for years — and the rule was derived from them at the moment of use. Nobody wrote it. Nobody reviewed it. It has no version number and no owner, and it is nonetheless being enforced, accurately, on every job.

Anyone working with these models does a deliberate version of this every day: you show a couple of examples and ask for the same shape back. The difference is that we did it by accident, with dirty material, and the material was our own past output rather than something we had cleaned up for the purpose.

There is a real distinction hiding in that, and it survives outside this particular tool.

An instruction is a claim. It can be short, but it is made of words someone chose, and you can argue with it: you said the dates should be weekdays, this one says 21 October. An example is a sample. You cannot argue with a sample. You can only be consistent with it, or fail to be. When a system derives its rules from examples, the rules are as good as the examples and as visible as the examples — which is to say, exactly as visible as the pile of paper you happened to paste in.

Ours was not a clean pile. It had two lines addressed to a colleague in the middle of it, an unfinished thought, a note whose beginning did not connect to its end. It generalised over all of that anyway, because the noise was not noise to it. It was more evidence about how we write.

What it could see, stated precisely

There is a precondition that makes the rest of this falsifiable, so it belongs in the middle of the post rather than in a footnote.

It does not read the things on our computers. The old drafts, the folder that keeps thickening, the several versions we later put on a drive — it can see none of them. All it has is words: what we pasted in this time, plus what we said over the previous handovers.

So everything it knows is something we wrote or said ourselves. It was not being clever and it did not peek. It took what we had written and treated it as what we are like.

That bound matters for a practical reason. If it had produced a rule we had never displayed anywhere, that would be a different and much stranger claim, and I would not believe me either. Every rule it followed was visible in the material we handed over. What is surprising is not the source of the information. It is that a pile of old output was enough to reconstruct a style nobody had ever articulated, including the parts we would have got wrong if we had tried to write them down.

The paragraph that stopped being written

We had always assumed we had no fixed style. Lay the pile out and it is plain that we do have rules: dates as weekdays, clients under the name we call them, unfinished items marked with that one sign, the soft sentence first. None of those rules is in any document. Not one was agreed in a meeting. They came out of doing the work and they smoothed over with use.

What changed is on the handover end.

Handing over a job, I used to add a paragraph at the end: same format as last time, dates as weekdays, don't change our names. Forty words, written fluently, eyes closed, every single time.

Now that paragraph often will not come. What would I write? Last time it already came that way.

So we save a few dozen words per job. That is the visible number, and it looks like the whole story: less instruction, same output, nothing else moved.

The invisible half is that the paragraph was also the only written record of the format. It was the one place where our house style existed as a sentence a person could read, quote, and disagree with. We deleted that copy one handover at a time, and nothing broke, which is exactly why nobody noticed. If you asked me right now to hand you a page listing everything we have taught it about our writing, I could not. The corrections are not stored as a document. They are stored as behaviour.

The test we did run

Two more jobs went through after that one, unrelated to it. The date field still said "Wednesday"; the unfinished items still carried the same mark. No drift, at least not on the surface.

I also tried changing it once, swapping "Wednesday" for "October 21". Two lines in, I changed it back. Things that fit the hand do not move. Read that honestly and it is not a story about the tool. It is a story about us: the standard survived because it was ours, and the only reason it is still standing is that nobody has yet had a reason to want a different one.

Which is fine until the day we do. Then the change has to be argued against a rule that is not written anywhere, by someone who cannot see it, in a document that only exists as the shape of the last thing that came back.

If you are building something that accepts pasted work

Four things I would want to know before shipping this, in rough order of how much they would have saved us.

Decide whether the schema by precedent is intended. If your product accepts pasted artifacts, and something downstream infers rules from them, then your real schema is the artifacts. That can be the feature. It should not be the accident.

Build the render, not the log. A log tells you what was said and in what order. It does not tell you what the system currently believes. Those are different objects, and the second one is the one a person can review. The cheapest useful version is a view that answers "given everything so far, what would it do with this job now" and expresses it in sentences someone could disagree with.

Test with a job from a different drawer. Rules derived from examples travel. Ours went from a one-pager to an outline and a set of instructions without anyone asking whether it should. The check is not whether the next similar job comes back right; it is whether an unrelated job comes back unmarked.

Measure words saved, but price them honestly. Saving forty words a handover is real and it compounds. The thing you spend is reviewability, and it does not appear on any dashboard, because nothing fails. You just slowly stop being able to say what your own standard is.

Where this sits

CloudPal runs long jobs in the cloud and hands back a finished document. Nothing to install, nothing asked of your computer, nothing read from the files you already keep — it works from what you give it, in words. You describe the job the way you would describe it to a colleague: badly, out of order, including the thing you only remember on the second telling.

It is in limited preview. New accounts get a dollar of credit, enough to run something real, and the number of new accounts per day is capped. It costs a few times less than the comparable tools and you pay for what you use.

The uncomfortable part is not that it copied us. It is that it copied us accurately enough that we stopped saying what we wanted. That trade is worth making — the output is better than what our own instructions produced — but it should be made on purpose, by someone who knows the paragraph they are about to stop writing was the spec.

CloudPal.TuringCorp.net — create an Agent Pass, sign in, and say what you want done.

Earlier in this series: it guessed a number, we told it off, and every number after that got checked, correct is a low bar, the same three facts, in a different order, the second half of the draft was policy we never agreed to, it can't read anything on my laptop, a direction is not a spec, four sentences in, seventeen pages out, the requester is not the reader, the first run is a demo, the ninth is the product, the meter, not the price, we deleted the install step.