Consumer Rights Wiki talk:AI usage policy

On a disclosure requirement, from someone who would have to comply with it

I should declare an interest before saying anything: I use AI assistance, and my recent edits to Capability gating, Format abandonment, Region locking and Sony BRAVIA pre-Android Linux TVs (2011-2012) were written that way, under my direction and checked by me. It would be strange to argue in this thread without saying so.

My reason is the one this policy already anticipates. English is not my first language. Left alone I write English that would embarrass an article, and the policy is right that assistance can be an improvement over the alternative. What I bring is the research, the hardware, the sources and the judgement about what belongs in an article; what I get back is help saying it in English that does not need cleaning up after me.

On the substance: I think a disclosure requirement is a good idea, and I would comply with it gladly, but I would not expect it to do much about slop. Someone who pastes output without reading it is not going to write an honest edit summary about it. Disclosure is a rule that lands on the people who were already being careful. That is not an argument against it, honesty has its own value and it lets a reviewer calibrate how hard to look, but it is worth being clear about what it buys.

What actually catches bad edits is the checklist already in the policy, and it catches them whoever wrote the text. Two examples from my own recent edits, both failures on my side rather than successes:

Three of my citation templates had line breaks inside them. A reviewer had to repair one by hand on Capability gating before I noticed and fixed the other two myself. That is exactly the "return characters" artefact listed here under revert on sight, it came from my drafting process, and no disclosure rule would have caught it. Reading the rendered page would have, and now does.

A reviewer tagged a quotation of mine with {{Citation needed }}. I asked a model whether the phrase was in the cited article and it told me yes, while quoting back slightly different words with the key part in brackets. That is the shape of a fabricated confirmation. I fetched the raw page and searched it myself, and the quote was genuinely there word for word, so the ref is now attached to the article that carries it. The point is that the model's confirmation was worthless either way. "Examine the content of every link or reference found using AI" is the single most valuable line in this policy, and it deserves to be read as "do not let the tool mark its own homework".

Some evidence rather than argument, from outside the wiki. I have sent the same kind of work to three software projects this month, carrying the same disclosure in every commit, and the outcomes have not tracked the disclosure at all. HandBrake merged a patch of mine 81 minutes after I opened it, on 16 September, reviewed on the code. MKVToolNix is reviewing two merge requests from me as I write this; the maintainer opened with "most of it is exactly the way I'd want it", gave me seven technical requests about array layout, function naming and where a call belongs, and has said nothing at all about how the code was written, although every commit message states it plainly. mpv is the awkward one. My pull request there is open and parked, and the day after I disclosed the assistance a maintainer landed a rule banning mentions of LLMs in commit messages. I am not complaining about that, it is their project and the rule is narrowly scoped, but the practical effect on me is that the honest disclosure is the part that has to be removed, while the patch itself is unchanged and still sitting there. Three projects, one contributor, one practice, three different results, and none of them agreed, but the ones that matter are the ones that were decided by the quality of the work.

So my suggestion, for whatever it is worth as a newer editor here: if disclosure is adopted, keep it simple and keep it non-punitive, so that saying "AI assisted, sources checked by me" in a summary is never worse for you than saying nothing. And keep the weight where it already sits, on the checklist and on reversion when the work is bad. An article is right or wrong, sourced or unsourced, readable or slop, and all four of those are visible in the diff without anyone having to guess how it was made.

One last thing I would gently push back on, as someone whose edits will be read with suspicion: please do keep the warning about edge cases that is already in the "common signs" section. The listed tells are real, and I follow them as a checklist against my own drafts, but they describe careless writing more than they describe a tool. A confident editor with a fondness for bold text and em dashes has been getting away with it here for years, and a careful one using assistance can produce something indistinguishable from any other good edit. Judge the edit. Capitain Jack (talk) 15:13, 20 September 2026 (UTC)

== PS: the other half of the same problem ==

A practical note that came out of the citation work rather than out of any argument. While replacing the Wikipedia citations on the three theme articles, following the example a reviewer had already set on Capability gating by swapping one for a real source, I kept a list of what I ran into. It is offered here because it is useful to anyone sourcing on this wiki, and because it bears on the section above.

Russian Wikipedia contradicts itself about the Soviet Stereo-70 system. The general article on stereo cinematography dates it to 1963; the article dedicated to the system itself says it was completed in 1965 with films from 1966. Two human-written articles, same wiki, disagreeing with each other, and neither flagged.

The two organisations that created and administered DVD region coding are both off the web. dvdforum.org no longer resolves in DNS at all, and dvdcca.org presents a broken certificate. I wanted a primary source for a claim about a DRM scheme and found that the primary sources have evaporated, which is why that citation now points at a technology explainer instead.

A manual link I was checking returned HTTP 200 while silently redirecting to a corporate home page with no product content behind it. It reads as a live link in every automated check that only looks at the status code.

Sony's support pages carry up to 1918 model-number strings each, from three unrelated sources on the same page: a published list of affected models, a metadata array of which product pages the article is attached to, and a site-wide catalogue behind a "type your model number" search box. I came close to publishing 367 models as Sony's own affected list when it was the contents of a search widget.

None of that was produced by AI. It is ordinary information rot, made and maintained by people, and the checklist in this policy is what caught all of it.

The historical point is worth making once, because it is easy to assume this problem arrived with the current tools.

In October 2020 the Hacktoberfest promotion offered a t-shirt for four pull requests. By DigitalOcean's own published recap, the result included 34,595 pull requests accepted by no maintainer, 9,598 labelled spam or invalid, 172,599 aimed at repositories that had not opted in, and 17,260 at repositories excluded for not matching the event's values.

The rules were changed to opt-in partway through.

No language model was involved in any of it.

