Joel Kallman had an interesting post about a customer who broke all of the rules and modified some constraints in the APEX_030200 schema. In this case, there was a happy ending, as Joel went the extra mile to craft a custom patch to remedy the issue. However, things don't always end up this way.
This reminds me of my early days with Oracle, when I used to work with the eBusiness Suite. The first page of any documentation of the suite said something like this: "WARNING: Do not use SQL*Plus to modify any database object directly". We used to laugh at this, as we used SQL*Plus & TOAD to modify these database objects several times a day, if not more frequently.
However, this was done on internal systems used to build demos. If we messed something up - and boy did we ever - we could easily refresh the instance with little effort.
Fast-forward a few years to today: FND & APPLSYS have been replaced by a single, much smaller schema called APEX_030200. Despite this, the same rules apply: NEVER modify anything in the APEX_030200 schema. Period. I always make it a point to emphasize this as much as possible during our training classes.
Now, if you MUST take a look at that schema - and many of you reading this will - please do it in a test environment that is not used for anything else. This can easily be done by using VMWare or one of the many other virtual machine programs. You can also do this in the Amazon Cloud. It doesn't matter as much WHERE you set up a test instance, but rather that you DO set up a test instance, and then poke around there. This way, nothing gets corrupted - now or in the future.