Re: We should require AI disclosure
Guus der Kinderen <[email protected]> Wed, 8 Jul 2026 11:45:37 +0200
| Newsgroups | gmane.network.jabber.standards-jig |
|---|---|
| Message-ID | <CAMJaV9=qj8zZWqaU1Oms_gxhJ75ON98Q3NxUJcO6OMK6_pswhQ@mail.gmail.com> |
--===============5647366580422600203== Content-Type: multipart/alternative; boundary="00000000000061834a0656165fef" --00000000000061834a0656165fef Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ralph, Two things: First on the review gate: Dave has made the point that it sits too early, and you've added that XEPs used to be changed by discussing with the author rather than by PR. Moving that gate later (light review at intake, with the deeper reading happening as people actually engage with a spec) is a change we could actually make. It has the property that nothing gets a careful reading until someone cares enough to give it one, which is exactly the wrong incentive for anyone submitting in volume. It would help whether or not that volume materialises. It doesn't require us to agree about AI at all. Before committing to it, though, I'd want to understand why we moved in the other direction in the first place. Presumably it served some purpose. Second: you've twice invited a PR against XEP-0143 using your phrasing. I've opened one: https://github.com/xsf/xeps/pull/1552. It's your sentence, in the submission process rather than the pre-submission advice, since the latter is explicitly advisory. It's deliberately not AI-specific and it doesn't settle anything else here. I'd rather it merged on its own merits than became a proxy for the wider argument. You asked Goffi why a human-authored document wouldn't need the same thoroughness. I think that's unfair to him. Reviewers have always read with priors. You read a new contributor more carefully than a familiar one, and for a familiar contributor you may give more attention to certain aspects than to others. Knowing a submission came from an LLM tells you to go and check the references. That's useful information, if you have it. My objection isn't that disclosure would tell us nothing, it's that I don't expect it to be accurate in the cases where it matters most. Those are separate arguments, and I think they've been getting mixed up. Kind regards, Guus On Wed, Jul 8, 2026 at 11:13=E2=80=AFAM Ralph Meijer <[email protected]> wrote: > On 08/07/2026 09.52, Goffi wrote: > > Hi, > > > > Le mardi 7 juillet 2026, 21:16:07 heure d=E2=80=99=C3=A9t=C3=A9 d=E2=80= =99Europe centrale Ralph > Meijer a =C3=A9crit : > > > >> [SNIP] > >> I do not see why these problems uniquely exist because of the use of > AI, and why this isn't covered by an author's existing responsibility to > ensure quality and the pre-conditions for assigning ownership rights to t= he > XSF per its IPR policy (in particular sections 3.1 and 3.2). > > The scale and effort required is not the same with AI. > > In creating the contribution, this may be true. Like Dave commented > elsewhere in the thread today, I am not convinced about increased effort > on triaging (initial submission) or review of individual XEPs to move > between states. If you mean the volume of submissions or XEP PRs, then > we need to figure out how to lighten that effort. In the past, for > example, PRs were not the approach to getting a XEP changed. You'd > discuss your suggestions with the author(s) and then they would make > changes. The Editor might be involved, but there is no such requirement > unless (about) to move between states. > > I agree with Dave that putting all the scrutiny at the beginning of your > process (unlike before) does not help. Instead, accepting a new > contribution with light review allows the distribution of the load to > the rest of Standards JIG. I.e. people will start reading, commenting, > attempting to implement, etc. > > > >> If you cannot formulate the requirements for quality for humans, then > how does declaring use of AI make things better? And if you can, and a > submission complies, how does it matter that AI was used in the process? > How would you handle =E2=80=9CAI-tainted=E2=80=9D submissions differently= ? > > I would read it differently. If I know that a whole section is AI > written, I know that the text and references can be hallucinated, and tha= t > there can be more boilerplate text than a human would do. > > If AI is used to extract table or make examples, I'll probably check > quickly for hallucinated values. > > If AI is used for slight reformulation and spelling/grammar, I'll > probably read it no differently as I read pure human submission. > > > > If a request is slop (low effort fully generated AI), I'll probably not > bother and reject it. > > > > In any case, I would appreciate and consider polite to be informed if > I'm reading a human or machine generated content. > What criteria do you use to make these judgements. Why is there an > assumption that if a human created it, you do not have to be as thorough? > > >> The same holds for potential rights issues. The author is still > responsible. > >> > >> My concern is that all future submissions will just have this > disclosure as boilerplate, and a recipient cannot assess how deep the > impact of the use of AI is. With the accelerating growth we see in both t= he > capabilities and the use of AI, this becomes increasingly hard. We will n= ot > have gained anything substantial. In that regard it reminds me of the Evi= l > Bit (RFC 3514) / Malicious Stanzas (XEP-0076). > > This is not what I'm seeing in other projects. Even the local inference > engine "llama.cpp", which we can hardly accuse to be "anti-AI", ask for > that, you can check PRs there: https://github.com/ggml-org/llama.cpp/pull= s > > I agree that allowing submissions by PR makes it easier for agents and > people to submit them and that may contribute to increased volume. I > also think that code is different from protocol specifications. But as I > mentioned above, if you cannot triage quickly, this requires changes to h= ow > heavy your triage process is. I do not see how an optional declaration > makes any of this better. > > >> The statement you linked to seems like common sense and doesn't > actually require disclosure. Consider this document again, but conceptual= ly > replace =E2=80=9Cthe use of AI=E2=80=9D with the =E2=80=9Cuse of a keyboa= rd=E2=80=9D. Does having such a > statement change the outcome of our standards process? > > This is a very poor comparison. It's like saying "I don't see why we > need a driving license, I don't need one to walk". The scale is not the > same, with LLM you can generate easily tons of text looking on the surfac= e > more or less OK. > > I love car analogies. No, my suggestion is more like you asking how I > got to the XMPP Summit, and you valuing me differently when I came by > car. Besides your personal preferences, this should not have any bearing > on my contributions in that venue. And I will certainly not show you my > drivers license or discuss its impact on the environment _in that context= _. > > > >> I think that our author guidelines (XEP-0143) are already clear, and > sense all the above boils down to this: > >> > >> =E2=80=9CAuthors must understand, verify, and take responsibility= for > every contribution they submit.=E2=80=9D (-- ChatGPT with my prompting) > >> > >> While noting that this stance is not universally accepted (e.g. see < > https://jme.bmj.com/content/51/4/230>), I think it is suitable for our > standards process. Feel free to use this phrase in a concrete proposal, > like a PR to XEP-0143. > > To clarify my (current) position: I'm not asking for an AI ban, it coul= d > not be enforceable and AI is a great tool for accessibility and many othe= r > things. But I'm advocating for requesting a disclosure (maybe not > mandatory, but strongly suggested). Explain that we have human reviewers > behind, and that we'll reject AI slops specifications. Use of AI need to = be > fully checked, and text should be reduced to essential. The later is one = of > the main painful point with content generated by or with AI: it's longer > than necessary, and that make it harder to review. > > > > We could start to have this as a template/popup when doing a > pull-request. > As I wrote earlier, if you can provide concrete changes to, say, > XEP-0143, I would be happy to judge them on face value. I am fine with > stronger indication of the responsibilities we require of authors (like > my proposed text). Preferably, you still need to define how you "reject > AI slops" using objective criteria. If "gut feeling" is the process, > then you can already do this. > > FWIW, the paper I referenced is an in-depth discussion on the > responsibilities of human authors on scientific papers, which should be > an interesting read for anyone that wants to seriously discuss this > topic. There are rebuttals to it, too, but unfortunately they are not as > open-access as this CC-licensed paper. > > >> Disclosure: this message was manually (glide) typed on a OnePlus 12, > using Google Board, in Thunderbird for Android. Conversing with AI may ha= ve > influenced my thought process. Except where explicitly noted, no excerpts > of other works were included in this message. > > No need to be sarcastic here, this is a problem seen across the whole > industry, it seems legitimate to me to state our position, like many othe= r > organisations are doing. > This was not meant as a sarcastic jab at all. It was meant as a concrete > example of how hard it is to usefully declare the use of AI. I > specifically mentioned Google Board and glide typing, because it uses > machine learning and AI for writing each word based on how you glide. It > has auto-correction, spell checks, etc. I didn't run the whole text > through an LLM myself to correct my writing, though, and so there should > be no hallucinations (other than my own) or unsupported citations. > > If you want to have optional declarations of the use of AI, then you > also need to specify what that declaration could look like. If it is > free-form, then you will get things like my example. > > ralphm > > _______________________________________________ > Standards mailing list -- [email protected] > To unsubscribe send an email to [email protected] > --00000000000061834a0656165fef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Hi Ralph,<br><br>Two things:<br><br>First on the review ga= te: Dave has made the point that it sits too early, and you've added th= at XEPs used to be changed by discussing with the author rather than by PR.= Moving that gate later (light review at intake, with the deeper reading ha= ppening as people actually engage with a spec) is a change we could actuall= y make. It has the property that nothing gets a careful reading until someo= ne cares enough to give it one, which is exactly the wrong incentive for an= yone submitting in volume. It would help whether or not that volume materia= lises. It doesn't require us to agree about AI at all. Before committin= g to it, though, I'd want to understand why we moved in the other direc= tion in the first place. Presumably it served some purpose.<br><br>Second: = you've twice invited a PR against XEP-0143 using your phrasing. I'v= e opened one: <a href=3D"https://github.com/xsf/xeps/pull/1552">https://git= hub.com/xsf/xeps/pull/1552</a>. It's your sentence, in the submission p= rocess rather than the pre-submission advice, since the latter is explicitl= y advisory. It's deliberately not AI-specific and it doesn't settle= anything else here. I'd rather it merged on its own merits than became= a proxy for the wider argument.<br><br>You asked Goffi why a human-authore= d document wouldn't need the same thoroughness. I think that's unfa= ir to him. Reviewers have always read with priors. You read a new contribut= or more carefully than a familiar one, and for a familiar contributor you m= ay give more attention to certain aspects than to others. Knowing a submiss= ion came from an LLM tells you to go and check the references. That's u= seful information, if you have it. My objection isn't that disclosure w= ould tell us nothing, it's that I don't expect it to be accurate in= the cases where it matters most. Those are separate arguments, and I think= they've been getting mixed up.<br><br><div>Kind regards,</div><div><br= ></div><div>=C2=A0 Guus</div></div><br><div class=3D"gmail_quote gmail_quot= e_container"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jul 8, 2026 at 1= 1:13=E2=80=AFAM Ralph Meijer <<a href=3D"mailto:[email protected]">ralphm@ik.= nu</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margi= n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex= ">On 08/07/2026 09.52, Goffi wrote:<br> > Hi,<br> ><br> > Le mardi 7 juillet 2026, 21:16:07 heure d=E2=80=99=C3=A9t=C3=A9 d=E2= =80=99Europe centrale Ralph Meijer a =C3=A9crit :<br> ><br> >> [SNIP]<br> >> I do not see why these problems uniquely exist because of the use = of AI, and why this isn't covered by an author's existing responsib= ility to ensure quality and the pre-conditions for assigning ownership righ= ts to the XSF per its IPR policy (in particular sections 3.1 and 3.2).<br> > The scale and effort required is not the same with AI.<br> <br> In creating the contribution, this may be true. Like Dave commented <br> elsewhere in the thread today, I am not convinced about increased effort <b= r> on triaging (initial submission) or review of individual XEPs to move <br> between states. If you mean the volume of submissions or XEP PRs, then <br> we need to figure out how to lighten that effort. In the past, for <br> example, PRs were not the approach to getting a XEP changed. You'd <br> discuss your suggestions with the author(s) and then they would make <br> changes. The Editor might be involved, but there is no such requirement <br= > unless (about) to move between states.<br> <br> I agree with Dave that putting all the scrutiny at the beginning of your <b= r> process (unlike before) does not help. Instead, accepting a new <br> contribution with light review allows the distribution of the load to <br> the rest of Standards JIG. I.e. people will start reading, commenting, <br> attempting to implement, etc.<br> <br> <br> >> If you cannot formulate the requirements for quality for humans, t= hen how does declaring use of AI make things better? And if you can, and a = submission complies, how does it matter that AI was used in the process? Ho= w would you handle =E2=80=9CAI-tainted=E2=80=9D submissions differently?<br= > > I would read it differently. If I know that a whole section is AI writ= ten, I know that the text and references can be hallucinated, and that ther= e can be more boilerplate text than a human would do.<br> > If AI is used to extract table or make examples, I'll probably che= ck quickly for hallucinated values.<br> > If AI is used for slight reformulation and spelling/grammar, I'll = probably read it no differently as I read pure human submission.<br> ><br> > If a request is slop (low effort fully generated AI), I'll probabl= y not bother and reject it.<br> ><br> > In any case, I would appreciate and consider polite to be informed if = I'm reading a human or machine generated content.<br> What criteria do you use to make these judgements. Why is there an <br> assumption that if a human created it, you do not have to be as thorough?<b= r> <br> >> The same holds for potential rights issues. The author is still re= sponsible.<br> >><br> >> My concern is that all future submissions will just have this disc= losure as boilerplate, and a recipient cannot assess how deep the impact of= the use of AI is. With the accelerating growth we see in both the capabili= ties and the use of AI, this becomes increasingly hard. We will not have ga= ined anything substantial. In that regard it reminds me of the Evil Bit (RF= C 3514) / Malicious Stanzas (XEP-0076).<br> > This is not what I'm seeing in other projects. Even the local infe= rence engine "llama.cpp", which we can hardly accuse to be "= anti-AI", ask for that, you can check PRs there: <a href=3D"https://gi= thub.com/ggml-org/llama.cpp/pulls" rel=3D"noreferrer" target=3D"_blank">htt= ps://github.com/ggml-org/llama.cpp/pulls</a><br> <br> I agree that allowing submissions by PR makes it easier for agents and <br> people to submit them and that may contribute to increased volume. I <br> also think that code is different from protocol specifications. But as I <b= r> mentioned above, if you cannot triage quickly, this requires changes to how= <br> heavy your triage process is. I do not see how an optional declaration <br> makes any of this better.<br> <br> >> The statement you linked to seems like common sense and doesn'= t actually require disclosure. Consider this document again, but conceptual= ly replace =E2=80=9Cthe use of AI=E2=80=9D with the =E2=80=9Cuse of a keybo= ard=E2=80=9D. Does having such a statement change the outcome of our standa= rds process?<br> > This is a very poor comparison. It's like saying "I don't= see why we need a driving license, I don't need one to walk". The= scale is not the same, with LLM you can generate easily tons of text looki= ng on the surface more or less OK.<br> <br> I love car analogies. No, my suggestion is more like you asking how I <br> got to the XMPP Summit, and you valuing me differently when I came by <br> car. Besides your personal preferences, this should not have any bearing <b= r> on my contributions in that venue. And I will certainly not show you my <br= > drivers license or discuss its impact on the environment _in that context_.= <br> <br> <br> >> I think that our author guidelines (XEP-0143) are already clear, a= nd sense all the above boils down to this:<br> >><br> >>=C2=A0 =C2=A0 =C2=A0 =E2=80=9CAuthors must understand, verify, and = take responsibility for every contribution they submit.=E2=80=9D (-- ChatGP= T with my prompting)<br> >><br> >> While noting that this stance is not universally accepted (e.g. se= e <<a href=3D"https://jme.bmj.com/content/51/4/230" rel=3D"noreferrer" t= arget=3D"_blank">https://jme.bmj.com/content/51/4/230</a>>), I think it = is suitable for our standards process. Feel free to use this phrase in a co= ncrete proposal, like a PR to XEP-0143.<br> > To clarify my (current) position: I'm not asking for an AI ban, it= could not be enforceable and AI is a great tool for accessibility and many= other things. But I'm advocating for requesting a disclosure (maybe no= t mandatory, but strongly suggested). Explain that we have human reviewers = behind, and that we'll reject AI slops specifications. Use of AI need t= o be fully checked, and text should be reduced to essential. The later is o= ne of the main painful point with content generated by or with AI: it's= longer than necessary, and that make it harder to review.<br> ><br> > We could start to have this as a template/popup when doing a pull-requ= est.<br> As I wrote earlier, if you can provide concrete changes to, say, <br> XEP-0143, I would be happy to judge them on face value. I am fine with <br> stronger indication of the responsibilities we require of authors (like <br= > my proposed text). Preferably, you still need to define how you "rejec= t <br> AI slops" using objective criteria. If "gut feeling" is the = process, <br> then you can already do this.<br> <br> FWIW, the paper I referenced is an in-depth discussion on the <br> responsibilities of human authors on scientific papers, which should be <br= > an interesting read for anyone that wants to seriously discuss this <br> topic. There are rebuttals to it, too, but unfortunately they are not as <b= r> open-access as this CC-licensed paper.<br> <br> >> Disclosure: this message was manually (glide) typed on a OnePlus 1= 2, using Google Board, in Thunderbird for Android. Conversing with AI may h= ave influenced my thought process. Except where explicitly noted, no excerp= ts of other works were included in this message.<br> > No need to be sarcastic here, this is a problem seen across the whole = industry, it seems legitimate to me to state our position, like many other = organisations are doing.<br> This was not meant as a sarcastic jab at all. It was meant as a concrete <b= r> example of how hard it is to usefully declare the use of AI. I <br> specifically mentioned Google Board and glide typing, because it uses <br> machine learning and AI for writing each word based on how you glide. It <b= r> has auto-correction, spell checks, etc. I didn't run the whole text <br= > through an LLM myself to correct my writing, though, and so there should <b= r> be no hallucinations (other than my own) or unsupported citations.<br> <br> If you want to have optional declarations of the use of AI, then you <br> also need to specify what that declaration could look like. If it is <br> free-form, then you will get things like my example.<br> <br> ralphm<br> <br> _______________________________________________<br> Standards mailing list -- <a href=3D"mailto:[email protected]" target=3D"_= blank">[email protected]</a><br> To unsubscribe send an email to <a href=3D"mailto:[email protected]"= target=3D"_blank">[email protected]</a><br> </blockquote></div> --00000000000061834a0656165fef-- --===============5647366580422600203== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected] --===============5647366580422600203==--