Skip to main content

AI Usage Policy

The OpenGOAL project has some strict rules regarding AI usage and contributions:

There are Humans Here​

Please remember that OpenGOAL is maintained by humans, for zero financial gain (infact, it's been at a substantial loss).

Every discussion, issue, and pull request is read and reviewed by humans (and sometimes machines, too). It is a boundary point at which people interact with each other and the work done. It is rude and disrespectful to approach this boundary with low-effort, unqualified work, since it puts the burden of validation on the maintainer.

If you disagree with these rules and guidelines, do not waste both of our time arguing over them. Move on to another project that aligns with your ideals instead, plenty exist, now more than ever. If you are the type to hurl insults at us because of how we have chose to maintain our project that we have poured over a-half-a-decade of our time and passion into, then your use of AI is the least of our reasons for why we want nothing to do with you.

General Rules / Etiquette​

  • All AI usage in any form must be disclosed. You must state the tool you used (e.g. Claude Code, Cursor, Amp) along with the extent that the work was AI-assisted.
  • No commits authored/co-authored by AI agents will be merged. We currently have no commits in master that are associated with Claude, Copilot, etc., and we would like to keep it that way. Constructing and organizing the commits yourself is a useful step for succeeding at the next requirement. We also have no interest in giving these companies free advertising or being directly associated with them.
  • The following rules can be summarized with the new term gaining popularity of don't be a meat proxy:
    • The human-in-the-loop must fully understand all code. If you can't explain what your changes do and how they interact with the greater system without the aid of AI tools, do not contribute to this project.
    • Issues, discussions and pull requests can use AI assistance (provided they don't violate other rules) but must have a full human-in-the-loop. This means that any content generated with AI must have been reviewed and edited by a human before submission, this includes the issue or PR description. AI is very good at being overly verbose and including noise that distracts from the main point. Humans must do their research and trim this down, ideally communicating with their own words.
  • No AI-generated media is allowed (art, images, videos, audio, etc.). Text and code are the only acceptable AI-generated content, per the other rules in this policy.
  • Bad AI drivers will be denounced. People who produce bad contributions that are clearly AI (slop) will have future contributions blocked, we don't have the time or the motivation to deal with this. Additionally, this block list will be public and may be used by other projects to be aware of bad actors. We love to help junior developers learn and grow, but if you're interested in that then don't use AI, and we'll help you. I'm sorry that bad AI drivers have ruined this for you.

OpenGOAL / Decompilation Project Specific Rules​

  • Accidentally committing game assets / data will result in an immediate ban from the project. This is something we have zero tolerance on going forward. The repository already has all of the relevant spots gitignored properly, but AI agent tools seem to love to put these sensitive files randomly in new folders and then when people don't make the commits themselves, they push up thousands of these sensitive files unknowingly. This is careless behaviour that shows a lack of regard for the previous rules and worst of all puts the project in legal jeopardy. This has never been a problem when only humans were involved, this is not a high bar to meet.
  • No AI generated contributions to /goal_src/ (the actual decompiled game code) from new contributors. Sorry to gatekeep, but there are several reasons for this:
    1. We successfully finished decompiling Jak 1, Jak 2, and Jak 3 without AI assistance, there is no reason to reach for an LLM for the last game (Jak X) when our decompilation tools are already heavily mature. We would like to be able to say that all four games were decompiled the traditional way, especially since projects like these work via very loose legal gray areas / precedents for reverse-engineering. It is anyone's guess at this point what will happen to all of these new AI-powered decompilation projects in the near-future and we have no reason to risk it after how successful and diligent we have been for many years.
    2. The goal of our project is not to just get the games running on PC, as so many recent decompilation projects seem to have as their main focus. Our goal has always been to understand the game's code and to clean it up as we go along so it can be easily read by humans, modified and extended. This cannot be achieved using LLMs when you do not have the hard-earned experience of actually working with GOAL code. While it is impressive with what it can do, we've already seen it lie, hack together and justify incorrect fixes, and mislead people with giant blocks of comments -- with no experience you cannot discern these things, and it should not be someone else's burden to do so.
    3. Probably most importantly, changes to this code can easily cause new bugs for users, bugs that we have no interest in solving, especially if they are things we've already fixed in the past. This is just an inconvenience for us and our users, we've already started to see the decline in other decomp projects where they are shipping broken AI features, we aren't interested in following suit.
  • No Android/Mobile support related contributions. No one on the team is interested in being involved in the Android or other mobile ecosystems and maintaining those release/distribution processes, etc. Such contributions will be rejected.
  • No LLM powered translation or localizaton efforts. We have already seen the low quality outputs of AI assisted localization, with people having to comb through and fix obvious mistakes that were never proof-read. We are taking the stance that no translations are better than bad machine translations. They also create the false impression that the translations are complete, potentially discouraging or making it harder for actual human translators to make a contribution (instead of having a list of things left to translate, they have to search through a list of things that were "done" potentially incorrectly).
  • No massive refactors or additions to enable or enhance low percentage user base support. Such examples would include a Metal or DirectX renderer. These sorts of things are large undertakings and come with a significant maintenance burden while only making an impact for <1% of our user base. History shows that unfortunately these sorts of contributions are not made by people that will assist long-term with fixing bugs, but even if they were to break the mold and fix every bug that users report, it really isn't worth the effort. Since the beginning we have made the decision to not support every possible user's configuration to strike a good balance between the developer experience and supporting the majority of users, for example, requiring things like AVX support and a modern OpenGL version, we are sticking by this decision. If your big feature is essentially only going to be used by you and a handful of other users or you just want to experiment, then it does not need to be in the mainline distributed project.