Skip to content

[P2 theory/analysis] Map-resolved torus tomography: fit modular-covariance solution spaces, not isolated shape rays #585

Description

@LightChainr

Trigger

The recent modulus program has done something useful by failing.

The next theoretical response should not be to add a longer list of isolated functions of tau.

Recent loop-model work gives a more appropriate object: a modular-covariant solution space labelled not only by fields but by connectivity/combinatorial-map data.

External input

Roux--Ribault--Jacobsen, arXiv:2604.24491, construct torus one-point functions in critical loop models using sphere four-point data. For the simplest primary insertions they find multiple modular-covariance solutions rather than one universal scalar shape; the torus functions are infinite non-chiral conformal-block combinations and the correlation function includes a combinatorial-map/connectivity pattern as part of its definition.

This continues the program of Grans-Samuelsson et al., arXiv:2302.08168, where ribbon/combinatorial maps organize loop-model correlation functions and bootstrap solution spaces.

Ang et al., arXiv:2604.05503, now supplies exact generic-loop three-point structure constants for many charged leg fields, so surviving map/charge sectors can eventually be tied to OPE data rather than only fitted as arbitrary torus functions.

The practical lesson is:

The correct torus hypothesis may be a low-dimensional subspace of map-resolved modular-covariant solutions, not one ray such as E4, r, or a single logarithmic block.

Primary question

For the exact lattice observable being measured, what is the smallest symmetry-allowed torus solution space that survives existing modulus data?

Write schematically

y(tau) = sum_a c_a F_a(tau),

where each F_a is a declared modular-covariant/map sector and the coefficient vector is constrained by exact lattice symmetries/selection rules.

The first result should be the dimension and identity of the allowed solution subspace, not a named continuum field.

Phase A — no new Monte Carlo: build the candidate sector dictionary

Start from already-measured torus/modulus assets only.

For each candidate sector record:

field/representation label when known,
combinatorial-map/connectivity label,
spin and C4/D4 transformation,
primal/matching parity when defined,
deck/homology character compatibility,
modular covariance law,
known logarithmic/non-chiral block content,
which existing lattice observable could realize it.

Use exact repository constraints aggressively:

If no credible lattice-to-map dictionary exists for a candidate solution, do not include it merely because its numerical shape is convenient.

Phase B — score subspaces, not ratios

For every existing modulus block retain the raw correlated response vector and full covariance. Compare a candidate sector space V by

D = min_a (y - V a)^T S^+ (y - V a),

using #579's projective/subspace machinery.

This has three advantages:

  1. no amplitude denominator is nominated;
  2. a legitimate two-sector continuum hypothesis is tested as a two-dimensional space rather than as an arbitrary fitted ratio;
  3. a known systematic direction can be carried as a nuisance column instead of deleting the coordinate that could falsify it.

Report identifiable rank and degrees of freedom explicitly.

Phase C — held-out modulus tomography

A multi-dimensional solution space only becomes informative if it predicts something not used to choose its coefficients.

Use the existing modulus ladder in a leave-one-modulus-out design where possible:

fit amplitudes/map mixture on source moduli,
freeze the solution subspace,
predict the full held-out response vector.

If current data have too few independent moduli, identify the one next modulus that maximizes principal-angle separation between surviving solution spaces. Do not default to another larger aspect ratio.

The held-out target can also be a different exact symmetry projector, e.g. a C3 homology character, if it is genuinely tied to the same continuum sector.

Phase D — exploit the sphere--torus relation

A particularly strong outcome of arXiv:2604.24491 is that torus modular covariance is related to sphere four-point crossing in a corresponding channel/map description.

For any torus sector that survives:

  1. identify the associated sphere four-point solution/map;
  2. construct a lattice sphere/plane four-point observable with the same connectivity semantics if feasible;
  3. compare a normalization-free cross-ratio vector or OPE ratio.

This creates an independent geometric test of the same sector. A torus fit that has no consistent sphere crossing realization should be downgraded.

Phase E — interface to exact three-point/OPE data

Do not rerun the old broad charged tables merely because exact 2026 OPE constants exist.

For a surviving map/charge sector, build an insertion faithful to the generic-loop field V_(r,s) and compare normalization-independent structure constants from arXiv:2604.05503. The target is

map/representation tensor
+
scaling dimension/spin
+
normalized OPE coefficient,

not another one-point amplitude.

This is the appropriate point to connect to #250.

What this changes about the current modulus program

It does not rescue a rejected ray automatically

A failed E4/weight-4 ray remains failed. Enlarging to a solution space is justified only by a concrete map/representation sector, not by post-hoc basis expansion.

It changes the meaning of high rank

Several torus solutions or combinatorial-map sectors can contribute to one scalar lattice projection. A multi-dimensional modulus response need not mean many unrelated irrelevant exponents.

It makes angular calibration prior to field identification mandatory

#583 should first establish what angular Fourier content is actually being measured. A torus solution-space fit should consume calibrated angular coordinates rather than ask continuum amplitudes to absorb an incorrect A4 extraction.

Decision table

One map-resolved ray survives held-out moduli

Promote a specific torus sector and demand its sphere/OPE fingerprint before operator naming.

A small map-resolved subspace survives, one-dimensional rays fail

Interpret the observable as a mixture/solution-space projection. Use exact symmetry/charge readouts to separate the components rather than adding more radial sizes.

The required subspace dimension grows with every modulus

Downgrade low-dimensional torus closure. Move to annulus/context-Hankel/process descriptions rather than a larger list of modular functions.

No candidate has a defensible lattice-to-map dictionary

Stop scalar modulus production. Design a marked/charged/connectivity-resolved observable whose combinatorial-map semantics are explicit.

Claim boundary

  • A modular-covariant solution is not by itself a field identification.
  • A combinatorial-map label is part of the correlation-function definition, not evidence of extra microscopic degrees of freedom.
  • Fitting a larger subspace after reveal is exploratory until it predicts a held-out modulus/readout.
  • Existing N=290/N=580 views remain the same evidence blocks under reanalysis.

Deliverable

1. map/representation/symmetry candidate dictionary;
2. numerical basis for the smallest relevant torus solution spaces;
3. covariance-weighted projective/subspace scores on existing moduli;
4. leave-one-modulus/readout-out predictions;
5. ranked next modulus or marked-observable design;
6. sphere/OPE cross-check for any surviving sector.

Literature anchors:

  • Roux, Ribault, Jacobsen, arXiv:2604.24491.
  • Grans-Samuelsson et al., arXiv:2302.08168.
  • Ang et al., arXiv:2604.05503.
  • Jacobsen, Nivesvivat, Ribault, Roux, arXiv:2510.04701.

Related: #114, #156, #220, #244, #249, #250, #333, #337, #576, #579, #583.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    priority:P2Deferred research or on-demand support; no default new compute allocation.

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions