# API v1 CONTACT\_MAPS: native 2048-bp output units and documented positive-ratio mapping

**URL:** <https://www.alphagenomecommunity.com/t/api-v1-contact-maps-native-2048-bp-output-units-and-documented-positive-ratio-mapping/1009>\
**Category:** Help & Support\
**Created:** [November 11, 2026, 3:51pm UTC](https://www.alphagenomecommunity.com/t/api-v1-contact-maps-native-2048-bp-output-units-and-documented-positive-ratio-mapping/1009 "2026-11-11T15:51:59Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![libang\_wu](https://yyz2.discourse-cdn.com/watermelon/user_avatar/www.alphagenomecommunity.com/libang_wu/32/1437_2.png) [@libang\_wu](https://www.alphagenomecommunity.com/u/libang_wu)\
**Post date:** [November 11, 2026, 3:51pm UTC](https://www.alphagenomecommunity.com/t/api-v1-contact-maps-native-2048-bp-output-units-and-documented-positive-ratio-mapping/1009/1 "2026-11-11T15:51:59Z")

</div>

We are evaluating already-cached human CONTACT\_MAPS predictions from AlphaGenome API v1, using SDK 0.10.0 and ALL\_FOLDS (IMR-90 and GM12878). The returned signed values L are on the native 2048-bp grid. We are not requesting new predictions or access to raw training data.

Could you point us to a version-applicable specification or implementation that defines the units of L and the intended mapping f(L) to a positive, normalized contact signal on that same native grid? In particular, is the inverse exp(L), 2\*\*L, or another formula, and does it require an additional offset, scale, or other operation? What positive quantity does that mapping represent after the documented interpolation to 2048 bp and ALL\_FOLDS aggregation?

The metadata describes a log-fold change over a distance-dependent expectation, while the paper writes “log” without an explicit base. We have checked the v1 output declaration/decoder/proto, research contact head and prepared-target loader, and the official contact-map tutorial examples; these do not identify a version-bound inverse. A formula or a precise documentation/code link with its applicable API/model version would resolve the issue.

Our downstream use is positive-signal diamond insulation and boundary analysis, so selecting a base by comparing benchmark scores would be inappropriate. We only need a documented native-grid positive representation; we do not need unique recovery of raw counts, reconstruction of the original 1-kb map, or the original expected/pseudocount arrays. If no such positive representation is intended for API v1, please confirm that limitation instead.