anchor.diff:  |===
   
   ==== Attestation
  -In the current model we view the consuming application as being the owner of the flow.
  +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.
  
positive.code: 
  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.
  footnote:[link to Solidatus, TBC]
  
  .Platforms using existing model
  [graphviz, direct, svg]
  
negative.code: digraph B {
      A[label="App A", color="green"];
      B[label="App B", color="green"];
      C[label="App C", color="blue"];
      D[label="App C"];
  
      A->C[color=blue];
      B->C[color=blue];
      C->D[color=balck];
  }
  ----
  
  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.
  
  
  .Direct attestation for platforms
  [graphviz, direct-att-complex, svg]
  