Before you read my answer, please consider that the term software architect means different things to different people. I'll just share my point of view, as I understand the architect role.
Unfortunately I was given this position organically and there are no
standards in place for how I should do my job.
Well, that's what your job is all about. Most of the time you're defining, choosing or communicating standards. In my opinion you have got several responsibilities:
1.) Defining standards
It is your responsiblity to define the standards for your applications. This includes coding conventions but also architectural standards and processes. Homogeneity is sacred and thus this is a very important thing. The better your standards are, the easier it is for all developers to work with your company's products, even if they were not the original creators.
2.) Know your infrastructure or choose the appropriate one
It is your responsibility to know your company's IT infrastructure best or to choose the appropriate infrastructure. Choosing an infrastructure is a strategic decision, so choose wisely. Also consider economic factors (are there enough developers available for that technology? How much do they cost? Will I still get support for that 3rd party library in 3 years?). This often involves trade-off decisions like higher development costs but lower runtime costs or the opposite. You're also responsible for picking the right tools to aid the development process.
3.) Have deep insight in your business domain
It is your responsibility to know the business domain best! You should be the one who has the best sight on the big picture of your problem domain. You need to divide it into components and subcomponents and choose their place in the infrastructure! You'll have to think about synergy effects (reusability etc.).
4.) Define interfaces between system and components
It is your responsibility to define interfaces between systems and components! When the interfaces are good, implementations can be exchanged pretty easily.
5.) Choose the right architecture
It is your responsibiltiy to choose the appropriate architecture for applications and to provide a standard way of implementing it. In my experience, this is best done by providing small example projects that show how to create the structure of files and folders and how to implement standard things.
6.) Communicate! Communicate! Communicate!
Last but not least, it is your responsibility to communicate everything to the developers, to help them understand and to listen to their criticism. In my opinion you should as often as possible have the developers involved in important decisions. They might bring up things and potential problems you wouldn't have noticed. Communicate a lot with them and listen to their feedback and problems. Have your wizard around when you're defining standards or you're creating an example project for a certain technology! Collaboration is the key to success.
I am very interested, for example, what type of diagrams and documents
an architect might provide so that they can assist a developer in
doing their job.
You'll have to help the developers understand the business domain and the architectural decisions you made. I wouldn't waste the time and create documents that are subject to change every three weeks. Imho the best way to provide the knowledge is to give them example code (an example project e.g.) and to sketch down some UML every now and then when they're having a problem or you need to communicate something. This should be supplemented by the usual documents (requirements analysis, product backlog, etc.).
Finally, I want to give you some personal advice. Having this role is hard indeed. You're responsible for many things. Success and failure stand and fall with your ability to communicate and collaborate. You needn't know everything or excel at every single task, rather make sure your team participates and find the best solutions as a team. Don't be an ego, there'll always be a developer who knows something better than you. Keep these people around you for the sake of the product. Be humble and incorporate any good feedback. Don't take criticism personally, but compliment developers on a well done feedback or for pointing out errors.