The largest slop event open source has suffered was produced entirely by humans, and it was motivated by a t-shirt.

That is also where machine slop comes from. These models were trained on human writing, including human padding, human hedging and human false confidence. Wherever one of them produces slop, a person wrote that slop first and the machine is repeating it faster. Low information density, unverifiable claims and volume without checkable content are not new properties, and they are not properties of a tool.

So one small suggestion, and it is a naming change rather than a policy change. The section titled "common signs of AI writing" is accurate about what it lists, and I use it as a checklist against my own drafts, but every item on it describes careless writing rather than a particular author. Over-bolding, fluffy comparatives, indicator words and sources given in parentheses without a URL were all human habits first, and they are still mostly human in practice. Read as "common signs of careless writing" the same list catches strictly more, it stops being a claim about who wrote something, and it no longer needs the caveat about edge cases, because nobody is insulted by being asked to write carefully.

Everything else in the policy already does the work. The checklist tests the artefact, and an artefact is either checkable or it is not. Capitain Jack (talk) 15:30, 20 September 2026 (UTC)

"Signal flare" requirement

So lately we have been experiencing some users using LLM powered agents to handle automating tasks on the wiki. While the work that they are doing is great and all, we severely need to append the policy for LLM-powered automation, so that we don't have to deal with a large block of edits being made with errors that are difficult to manually patch.

Simply put, set up a requirement for any sort of automations to send off a signal flare with as many edge cases tested as possible before being left to run.

I do believe we could use a better phrasing for the rule, though. JamesTDG (talk) 18:08, 20 September 2026 (UTC)

I am one of the people you are describing, so let me declare that before anything else. My recent edits here were made through the wiki's API with a small client I wrote, and they were AI assisted. I support this rule and I would be glad to be bound by it.

On phrasing, since you asked. I think the rule is stronger if it asks for three separate things, because they fail in different ways:

Announce before the run, not during it. Say on the talk page of the affected article, or on a noticeboard for anything wider, what the automation will change, roughly how many pages it will touch, and what you tested it against. The point of announcing beforehand is that someone who knows the articles can say "not that one" while it is still cheap.

Separate the two moments, because they fail in opposite ways. Creating a page and maintaining one are not the same job and should not carry the same rule.

Creating a page. Draft it offline, in full, and publish it in a single save. A new article assembled from twenty incremental saves floods recent changes, buries its own history under noise, and gives a reviewer no one version to read. Publishing once also forces the author to finish thinking before they publish, which is most of the benefit.

Editing an existing page. Here the opposite applies. Small separable edits, each doing one thing, with a summary saying which thing. A hundred changes in a single diff cannot be reviewed and cannot be partly reverted, so a reviewer who finds one error has to choose between keeping the rest or discarding all of it.

Land a small batch first and stop. For anything running across multiple pages, five or ten edits and then wait. A reviewer can inspect ten in a few minutes and tell you your citation template renders wrong, which is a much better outcome than discovering it on page two hundred. I would rather this were a hard number than "as many edge cases as possible", because an operator's idea of an edge case is exactly the thing that is unreliable here.

Verify each write against what the wiki actually holds. This is the one I would most like to see written down, because it is cheap and it catches the failure you are describing at the moment it happens. After every save, fetch the page back and compare it to what you submitted. My own client refuses to report success unless the returned text matches byte for byte, and that check has caught things I would otherwise have left behind, including a template that looked fine in my draft and rendered broken on the page.

Two smaller suggestions. One edit per logical change with a summary that says what it was, so that a revert can be surgical instead of wholesale. And an explicit line that the operator patches their own errors rather than leaving them for the community, since "difficult to manually patch" is the actual harm in your first paragraph and it is worth naming as the operator's responsibility.

A rough wording, to be pulled apart rather than adopted: "Before running any automated or semi-automated series of edits, announce it in advance with what it will change and what it was tested against. Create new pages offline and publish them in a single save. Make later changes as small separable edits, one logical change each, with a clear summary. Where a run spans several pages, publish a small initial batch and pause for review. Verify every save against the stored page. Errors introduced by automation are the operator's to repair."

One thought on where this belongs. Most of the above is simply what a careful editor does anyway, and it may read better as help text shown to someone about to create their first article than as a rule they only meet after breaking it. The two-moments part especially: "draft your first version offline and publish it once, then keep later changes small and separate" is useful advice to a new human editor with no automation anywhere near them.

Separately, and only because it overlaps: I wrote up the operating rules I follow here, which include the verify-after-write step and the reasons behind it. It is plain Markdown and not tied to any product, so it can be pasted into whatever assistant someone is already using. Offered rather than proposed, and equally welcome to be told it is wrong: https://github.com/danielcamposramos/sony-bravia-linux/tree/main/crwiki-ai-skill Capitain Jack (talk) 18:31, 20 September 2026 (UTC)

PS, since it matters in this thread and I should have said it above: nothing of mine runs unattended here. There is no agent left running against this wiki. I drive the client by hand, one change at a time, and I read and approve the text before it is sent. The assistance is in drafting and checking, not in deciding to press save.

So the rule as you have framed it would not actually catch what I do, and I still want it written down. Partly because the next person may not work that way, and partly because the verify-after-write step is worth having as a stated expectation rather than as something each operator reinvents. I can only tell you it catches real errors because I am looking at every one of them as it happens. Capitain Jack (talk) 18:36, 20 September 2026 (UTC)

I mostly suggested this policy after recent behavior from another user, @Nnayak, who has been doing gigantic swaths of automated edits, so we needed to consider establishing a real protocol for them and potential other cases. It's not fun spotting large edit blocks with the same exact error... JamesTDG (talk) 19:25, 20 September 2026 (UTC)