When building a bounty brief, it's just as important to specify what you don't want researchers to test for as what you do want them to test for. This helps respect researchers' time and effort by excluding common issues like low-impact bugs, intended functionality that could be misinterpreted as a vulnerability, known issues that are not worth fixing before the program launches, accepted risks that are not worth rewarding, and issues resulting from pivoting. By explicitly noting these exclusions, you can save both yours and researchers' time, provide a better experience for researchers, and build a positive relationship with them. This is crucial to create a successful bounty program where researchers feel encouraged to continue exercising their skills and abilities in your program.