Claude watermarks in developer docs: keep the behavior exact

I judge developer documentation by what happens when somebody follows it. If editing makes a README easier to read but changes a promise about retries, the editing has introduced a bug.

Claude can help turn implementation notes into readable prose. A developer might also want control over the final wording and any statistical watermark left in that prose. My requirement for a second rewrite is that the described software must behave exactly as it did in the first version.

Does this apply to a README written with Claude?

Prose from a supported marking model can carry a watermark even when its underlying information came from your code or notes. Anthropic describes that limit on authorship in its help article.

The relevant part here is the explanatory text around the code. I would keep commands and configuration files out of a general prose rewrite. I would also keep exact identifiers in a separate record for the final comparison.

A helpful sentence can describe a different API

Here is a fictional piece of API documentation.

The client retries a request only when the response is 429 and includes a Retry-After header.

Compare it with this possible edit.

The client automatically retries failed requests using the server’s recommended delay.

The second sentence sounds ordinary, but it describes broader behavior. It could lead a reader to expect retries for errors that the first sentence does not cover. The header condition has also become less explicit. This is an illustrative pair, not a result produced by the tool.

I would check a rewrite for changes like these before worrying about how smoothly it reads. “Only” often carries a condition that the implementation depends on. So do words such as “before” and “unless”.

Standards make some of these distinctions explicit. For specifications using the RFC 2119 convention, MUST expresses a requirement, SHOULD allows justified exceptions, and MAY means optional. Replacing one with another changes the instruction. Ordinary README prose deserves the same care even when it does not use that convention.

What the rewrite experiment supports

In the reference-key study, the protected single-pass LLM workflow crossed below the threshold in 8/10 fresh responses on the original sources and 10/10 reports in the standard-order control. The original panel credited it with 100 selected claims; the follow-up review qualified that result. The current tool uses a separate multistage Qwen3.6 workflow. These research counts do not measure its success rate on your draft.*

*The test used fictional reports and a research watermark key. It did not test executable code, API compatibility or the private production detectors used by Claude and Gemini. The remover cannot certify their marks are gone or verify that documentation matches a repository.

The tool compares the rewritten text with the text supplied to it. It cannot infer the real implementation from a paragraph alone. If the source says the client retries every failure, the review may faithfully preserve that mistake. I would first check the source paragraph against the current code and tests.

A review that fits a repository

I would submit a complete prose paragraph, keeping fenced code blocks and literal configuration outside the input. Afterward, I would put the candidate back into the README and inspect the diff.

For behavior claims, I would compare the old and new sentences with the relevant implementation. A timeout must retain its unit. An optional setting must remain optional. An example that covers one platform must not become a claim about every supported platform.

I would run the documented example where practical. A clean text diff cannot prove that the command works, and a passing command cannot prove that the surrounding explanation is complete. Both checks answer useful questions.

The service also has an MCP server and API for a coding client. That can make the wording pass easier to request from the same workspace. I would still review the returned prose before accepting a patch; the integration does not give the service access to the repository’s truth.

Try a paragraph in the free watermark remover and keep the implementation open beside it. Accept the wording when its requirements and described behavior still match the code.