Kevin here.  As Angelo mentioned I've been putting together a viewer for the data for our fleet, which I originally started to help some of us review and settle a mark room situation prior to needing to get into the room.  Given that there was a lot of thought about what the data can prove vs infer as we were looking at it together as adversarial parties not just trying to present a case in the best light.  There's a lot of good discussion here about GPS resolution/accuracy I won't rehash so I'll try to stick to some key points I don't think have been considered yet:

1.  Boat motion in the Vakaros RaceSense player is interpolated.  If you're simply viewing the RaceSense player that means from one GPS logged position to the next (each having heel, heading, SOG, COG) the motion, turning, and position of the boat is assumed to have a perfectly smooth transition between the two points.  It is entirely possible for a boat to duck another one, then come back up on the other side and if the mesh network didn't manage to get data over to the tablet during those critical seconds the player might show the boat traveling in a straight line right through the other boat.  As far as I know the player does not have an ability to only show only the logged GPS points which means you're not just watching something with GPS inaccuracy, you're watching smoothed motion between two points with GPS inaccuracy which may in actuality be a complete large gap in the record.  This can contribute to where you're seeing boats moving sideways.  It's not that they knocked their atlas device on the mast, it's that you're looking at a 9 second data gap where a tack occurred in the middle of it so the track is showing the boat moving directly towards the new point but it's smoothing the heading change for the boat across all 9 seconds of the gap.  Here's exactly such a case:

If you pull the data, what you really see is a data point where the 90 degree turn is with them on the original tack and then 9 seconds later a new data point way to the right fully on the new tack.  All the sideways sailing is from the interpolation, there's no actual Heading or COG readings for what it's displaying for those 9 seconds, just the delta divided over the time for smooth display.

This is not a knock on Vakaros player.  Watching tracks without interpolation on makes me want to stroke out from all the jittering and they weren't intending it to be used for determining protests so it's perfectly reasonable to have interpolation on for it.

But it's a real limitation if you ARE trying to do that.  To help us deal with this I included a toggle on our viewer so that you can turn interpolation off for situations where you need to see the actual evidence in it's sparse form without anything filled in for you.  When interpolation is off each boat shows a timer indicating how stale the GPS data point is in relation to the player time. A positive number like 0.5s means the data point is stale by .5s and a negative number means it's from the future which now that I type up is probably going to confuse people and should be inverted.  Anyways, the point is, you need to know if the closest data point is older or in the future of the current player time and what that time delta is compared to the other boats to actually evaluate data that actually exists. Below you can see the view with interpolation off for some boats doing a mark rounding so you can see where we've paused the player is 0.2 seconds ahead of the closest GPS data points for the boats.

2. The main problem with (1) stems from RaceSense data being sparse due to the limited bandwidth of the mesh network and distance compounded by distance from RC.  But it doesn't have to be, high fidelity data is stored in each competitor's Atlas 2 device.  In the screeenshot above you'll notice the non-interpolated data shows extremely narrow deltas (.2s). That's because we didn't only use the RaceSense data that has sparse capture via the on the water mesh network, we each uploaded the VKX export from the session using the Vakaros Connect App.  That fills it in with data points every quarter second whether you're in range of RC tablet or not.  Getting that data though requires the competitor's Corinthian spirit in actually finding the truth so likelihood of that might differ between classes/events.  Personally though as a competitor, if we're participating in an event where we are required to have a working atlas 2 to as part of the rules and it's automatically calling OCS for us, I don't see why we shouldn't be also required to provide the non-sparse track data when requested for a hearing in the event.


How we've used the data so far:

Ignoring performance analysis, for the purposes of protests we've used it to evaluate our on the water judgement calls and come to agreements with the adversarial boats and avoid the room.  In other cases the data showed there was still uncertainty and it continued to the room.  Both I believe are valid outcomes and it required the different parties talking to each other and changing parameters to help make sense of the situation.  In this particular case it was a rounding of a government mark so there's not an atlas 2 device recoding it's true position at the moment of rounding.  So we started with some accepted facts like no one sailed on the wrong side of the mark or hit it, so the mark must be within the turning track of the three boats.  Then we have some reasonableness judgements like "this boat rounded tightly to the mark and they didn't sail past it 20m so we'll try out different mark locations within the bounds of "reasonableness" and see if any change the result of overlap and/or entrance order.  It helped us eliminate reasonable possibilities which is an important distinction between "we looked at it and it gave us the answer which we blindly accepted"  For example, it checks the overlap at all paired (closest time) GPS points in a 2s window in addition to the reading at the moment of entry.  This, along with visual display of how big the overlap was, can help give (or rightfully undermine) confidence in the at the moment of entry determination.

This all goes back to what's running at the core of this conversation though.  Track data is evidence the same way witness testimony is evidence.  I'd say it's wildly better at estimating distances even on a bad day  (I routinely hear people call the 3-boat length circle while there are literally four physical boats in a line between them and the mark) but it still need to be understood to be fallible and thus questions need to be asked like "if the recorded heading is off by 10 degrees or time of entry into the circle is different by a second in either direction does it reasonably change the result?".

There's still uncertainty, but it helps eliminate a lot of possibilities.

See discussion above.

Hitting an anchored boat may found a claim for damages, but does not break any IRPCAS rule.

Hitting a dock or pier, the same.

This one is worth answering directly, because you and the app agree and it wasn't letting you see that.

The rule 14 card only ever proposes one move — you hold your course — and asks whether holding it is legal. So on a card where the answer is "that's a foul", the app is saying exactly what you were saying: swift and decisive action was required and holding on wasn't good enough. It just never gave you the words for it, and it never told you that contact was actually coming, which left "surely she'll get out of the way" as a perfectly reasonable read of the picture.

The card now says so in the setup: she is not keeping clear, and you are going to hit her. What's left to judge is the rules question — rule 14's first sentence binds both boats all the time, so the interesting half is the second: a right-of-way boat need not act until it is clear the other one isn't keeping clear. When that stops being true is a real question, and it's the one the card is trying to ask.

Clearly placed there by a trimmer trying to share the guilt! ;0))

Thanks very much John. I appreciate your efforts in replying in so much detail.

Our annual program includes a Pointscore Series (Pursuit format; scratch -> biased towards slower boats) run every fortnight ( 15 races per season), Championship (Yardsticks; 2 races each day; 14 per season) and Sprints (Yardstick, 3-5 races per day; 24 say races per season) => run in turn every other week.  (so C-P-S-P each month).
 
We'll be running our annual October Regatta (6 Divisions) , Hobie States, Spiral Nationals + the International Canoe World Titles this year so we'll be busy, and having lots of fun and enjoyable times out on the Bay!

As Race Secretary I want to apply a common entrant list and a common set of rules for our club races. (KISS).  We are transitioning from a Cox-Sprague system to low-point (Sailres) next season. We have a meeting next week to decide on the rules.

After much research and simulations and yours, and others kind feedback, my preferred approach is DNC= Starters+4. I thinks the committee could settle on DNC = [12] which is starters + 4 for our average fleet size of 8-10. There is a group who want to keep the regatta approach of Entrants + 1.
 
We'll see who 'wins' the debate. Interesting Times (pun intended)! 

Cheers and Thanks again for all the great feedback. 
PS many clubs face similar issues and so it is worth discussing it here.