deletions | additions       diff --git a/Rule 4. Publish workflow as context.md b/Rule 4. Publish workflow as context.md  index 4f07353..449bc83 100644  --- a/Rule 4. Publish workflow as context.md  +++ b/Rule 4. Publish workflow as context.md 
...
# Rule 4. Publish workflow as context. context  Traditionally, what computer and information scientists call "workflow" has been captured in what scientists call the "methods" and/or "analysis" section(s) of a scholarly article, where data collection, manipulation, and analysis processes are described. Today, nearly every study uses many scientific studies use  computer software to carry out the bulk of its workflow, but rarely is the end-to-end process described in a paper or a single software package. Thus, while directly publishing code is critical (see Rule 6), 7),  publishing a description of your processing steps offers essential context for interpreting and re-using data. In the future, we envision that the most useful workflow documentation will be part of an electronic provenance record that"automagically"  links together all the pieces that led to a result: the data citation (Rule 2), the pointer to the code (Rule 6), the workflow (this Rule), and a scholarly paper. paper (Rule 5).  But for the time being, you can use a system that documents scientific workflows (see Appendix for a list). At a minimum, provide a simple sketch of data flow across software, indicating how intermediate and final data products and results are generated. If you get more ambitious, consider providing an online service that encapsulates the workflow. Keep in mind that even if the data used are not "new," in that they come from a well-documented archive, it is still important to document the archive query that produced the data you used, along with all the operations you performed on the data after they were retrieved. Keeping better track of workflow, as context, will likely benefit you and your collaborators enough to justify the loftier, more altruistic, goals espoused here.