One sometimes talks about the "envelope of change" of a system to refer to the the fundamental constraints of the system: those assumptions that it could be very costly to change generally. What is outside the envelope is hard to attain; what is inside is already accounted for in the architecture and can be implemented in a straightforward way.
A typical example of something that was outside the envelope of change is the out-of-memory handling introduced in Opera 6--it affected virtually every line of core code and was quite costly to implement. The result is a product that is deeply different than the one we started with.
The following list is not complete.
Some things are explicitly not required and are documented here so that we do not make the mistake of starting to rely on them. In some cases these are the consequence of requrements; in other cases, of design choices that were not forced.
The following assumptions do not go deep enough to define the envelope of change, but they are important for the code that we deliver today. If the platform does not meet these assumptions then significant work may be required too work around the problem.
The following list is not complete.