Thanks. The data levels profile clips, so the monitor expects video levels over HDMI. It probably has a bit of headroom in terms of gamut that it taps into when it is fed data levels, these obviously cannot be used (unless you can change that via the monitor’s OSD?) but it would explain the slightly larger gamut.

Where does the colorimeter correction you’re using come from? Do you have a spectro?

What you should do is match the monitor’s white to a known reference to overcome issues with metameric failure, i.e. use DisplayCAL’s visual whitepoint editor (set whitepoint on the calibration tab to “Chromaticity”). Unfortunately the visual whitepoint editor currently does not do adjustments over Resolve directly (it can still be used to measure the adjusted white), so you have to find a different way (grade a white patch in Resolve until it matches your reference, then use the visual whitepoint editor to measure it maybe?). Once you’ve adjusted the monitor’s white to match your reference, and measured it using the whitepoint editor, it will be set as calibration target. On the 3D LUT tab, you need to enable “apply vcgt” and set rendering intent to relative colorimetric.

It’s the 2016-04-09 00:52:00 one for UP2716D from the database (the one from the 13th seems bad). Sadly no spectro at the moment.

Just keep in mind all the corrections from the online database are user-contributed. They may or may not improve the accuracy of your colorimeter with your display.

When the initial readings to measure gamut are taken, other than slightly for blue, doesn’t the gamut exceed the 709 colourspace even at video levels by some margin, and if so

Not sure what you mean by “initial readings”, but gamut is determined by all the readings on the ‘hull’, as it’s a 3D volume. And yes, the gamut is technically larger in volume than Rec. 709, but as you can see from the 3D view, some parts of Rec. 709 (the wireframe) are not covered, it ‘sticks’ outside the display gamut.