My "everything goes" dish: Finnish karjalanpaisti pork cubes seasoned with Vietnamese sauces then braised and shimmered in miso soup, Japanese style, with fried eggs and wakame. Served with Italian penne pasta.
When I used to live with one of my ex-girlfriends, we absolutely loved indulging in exotic food tours once every few weekends. Usually it was just me cooking up the meal because she had this belief that she has terrible taste and everything she touches turns sad and soggy. One weekend I decided that I wanted to help her become more confident and also that I want the cooking to be more like a couple thing with back-and-forths and each one supporting the other. So we sat down with the recipe for a fairly complicated dish and tried to figure out how we can best divide the tasks among ourselves.
It is now very clear from a glance that in order to make bolognese, you have to make the ragù and the pasta, and in order to make the ragù, you have to make the sofrito, and in order to make the sofrito, you have to have these certain ingredients cooked in this certain way, etc. It's turtle all the way down! And we can now see that the pasta, stock, sofrito can be done separately (some recipes are more parallelizable than others; the first one that we tried was a great example but we lost that piece of A4 paper, sadly, and I don't even remember what we cooked that day exactly anymore).
For now, as far as I know, there is no intuitive tool yet to create this kind of graph for personal use. I'm currently handwriting all my recipes into Microsoft OneNote but you may have success with a mind-mapping tool.
I can imagine this method of representation being part of a bigger cooking knowledge management system. You could have recipes depending on each other and/or reusing parts of each other. For example, the recipe for Spaghetti Bolognese calls for sofrito as the base for the sauce. Many other Italian ragus also call for sofrito. We could have them all depend on a single sofrito as one of the ingredients.
Once you have the recipes broken down into structured data, you can do all kinds of interesting queries on top of it. For example, you can automatically estimate recipe difficulty by analyzing the complexity of the graph: how many nodes and edges are involved, longest path to the finished dish among other metrics like centrality. We can also add weights to the nodes to represent price, relative rarity to find in a particular locale (Latundan banana "chuối tây" is basically impossible to find in Finland, oh that richly sweet taste...) or to edges to signify difficulty or average known time to complete certain actions. These weights will add up to combine with other metrics to form a complexity assessment. Or we can do graph similarity indexing to recommend relevant recipes.
<aside> 💡 Even though this idea first started out as a way to write down cooking recipes, I believe it is applicable to any assembly process. IKEA instructions booklets, for example, could benefit greatly from a redesign in this direction. Computer system admins and data researchers have long used DAG's for setting up data processing pipeline. And I wouldn't be surprised to find that the food scientists working on industrial recipes for massive large-scale food production are already using this representation. They might even think that this is such an obvious and trivial thing to talk about.
</aside>
Unsurprisingly, being such a natural way of looking into cooking instructions, this method has been discovered by many people, independently. But so far no one has successfully popularized it yet. A quick survey reveals several papers, interestingly a significant number of which are by Japanese researchers: