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: }
  ----
  
  |===
  |Pros |Cons
  
  | Closely resembles actual topology
  | Lineage is hard, cannot represent that the intended recipient of the flow from App1 is App2.
  In Waltz this is mitigated by using flow diagrams to explicitly depict multi-hop lineage.
  
  | Conceptually simple
  | -
  
  |===
  
  ==== 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]
  
negative.code: ----
  ====
  
  **_Option 2:_ Declare attestation obligations on a per flow basis**, this would be at the physical flow and/or logical flow level.
  These obligations will inform the ui who is responsible for each attestation.
  
  Whilst the second option will give more accurate results and handles more situations, we believe the development effort and associated runtime attestation effort will outstrip this gain.
  
  
  <<<
  
  == Alternative flow representations
  
  === 'Via' routing
  
  In this approach the flow of data is recorded between `App1` and `App2`.
  The platform in between them is recorded as a detail on the physical flow.
  
  
  .Platforms using physical routing
  