By: ValentinHirschi <valentin.hirschi@gmail.com>
fix amplitude and LU phase conventions
Return complete Feynman-rule amplitudes A_Gamma = -i M_Gamma, align the scalar
UFO and both JSON models, and use one marked-forward LU prescription across
bare terms, UV subtraction, causal threshold terms and computed exports.
Keep inverse-process RHS vertices intact instead of applying a second adjoint.
Apply the approved SM ghost/Goldstone Lorentz corrections in a scalar/vector-
axial basis; retain the verified three-gluon and fermion momentum signs.
Remove the redundant wrapped SM JSON. All 26 SM external inputs are real in
both vendored representations. Port generic anticommutating statistics from
upstream 6e92007a1d3e1a1202de590f01482224e1c21df6 to the current layout.
Validation: full 166-case scalar LU release matrix passes; all four signed
LO/NLO photon/lepton ddx/ttx benchmarks pass. Scalar Born multiplicities 2..6,
unit-numerator amplitude MC integrals through four loops, causal/iterated
threshold identities, generated sewing, exports, complex-mass/CP guards and
developed ghost UV references pass. All seven final reference cases pass
across targeted reruns. Rust/Ruff formatting, type checks and workspace
all-target Clippy pass. Numerator diagnostics preserve factorization.
Known limitation: the additional ttH UV Compare diagnostic still fails in
Symbolica tensor-index canonicalization; no expansion or equality bypass was
introduced. The separately audited W/Z gauge repair awaits approval. The
optional CP guard does not comprehensively diagnose arbitrary direct UFO
coupling phases; ordinary sewing requires Hermitian partner vertices.
Regenerate integrands and saved compiled gammaloop_state/ artifacts to obtain
the new phases. Loop-filter API/CLI names now refer to anticommutating loops.
See PHASE_CONVENTIONS_FIX.md and docs/architecture/phase-conventions.md for
the accepted revisions, evidence and remaining limitations.
User instructions (verbatim):
Prompt 1:
Alright, time to address and fix once and for all the phase issues conventions we have in gammaloop.
First we need to plan this by carefully and diligiently identifying what is currently the phase convention of our amplitude type of calculations in gammaloop and of our cross-section calculations in gammaloop.
Then we need to decide what is the actual phase convention we want to *impose*. For this the guidelines are as follows:
a) For amplitudes, the phase is of course not observable. Yet, I would like our convention to be such that if feyngen were to build an amplitude graph from a phi^4 UFO model, then our result for the MC integral of that graph is directly what enters the textbook "scattering amplitude", i.e. the quantity typically denoted `-i M`, ready to be squared to build the squared matrix element forming the cross-section.
Also reflect on what this imply for resulting phase returned by gammaloop when computing a topology loaded from a long graph where the user forced the numerator to be exactly one (i.e. a "scalar" loop), and supposing it has no threshold, so that the CFF integrand has a uniform phase and no integrated threshold CTs, so no source of imaginary part, For example would the phase in such an example keep switching at various loop count with the phase choice yielding `-i M` like requested above?
b) For the cross-section mode when handling forward scattering graphs, the desired phase requirement is much simpler and clearer: the cross-section must be real and positive when considering a case with no threshold once each Cutkosky cut is imposed with a symmetric left and right graph. (e.g. when reproducing the Born cross-section of x > y (even with y having many particles, so the forward-cross-section is multiloop)). Indeed, each of these symmetric Born-like cut corresponds to | A\_\Gamma |^2 which must corresponds to the norm of an amplitude graph and must be positive and real so the cross-section is positive and real. This works only processes with external scalars (otherwise for e.g. vectors, the unphysical spin-sum of -g^{\mu\nu} means that this property may not be realised per graph), but it's enough to fix the phase-choice. 
c) To get the property b) on must of course consider properly the complex-conjugation on the right of the cutkosky cut. This is currently properly applied only for the imaginary prefactor of the integrated threshold CT (i.e. the causal prescription of the propagators to the right of the cut). But we need to apply it to the numerator too. When using the currently implemented "complex\_conjugate()" on a tensor network, it is a bit over-eager as it really applies a CP transformation to the tensor network. It is not really wrong but it needlessly complexifies the algebra. However, now that we support the schoonship notation, it may be easier to do. I want you to add a new generation mode "complex\_conjugation" which has two modes "exact", "scalar\_only". In the "exact\_mode" (default) you faithfully call "complex\_conjugate" on the whole tensor numerator on the r.h.s of the cut (i.e. CP) and try to simplify the complications that appears before proceeding (so any (gamma^0)^2 should be set to 1 for instance) and then proceed. In "scalar\_only" mode, you only complexify the scalar coefficients of that r.h.s tensor, leaving all couplings whose current numerical value is real-values (at the time of the generation) untouched.
You must then verify that the phase requirement I mentioned for the LU cross-section result is now exactly met for various loop counts of a scalar LU cross-section (similar to the LU check of the test matrix but engineering only symmetric graphs with a single "born-like" cut of progressively higher multiplicity, where we know it must yield a positive and real cross-section no matter the loop count of the forward-scattering graph.
d) You'll be working and pushing to the branch "raised\_energy\_cff\_optimization\_phase\_fix" (not exact name, essentially I want the same as current name, but with suffix "\_phase\_fix")
Upon starting implementation of the plan, specify to write it verbatim in the file PHASE\_CONVENTIONS\_FIX.md, including a goal statement, and setting it to yourself as the goal.
In that plan, had an addendum that will include this user prompt here verbatim.
Prompt 2:
Ah and you can override the repo requirement to ask for permission to make changes to the tests and things like this because there may be many here.
Also ask questions if anything is unclear in the plan after investigation of course.
Prompt 3:
Continue elaborating the plan, but also make sure the conventions of the UFO model for the scalar theory (sign/phase of the prefactor of interaction feynman rules and sign/phase of the scalar propagator numerator is also matching text-book expectations).
Prompt 4:
Ah and also add to the plan than then you must run the ddx and ttx tests and verify that you get a positive real LO cross-section and also an NLO correction matching our published numbers, but this time not in absolute value (like the test currently tests) but with the correct sign without any corrective ad-hoc measure.
Prompt 5:
Ah and then of course add to the plan that when you're certain the phases are fixed according to my guideline, then all tests sensitive to that must be updated. I see you want to change the scalar model vendored in to match textbook conventions, this is fine indeed, but make sure then to update both the UFO and the json model there too.
Prompt 6:
Add to the plan that you should check both e+ e- > a > ddx / ttx and a^star > ddx / ttx results (incl. phase) in the tests.
Prompt 7:
Implement the plan.
Prompt 8:
(continue as planned, but you can safely assume that a model parameter declared "real" in the UFO will always remain real, the output would be invalidated otherwise, so at generation time it should be clear whether complex conjugation hits them or not (i.e. giving those symbols the attribute "real" should simply do the trick already actually))
Prompt 9:
But actually spin out a research agent too in order to really make a deep study of whether doing the complex-conjugation on the spin tensors on the r.h.s. of the cutkosky cut is really the correct things to do (i.e. it's not sort of already done somehow due to how the feynman rules and edge orientation works)
Prompt 10:
Wait this is important explain why it is wrong
Prompt 11:
OK then remove the request for the two "complex conjugation modes" then just keep the code doing one thing, but the *right thing* as you described. Do another deep research to really pin down what is the right thing to do there (also if we had complex-values coupling like off-diagonal CKM or in the complex mass scheme).
Prompt 12:
Ok but if it comes out that complex-valued couplings are difficult to support, then simply make sure that the code errors nicely if any are found in a cross-section and implement your solution for real-valued couplings.
Prompt 13:
Continue as planned, but also pay attention to the cut edges in cross-section, indeed one must be careful to overall obtain the correct interplay between the origin `i` in the propagator numerator and the corresponding scalar phase factors used within gammaloop when taking the cut of that propagator.
Anyway, in the end it must all play out to give the requirements we asked for, with principled handling of every source of phase.
Prompt 14:
Also launch a separate agent to do a deep investigation of derivative couplings in the SM. For SMQCD the only one is the three-gluon vertex, and my concern here is that I believe (but to be checked) that our convention is "all-incoming" for the meaning of a $$p^\mu$$ in the feynman rules, but I am not convinced that the way the three-gluon feynman rules, as well as the QCD ghost one (and others beyond QCD) is currently encoded in our SM model actually fits this convention in its choice of sign (e.g. vs literature).
This is delicate as we're talking about signs here, so the online literature authoritative result must be triple-checked, and then really dig into how our current momenta in the feynman rules is being interpreted in gammaloop and confirms that it is consistent. All such derivative couplings must be checked this way and if there is any mismatch requiring a change in the SM model, make sure to escalate those changes to me so that I can decide them to greenlight them or not.
Prompt 15:
Ah and also ask this agent to also double-check the sign of the momentum in the numerator of the fermion propagator (and anti-fermion). However there, I'm more confident that it's also correct (but it's tricky to get right!).
Prompt 16:
Wait what are the two SM JSON variants? There should only be one no?
Prompt 17:
Ah ok, well those should match exactly (only difference is indices wrapping). Actually I would just remove the sm\_wrapped version.
Prompt 18:
Yes this ALOHA mismatch is exactly what I'm afraid about, but look, in the end we don't use/care about aloha, so the only thing that you need to do is to really compare the textbook correct rules vs the ones in our SM model and its interpretation within gammaloop, to make sure it lines up. ALOHA can do whatever it wants, we don't care I think.
Prompt 19:
Continue as planned, but realise that for this phase-test you can generate a single orientation (with that cut contained), it does the job equally well to test the phase.
Prompt 20:
but even for the four-loop uncut topology you can select a single orientation.
Also make sure that you propagate any change you do to all generation modes and pieces (UV CTs, local and integrated threshold CTs, etc..) but ok this is likely automatic.
Prompt 21:
I think the diagram generator *does* include a negative sign for closed ghost loops! I implemented it generically on any anti-commutating field, and this includes both ghosts and fermions I believe!
Prompt 22:
Ok then indeed pull that upstream change here already.
Prompt 23:
Ok but also simplify all combinations of `P_L-P_R` (or `P_R-P_L`) so as to explicitly write them int the `gamma_5`-free form as it would otherwise cause problems in the d-dimensional regularization when doing d-dimensional gamma algebra to build vaking input.
Prompt 24:
Yes sorry, simplify `P_L+P_R` without gamma_5 but then for the differences, write them explicitly as gamma_5!
Prompt 25:
So essentially use the Vector vs axial decomposition, and not the chiral weyl decomposition.
Also does that mean then that you deemed our three-gluon current derivative coupling sign to be valid?
Prompt 26:
I'm not sure what you mean with: "The diagnostic now uses an exact unfactorized rational-polynomial comparison over \\(\mathbb Q(i)\\), preserving the phase check without that failing factorization step." but make sure you *NEVER EXPAND* the numerator.
Prompt 27:
(continue as planned, but of course also make sure that int he vendored SM, no input parameter that is meant to be real is declared as something else than real-valued).
Prompt 28:
Continue as planned, but can you now give a summary of what you fixed in the end, and also does your amplitude phase targets `M` or `-i M`? And finally did you check that now the LO and NLO contribution to bother ``gamma^\star > d dx / t tx` and `e+ e- > \gamma^\star > d dx / t tx`` come out with the right sign?
| Time to Start | Worker time | Duration | Time to finish | Idle | |
|---|---|---|---|---|---|
| Config | 1s | 2s | 2s | 3s | 1s |
| Eval | 4s | 1m29s | 1m29s | 1m34s | 0s |
| Build | 1m30s | 4h01m10s | 1h13m55s | 1h15m26s | 8s |
| Test | 32m43s | 29m35s | 49m44s | 1h22m28s | 0s |
| Deploy | - | - | - | - | 4h15m33s |
| Suite | 1s | 4h32m18s | - | - | 4h15m44s |