The discussion I’m trying to start here is where architecture stops and design begins. In my point of view a Project Start Architecture (PSA) can be used to bridge the gab between a prescriptive architecture approach – where by the use of principles and reference models the design freedom is being limited – and a more system design oriented approach (also see ‘Three perspectives on architecture, Erik Proper 13 December’). The main topics addressed in a PSA are: the driving business requirements (not the user requirements), the current situation (the descriptive architecture approach), the relevant principles, the available reference models (context of the project within the reference architecture) and the to-be situation (the solution). Addressing stakeholder concerns and describing the solution from various viewpoints (aligning business-, information-, application- and infrastructure architecture), demand and supply will be brought closer together, creating an agreement on the project objectives and scope. 
 
Yes, the PSA is a temporary document. After realization the (descriptive) as-is architecture has changed. The views created in the PSA can be used to up-date the architecture descriptions to the current status. 
 
The question is still how far we should go in describing the to-be situation. In practice you will see that a PSA will have a lot of content you would normally see in specification- and/or software architecture document. I think this is because the purpose of a PSA is not always clear and thereby often misused. In my opinion the PSA can be used to make some high level design decisions (like the technology to use) based on possible risks to the project, but this will depend on project need. 
 
I do think a PSA is of great relevance (and a lot of organizations do to) to align the demand and supply (business and IT), avoid solutions that are not in line with enterprise architecture strategy and to improve project success.