anchor.diff:  |Pros |Cons
   
   | Simplifies basic lineage
  -| Multi hop _via_ routes difficult to express
  -
  -| -
  -| Inconsistency of recording.
  -If App1 does not know, or particularly care about, App2 (or vice versa)
  +| Multi-hop _via_ routes difficult to express (ordering etc)
   
   | Intuitive understanding
  -| -
  +| Usage of platforms more difficult to understand as may be via a direct flow or an indirect detail on the physical flow.
  +
  +| Somewhat solves the attestation problem as the flow is now between apps.
  +| By omitting the platform from the main flow all recipients must know about, and record, `App 1` as the originator.
  +
   
   |===
   
  
positive.code: }
  ----
  
  <<<
  
  
  == Flow representation
  
  === Direct routing
  
  This is the way that flows are currently expressed in Waltz.
  We do expect each part of the flow to be documented can only see multi-hop flows via other mechanisms such as flow diagrams or by extracting the raw topology information into tools like Solidatus.
  
  .Platforms using existing model
  [graphviz, direct, svg]
  ----
  digraph B {
  
negative.code: }
  ----
  
  In Waltz there are limited ways to express indirect flow relationships such as `App 1` -> `App 2` in the diagram above (shown with the dotted arc).
  To show lineage users have a choice:
  
  * Use **Waltz's Flow Diagram** capabilities which allow users to quickly draw a route through the network (by using an editor constrained by the underlying graph).
  * Use **physical flow tagging** to associated flows.
    This is conceptually similar to the diagrams mentioned above, but some users prefer this basic approach.
  * **Export the flows and use tools** such as Solidatus to represent a more detailed view of lineage
  
  
  <<<
  
  === Attestation
  In the current model we view the **consuming application as the owner of the flow**.
  The reasoning behind this is based on a simple belief that the consumer is more likely to be aware of the flow than the producer.
  
  For simple app-to-app flows systems this model works well and attestation is straightforward; the consumer should attest all inbound flows.
  This is depicted in the figure below (`App C` must attest to the accuracy of the flows from `A` and `B`).
  
  .Example of attestation scope for simple apps
  [graphviz, direct-att-simple, svg]
  