Document workflow output

docs/source/user/getting_started/running_workflows.rst

@@ -66,3 +66,28 @@ Sometimes you might want to cancel a workflow that is running. Use
 
 where ``WORKFLOW_REF`` is either the path to the workflow directory, 
 or the ID of the workflow displayed by ``{{ app_module }} show``.
+
+Workflow output
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+In your working directory, a new directory will be created with the name of the workflow and the date and time of submission.
+This directory contains the output of the workflow, including your results files, the log files and any other files generated by the workflow.
+
+The directory structure is as follows:
+```
+workflow_name_YYYY-MM-DD_timestamp/
+├── artifacts/
+│   ├── workflow.yaml
+│   ├── submissions/
+│   └── tasks/
+├── execute/
+├── metadata/
+└── parameters/
+```
+
+The ``artifacts`` directory contains a copy of the workflow template file that you submitted, the submission files, and the task artifact files.
+The ``submissions`` directory contains generated jobscripts that are submitted to the scheduler, standard output and error stream files from those jobscripts, and app log files (if {{ app_name }} is configured to generate them).
+If your workflow crashes, you should first check the files in the ``js_std`` directory to see what happened.
+The ``tasks`` directory contains files associated with task execution that we wish to keep (for example input and output files for a simulation). We can control which files are kept within the task schema.
+
+The ``execute`` directory contains the working directories for the tasks, and so any output files generated by the software that is invoked will be here. The ``metadata`` and ``parameters`` directories contain binary files, corresponding to workflow structural metadata, and input and output parameters, respectively. You will not normally need to look at these files, but they are available there for advanced debugging and checkpointing.