ProRes 422 should normally be encoded and interpreted as video level, aka legal range, not data level aka full range. The licensed ProRes encoders I've seen normally do this. If the file was created by an unlicensed encoder such as FFMpeg and derivative implementations, then anything is possible.
However, there are licensed encoders, such as on Atomos devices, that give users a selectable option to encode at the video level vs. the data level. If the Atomos “legalize vs full” setting doesn’t match what the camera is sending and what post expects, you get a levels mismatch.
Likewise, if a post-production person mistakenly thinks a recording is at the wrong level and (without proper inspection and understanding) changes the level, that could burn in a multiply-stacked incorrect encoding level.
There is another set of issues related to some log formats such as S-Log3 that Sony defines as data levels, yet they are sometimes placed inside a ProRes 422 container which is traditionally defined as video levels. It is further complicated by the levels spec itself being contaminated by an error in an early version that has led to two different level metadata values, one at the essence level and one at the container level.
Looking at an NLE waveform is not always reliable when checking levels. If it shows (say) 109 IRE, that doesn't mean the file is encoded for that. It could instead be incorrect metadata influencing the waveform depiction. The waveform shows the signal as interpreted by the NLE, after it’s already made a decision about whether the clip is legal or full (and after any color management). So you can’t reliably infer the original encoding just from what NLE scopes show.
It's better to examine the code values using a tool like QCTools or a Nobe OmniScope. QCTools is free and can scan the file and present the high and low code values, which, when combined with examining the file metadata with MediaInfo, enable insight into whether the file is properly encoded.
In FCP if you have a ProRes file that seems recorded at the wrong level, you can compensate from full to video or video to full using the free Leeming LUTs designed for this. Those can be located by Googling "leeming lut fixie". Those are 64-point 3D LUTs.
That said, level-shifting LUTs can be a band-aid, not a root-cause fix. It's better to have a DIT, video engineer or experienced post-production person trace the problem back to the source: camera output settings, recorder legal/full toggle, and NLE project/color-management configuration. Otherwise, you risk shipping files where the metadata claims one thing, the actual numbers do another, and multiple “compensations” have been baked in on top of each other.
If the situation is not a downstream flow from ingest to editorial to VFX, but an upstream flow from VFX back to editorial, that is generally in an NLE-friendly format such as ProRes 4444/4444 XQ that FCP can play without issue.
The definitions for the assets that flow down and up the pipeline should be determined by a written spec. That spec is informed by other longstanding common practices. E.g, ARRI says: "Apple specifies that ProRes should be legal range. Our tests have shown that an extended range ProRes file can result in clipping in some Apple programs.” That is why ARRI cameras always encode ProRes (including 4444) in video levels, not data levels.
If the post-production workflow spec says: “ProRes 4444 XQ, Rec.2020 PQ, legal Y′CbCr,” then everyone lives in that world.
If the spec says “ProRes 4444 XQ, RGB, ACEScct, full-range,” then editorial/grade know that in advance and get configured accordingly.
But nothing should ever come back from VFX in some non-specified format that leaves editorial to deal with it. If it's not in the right format, then editorial talks to VFX to work that out.
