An outcome diagram should:

  • Show the "physical" items that exist / yet-to-exist / to-be-cleaned.
  • Show which steps are linked to it, e.g. clicking on a file shows the steps that write to / read from the file.

Determining Information for Rendering

To render the outcome diagram, we need to deduce the physical things from Items, and determine:

  1. Source: where data comes from, whether completely from parameters, or whether parameters are a reference to the data.
  2. Destination: where data moves to or the system work is done to.
  3. Whether the source or destination are declared in parameters.

As of 2024-02-18, Item::Params is a single type, which would take in both source and destination parameters, so we cannot (realistically) determine the source/destination/host/cloud from the Item::Params type.

What Rendering Makes Sense

Conceptually, Items can be thought of either an edge or a node:

  • Edge: The item represents an action / work to between the source(s) and the destination(s).
  • Node: The item represents the destination thing.


Consider the following diagram, which is the first attempt at rendering an outcome diagram on 2024-02-18 -- this uses edges / hierarchy to draw nodes and edges:


  1. It is not clear where the app_download Item transfers the file from, or to.
  2. It is not clear that the iam_policy, iam_role, and instance_profile are defined in AWS.
  3. The links between iam_policy, iam_role, and instance_profile should probably be reversed, to indicate what references what.
  4. The s3_object item transfers the downloaded application file, to the S3 bucket created by s3_bucket, but it isn't clear whether we should be highlighting the link, or the nested node.
  5. If we highlight the link, then note that it is a forward link (data is pushed), compared to point 3 which are backward links (references).

Hosts, Realms, and Edges

If we could show:

  1. The hosts of all network communication
  2. The "realm" where resources live in, which may be a cloud provider or a region within
  3. A node for each resource that is created/modified/deleted
  4. For each item, the edges and nodes that interact

then what is happening becomes slightly clearer:



  1. There is only one level of detail.
  2. It is useful to have expandable detail, e.g. hide a full URL, and allow the user to expand it if they need to.
  3. It is useful to show and hide animated edges while that step is in progress.