Mike raises some excellent points so perhaps I'll continue the theme of when you can't call yourself an architect...

Since my post about first experiences of being an architect, as opposed to a lead developer, I've tended to think of the difference in terms of code (the clue's in the job titles!). Therefore I'd probably say you can't call yourself an architect until you've done a project without writing a line of code*! I found it fascinating to see how my thinking changed when I couldn't defer the research or design to the construction phase of the project. If you can't code your way out of trouble anymore you try to spot it in advance.

There's also a duty to the technology as well as the team. Perhaps you can't be an architect until you've selected a technology you know nothing about and lumbered somebody else with developing using it (but stayed on the project)! This means doing your research and supporting the development team despite being no more familiar with it than they are.

I guess this all boils down to more or less the same points that Simon mentions... experience and confidence. Experience lets you trust your instincts when in unfamiliar territory. If you're to make a detour through an unfamiliar technology then confidence is also required.

Perhaps I'd use a stronger word - something like "audacity". As Mike says, when the buck stops with you and the best technology choice isn't your forte it takes a degree of audacity to go ahead anyway. This isn't synonymous with being cavalier - your experience and hard work will get the job done in the best way, not necessarily the easiest way.

* I'm not advocating the "Architects Don't Code" anti-pattern, merely that there's valuable insight to be gained from having this safety net removed and drawing a slightly wider line between being a lead developer and an architect.