anchor.diff:  ----
   
   
  +[CAUTION]
  +====
  +We would need to consider what happens when/if platforms exchange data.
  +If they are exempt who has the attestation obligation ?
  +
  +.Platform to platform flows, who attests ?
  +[graphviz, direct-att-complex-edge-case, svg]
  +----
  +digraph B {
  +
  +    plat1[label="Platform 1", color="orange"];
  +    plat2[label="Platform 2", color="orange"];
  +    app1[label="App1", color="green"];
  +    app2[label="App2", color="green"];
  +
  +    app1 -> plat1 [color="green"];
  +    plat1 -> plat2 [color="red"];
  +    plat2 -> app2 [color="green"];
  +
  +    {rank = same; app1; app2; plat1; plat2}
  +}
  +----
  +====
  +
  +**_Option 2:_ Declate 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.
  +
  +
  +
  +
   <<<
   
   
  
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: |===
  
  ==== 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.
  