anchor.diff:  ----
   ====
   
  -**_Option 2:_ Declate attestation obligations on a per flow basis**, this would be at the physical flow and/or logical flow level.
  +**_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 between `App1` and `App2`
  +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
  
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: 
  This is depicted in the following figure, the green flows show a large volume of inbound flows to the platform which may have little knowledge of their content and/or accuracy.
  
  <<<
  
  ==== Attestation Enhancements
  
  To overcome this situation we could:
  
  