add AI guidelines

[RafaelAPB]

As discussed in the TAC meeting 15th of April 2026, here is my contribution for us to discuss AI guidelines for LFDT projects.

Recording: https://www.youtube.com/watch?v=H6_EmFEu2ik
Slides: https://discord.com/channels/905194001349627914/1493501870185119846/1494377792417169559

Some points of discussion/concerns raised:

• should specific tool/model be disclosed for each commit? Is disclosure that AI was used enough?
• should a risk and opportunities assessment be done and included in the present guidellines?

[matthew1001]

Does this mean all projects, or just LFDT (such as project annual reviews etc.) If it's all projects it's worth clarifying that here.

[RafaelAPB]

The idea would be this document to provide guidelines for all LFDT projects, as well as meta projects (i.e., the administrative repositories). Opinions on this? We shall add a clarification upon feedback from the TAC.

[ThatGuyLLC]

I agree with that stance and would include labs as applicable, it's best to have one MVP guide and then exceptions as they develop

[matthew1001]

It's presumably acceptable that a review is itself AI-assisted? E.g. "I used Gemini to explain some background concepts from a project proposal"?

[RafaelAPB]

I'd say a contributor does not need to disclose if AI was used for learning/assistance in the contribution process, but rather if it is used to generate code.

[ThatGuyLLC]

I would include any "assessment results contributions" as well outside of direct code, discloses possibility of hallucinations possibilities in results.

[matthew1001]

Suggested change

	### For LFDT projects contributors
	### For LFDT project contributors

[matthew1001]

I'm not sure if this statement/document equates to a MUST instruction or a SHOULD. I think it's useful for projects who are trying to ensure they are compliant with LFDT requirements, to be clear which it is. Perhaps our convention is that any "guidelines" documents are implicitly SHOULD or MAY requirements, and anything that's a MUST requirement should be under governing documents.

In fact I notice that this document is called AI-GUIDELINES.md but is not under the guidelines folder. I think this needs clarifying.

[RafaelAPB]

Very good point. My recommendation would be to keep generic guidelines more permissive when possible (i.e., disclosure SHOULD be done), and projects can implement stricter guardrails (i.e., Cacti uses a MUST for AI generated code disclosure)

[RafaelAPB]

The document should indeed be under guidelines.

[matthew1001]

I think I agree with it being a guideline not a mandatory requirement, as it leaves scope for projects to determine what is appropriate for them

[matthew1001]

Suggested change

	Code that was generated or assisted by AI — whether in implementation,
	review, documentation, testing, or any other activity associated with
	open-source contribution — shall be disclosed. Following the
	Code that was generated or assisted by AI — whether in implementation,
	review, documentation, testing, or any other activity associated with
	open-source contribution — `SHOULD` be disclosed, but projects are allowed to determine an appropriate stance based on the view of their technical steering committee (or maintainers in the absence of a TSC). Following the

[hendrikebbers]

I have put it to the agenda of the Hiero TSC and plan to bring feedback in within the next 2 weeks

[ryjones]

@/ent:project-maintainers

The LFDT Technical Advisory Council has been discussing creating guidelines for the responsible use of artificial intelligence in contributions to projects and labs. The TAC wants input from maintainers before making any decisions about these guidelines.

You can see the draft guidelines and the discussion about them so far at:

#321

To provide feedback on this, feel free to add your thoughts on the Github pull request, join an upcoming TAC call or join the #tac channel on LFDT Discord. You can find information about upcoming TAC calls or meeting minutes from previous calls at:

https://lf-decentralized-trust.github.io/governance/meeting-minutes/

[SamYuan1990]

I would say any guideline which allows AI usage(any level) are good for me.

Just sharing my practices in very briefly, please mail me(mailto:yy19902439@126.com) if you interested with details:

