# Credible set contains inconsistent NULLs in the locus column
**URL:** https://community.opentargets.org/t/credible-set-contains-inconsistent-nulls-in-the-locus-column/2056
**Category:** Community Feedback
**Tags:** data
**Created:** [14 July 2026 18:02 UTC](https://community.opentargets.org/t/credible-set-contains-inconsistent-nulls-in-the-locus-column/2056 "2026-07-14T18:02:15Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@Stepan\_Nersisyan](https://community.opentargets.org/u/Stepan_Nersisyan)
#### Post date: [14 July 2026 18:02 UTC](https://community.opentargets.org/t/credible-set-contains-inconsistent-nulls-in-the-locus-column/2056/1 "2026-07-14T18:02:15Z")
Hello,
I noticed that many credible sets have a problem, where `pValueMantissa` and `pValueExponent` columns contain non-NULL values, while when you look up the lead variant in the `locus` column, you see NULL values despite it’s the same variant. At the same time, `beta` always matches between the `beta` column and the corresponding value in the `locus` column. Example studyLocusId to reproduce: `c6a7aaa880e5ccbebb1ed0d52ecf5f9e`
You can see the bug both in the downloadable files and on the OT platform page. E.g., on [Credible set around 17\_42416098\_T\_C for UKB\_PPP\_EUR\_AARSD1\_Q9BTE6\_OID21311\_v1 | Open Targets Platform](https://platform.opentargets.org/credible-set/c6a7aaa880e5ccbebb1ed0d52ecf5f9e) (same locus as above), you can see P-value: 7.680×10-17 in the top widget, but NULL in the “Credible Set Variants” one.
---
### Author:  [@Daniel\_Considine](https://community.opentargets.org/u/Daniel_Considine)
#### Post date: [15 July 2026 10:26 UTC](https://community.opentargets.org/t/credible-set-contains-inconsistent-nulls-in-the-locus-column/2056/2 "2026-07-15T10:26:24Z")
Hi @Stepan_Nersisyan,
This is an artefact of our current fine-mapping/ingestion pipelines. Depending on whether the credible set is susie, susie-inf, or PICS, it may have different information available in the locus object for each variant. In the example you provided, it is a UKB-PPP credible set which we fine-mapped ourselves with susie-inf. This means that the ‘beta’ column represents the conditional beta from susie (and is available for every variant in the locus) but we only retain the P-value for the lead variant in our current pipeline.
This is something we are looking to improve moving forwards, where we hope to retain the P-value, univariate beta/se, and conditional beta/se for every variant in the credible set. However, this requires quite large changes to our schemas and pipelines, and has many consequences downstream. Therefore it’s something we can’t give an ETA for, but it is high on our list of priorities.
Hope this answers your question.
---
### Author:  [@Stepan\_Nersisyan](https://community.opentargets.org/u/Stepan_Nersisyan)
#### Post date: [17 July 2026 02:04 UTC](https://community.opentargets.org/t/credible-set-contains-inconsistent-nulls-in-the-locus-column/2056/3 "2026-07-17T02:04:50Z")
Hi Daniel,
This makes sense - I just want to re-emphasize that p-value for the **lead variant** is NULL in locus array and not NULL outside of the array, while it should be exactly the same value. This is slightly different issue from the fact that non-lead variants have no p-value, and could (IMHO) be classified more like data quality issue.
Would be great if you can put somewhere into documentation that statistics for the lead variant should not be taken from the locus array - this would help for use cases like mine, where I was “exploding” the locus array and thinking that it’d have exactly the same lead variant stats as the parental, non-locus columns.
Thanks for such a prompt reply!
---
### Author:  [@Daniel\_Considine](https://community.opentargets.org/u/Daniel_Considine)
#### Post date: [18 July 2026 15:23 UTC](https://community.opentargets.org/t/credible-set-contains-inconsistent-nulls-in-the-locus-column/2056/4 "2026-07-18T15:23:12Z")
In our current SuSiE-inf pipeline the locus objects are generated directly from the raw susie output, which doesn’t include P-values. For our downstream pipelines/frontend the only P-value we consider is that of the lead variant, which we retain outside of the locus array. This is why we originally didn’t append the original P-values back to every variant (including the lead) in the locus object.
I completely understand how this is inconvenient for a use case like you described though. This is one of the reasons we are looking to improve the data model, and ensure all credible sets have consistent/complete information.
I’ll be sure to give you a notification when we have updates to this 👍