anchor.diff:  ----
   
   However, when we have aggregation/distribution platforms the **attestation burden falls upon the platform**.
  -Often the platform owners are not in a position to be able to accurately perform the required attestation, especially in mulit-tenancy situations.
  +Often the platform owners are not in a position to be able to accurately perform the required attestation, especially in multi-tenancy situations.
   
   
   .Direct attestation for platforms
  
positive.code: |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)
  
  | Intuitive understanding
  | -
  
  |===
  
  
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]
  