For our community project, I configured some DepBot with auto merge, and ask user to use latest version if possible(it's a testing tool not for production).

As there already some AI tools(bower plugin?) to deal with leecode exam. If we can't ensure or force no AI. I don't want to stuck myself to worry about AI.

Instead, I would like to suggest that we set up strands as:

• For any PR meet this(A,B,C,D), then merge.

Start DepBot in this thread, as for me it's a good example which:

• The ABCD is if the bump up version is no harm(ex. no breaking for CI), then auto merge.
• For other AI contribution, I just treat as a smarter depbot.

I also did some implements on i18n, a smarter bot to see if this ABCD can scale:
Some community feedback as for i18n, because it's not production document and well, people just treat an i18n agent as google translate.

For example from English to xxx language, as I don't know the language, so I try my best with a translation tool to provide audience a edition, if it's wrong, please PR back.

• The ABCD is as I(among community) don't know xxx language, just ask LLM to do it's best. If it's wrong, please audience fix and PR back.(as server side google trans)

Then coding, I make a personal spec with 3 parts in each file: description, code impl, and example usage, which the research still in progress.

• AI generate code from description to code impl, which means, for any LLM, in most case can do the same level/quality of code impl.
• Example usage to user document.
• Test with end to end test case.

To be specific, at format level, how about agents.md? so that we can apply to all projects and coding agent can know this work.

[AntonioCeppellini]

I think that if we want to be AI permissive we should try to be consistent across all repos (i.e. like @SamYuan1990 mentioned the agents.md).
to be honest if someone use AI to write code or to understand the codebase for me is okay, the most important part is to handle the logic of the code properly, to make it readable, maintainable, secure and well documented, if it is done only by hand or if it is thought by a person that make the agent writes very good code that follows all the "rules" that should follow then for me is quite the same thing (in terms of result).
for sure if someone that can not code use ai to create code then the result could (with high probability) be something we don't want to handle 🤣.
Also what should be the line that divide a human written code to a "ai-assisted" one? because if AI helps me to understand code and gives me hints on how to design code is still ai-assisted, no?
and also if I design everything but let AI writes code with strict rules and instructions because i want to be faster is still ai-assisted, no?
but it seems to me they are two very different approaches (that could have the same outcome).

[WRRicht3r]

Suggested change

	TBD
	Artificial intelligence (AI) tools, including large language models (LLMs), are increasingly being used throughout the software development lifecycle to assist with coding, documentation, testing, review, translation, security analysis, and other project activities.
	These tools can improve productivity, lower barriers to contribution, and help contributors and maintainers work more effectively. At the same time, AI introduces risks related to code quality, security, licensing, intellectual property, transparency, and accountability.
	LF Decentralized Trust (LFDT) is adopting this policy to help projects and contributors realize the benefits of AI-assisted development while maintaining the standards of openness, trust, security, and community governance that underpin LFDT projects.
	This document establishes a common framework for the responsible use of AI across LFDT projects and provides both mandatory requirements and recommended best practices for AI-assisted contributions.
	This policy applies to all participants in LFDT projects, including contributors, reviewers, maintainers, Technical Oversight Committee (TOC) members, and project teams. It covers the use of AI tools in all forms of project contribution, including source code, documentation, reviews, testing, automation, translations, visual assets, and other project artefacts.
	The requirements defined in this document establish the minimum standards for AI-assisted contributions across LFDT projects. Individual projects may adopt additional or stricter AI-related policies where appropriate, provided those policies do not conflict with or weaken the requirements established here.
	The guidance and recommendations contained in this document are intended to support the consistent implementation of these requirements across the LFDT ecosystem.

[RafaelAPB]

Generally speaking, I agree with this; let's get feedback from the TAC

[WRRicht3r]

The phrase “sole responsibility” may create ambiguity in collaborative contributions involving multiple authors or reviewers.

[RafaelAPB]

Let's change "of the committer" to "the authors" perhaps? Indeed the committer might not be the person who did the task

[WRRicht3r]

Consider clarifying that responsibility applies to the submitting contributor, without diminishing existing reviewer and maintainer responsibilities.

[WRRicht3r]

• “Reviewed by a human” is not defined.
• A contributor could theoretically perform only a superficial review while remaining compliant.

The section could distinguish between cursory review and meaningful validation.

[WRRicht3r]

• The requirement is reasonable but difficult to enforce.
• Large contributions may make complete understanding challenging, even when authored manually.

Consider framing this as a contributor expectation rather than an implicit compliance requirement.

[RafaelAPB]

I tend to agree as it is hard to verify and enforce. Thus, thus section should provide some recommendations to the contribution expectation?

[WRRicht3r]

• This section repeats several concepts already covered elsewhere (responsibility, review, compliance).
• Could be streamlined to reduce redundancy.

[WRRicht3r]

• The distinction between exempt IDE assistance and discloseable AI assistance may not always be clear.
• Modern development environments increasingly blur the line between autocomplete and code generation.

Consider providing additional examples or principles to help contributors determine when disclosure is expected.

[RafaelAPB]

Good point; at the start autocompletes were fairly simple (mostly syntax). However, you could configure autocompletes to output decent-sized blocks

[WRRicht3r]

• Some expectations may be difficult for contributors to satisfy in practice.
• For example, contributors often cannot determine with “reasonable certainty” whether output is derived from copyrighted material.
• The recommendation to prefer tools that identify training-data provenance may exclude many widely used AI systems that do not provide such transparency.

The section could distinguish between aspirational best practices and mandatory requirements.

Additionally, the statement regarding confidential code inputs could benefit from references to acceptable enterprise AI tooling and approved deployment models.

[WRRicht3r]

This section would benefit from prioritisation:
* What is mandatory?
* What is recommended?
* What is optional?

Current wording sometimes mixes requirements with suggestions.

The maintainer guidance could also address enforcement and handling non-compliant submissions.

[WRRicht3r]

• Consider defining a review cadence (e.g., annual review by the TOC).
• Otherwise, updates may become reactive rather than systematic.

[lifubang]

Thanks all for the thoughtful discussion so far. I'd like to add a
perspective that might help with some of the open questions.

1. We need measurable AI usage levels.
Every time we talk about "AI-assisted contributions," we're using different
standards unless the levels are quantified. The term "AI-assisted" covers
everything from asking ChatGPT a question to fully autonomous code generation.
Without a shared taxonomy, our policies will always be talking past each other.

2. Review quality is not enforceable -- with or without AI.
Several comments (including @WRRicht3r's review) point out that "human review"
is hard to define and enforce. This is true, but it's also not a new problem
introduced by AI. We've never been able to require a certain depth of human
review, and the AI era doesn't change that. The right approach is to set
expectations, not compliance checkpoints, for review quality.

3. Different AI usage levels deserve different policy conclusions.
L1 (chat-based Q&A) and L5 (autonomous agent submission) should clearly not
be treated the same way. A single blanket policy for "AI use" is either too
strict (blocking useful tools) or too loose (allowing low-quality submissions).
Level-specific policies are the only way to be both permissive and responsible.

---

With these points in mind, I'd like to share a lightweight convention I
proposed at OpenChain Beijing 2026 & OSPOlogy Live:

.agentic.md

(This is different from agents.md -- it's for human developers, and a quantifiable taxonomy with L1–L5
levels, not just a free-text instructions file for coding agents.)

It defines 5 AI usage levels, maps each to a policy stance (Allowed / Cautiously
Allowed / Not Allowed), and proposes a standard Co-authored-by / Reviewed-by
disclosure format. The file is designed to be machine-readable (inspired by
robots.txt), so it can be parsed by CI bots.

I'm not suggesting adopting it as-is, but I'd be curious whether the L1–L5
taxonomy helps provide the measurable baseline this PR needs.

Thoughts?

[ryjones]

@/ent:lab-maintainers please review and add comments to this matter before the TAC

[RafaelAPB]

1. We need measurable AI usage levels. Every time we talk about "AI-assisted contributions," we're using different standards unless the levels are quantified. The term "AI-assisted" covers everything from asking ChatGPT a question to fully autonomous code generation. Without a shared taxonomy, our policies will always be talking past each other.

I'm not sure if we need measurable "AI usage levels". Surely that such data could provide useful, but I don't see a reason for, at this stage, ask for information in excess.

**2. Review quality is not enforceable
I tend to disagree, but only partially. There are guidelines (i.e., social contract) and enforceable techniques (e.g., via CI) that do implement certain quality assurance in contributions (and, similarly, reviews). See for instance the quality control checks and CONTRIBUTING.md at Hyperledger Cacti.

A single blanket policy for "AI use" is either too strict (blocking useful tools) or too loose (allowing low-quality submissions). Level-specific policies are the only way to be both permissive and responsible.

I think the current guidelines do not concern itself too much with "allowing low-quality submissions" - It is up to each project to define what is a high-quality submission and how to enforce it (e.g., contributing guidelines, specific instantiation of these AI Guidelines);

[ThatGuyLLC]

I agree with this policy and support it

[RafaelAPB]

@ryjones who's responsible for updating the PR while progress is done on this topic? I'm happy to push the changes myself or to allow folks to push to this branch

[ryjones]

@ryjones who's responsible for updating the PR while progress is done on this topic? I'm happy to push the changes myself or to allow folks to push to this branch

you do you