Why is it important to have your choice of principles, patters, and architectural decisions identified “PRIOR” to construction? How does or does not this conflict with the agile development methodology?
Making strong decisions about principles, patterns, and architecture before beginning construction of software makes the rest of the processes that much easier to complete. Principles and patterns seem to really be the same as good programming (and software design) practices, and the architecture seems to be more about planning a general framework for the rest of the project.
Not doing this could result in a lot of rework if two different components are being worked on by two different people who take different approaches and forgot to account for the ways that those components need to interact with one another. Alternatively work could be duplicated across components, and other regular principles could also be violated. Finally without strong decisions up front the final software may not be modular enough to support updates, changes, or additions in the future without serious rework.
I do not believe this conflicts with agile methodologies whatsoever. Lots of up front planning to establish good, strong decisions about these items actually seems pretty par for the course for this methodology. It's almost more important in agile since individual components will be developed one at a time - this means that the team must make sure up front that they all follow the same principles and architecture so everything will fit together in the end.