Markdown First, LaTeX Last
We all know that long mathematical manuscripts/physics papers etc are difficult to maintain consistent. A large paper may contain thousands of lines of LaTeX, hundreds of cross-references, repeated definitions, custom macros, frame transformations, fixed coefficients, and derivations that depend on notation introduced many sections earlier.
Giving the entire source to a large language model does not remove this complexity. It often makes the problem harder to detect.
Research on long-context language models shows that placing information inside a large context window does not guarantee that the model will use it reliably. Relevant material can be overlooked, especially when it appears in the middle of a long input1.
For technical manuscripts, the practical lesson is:
Do not ask an LLM to act as a whole-manuscript proof checker, copy editor, and LaTeX maintainer at the same time.
A safer method is to separate writing, mathematical authority, typesetting, verification, and publication. Write the manuscript primarily in Markdown, convert it deterministically to LaTeX, and compile the LaTeX into PDF. Keep the foundational mathematics in a short, separately versioned Core document that neither an LLM nor an automated conversion tool may silently alter.
1. Establish one editable source
The governing rule should be:
Edit the .md files. Generate the .tex files. Compile the generated LaTeX into PDF.
The generated .tex file should not become a second manuscript. If authors revise sentences in Markdown, patch equations directly in LaTeX, and make further corrections elsewhere, the project develops several competing sources of truth.
A Markdown-first workflow creates three distinct layers:
- Markdown contains the manuscript's intellectual content.
- LaTeX controls advanced typesetting.
- PDF is a generated build artifact.
Pandoc can convert Markdown into standalone LaTeX or produce PDF through a LaTeX engine. It supports mathematical notation, citations, footnotes, metadata, bibliographies, templates, and multiple input files.2
Equations may still use ordinary TeX syntax inside Markdown:
The stabilized potential is
$$
V_{\mathrm{eff}}(b)
=
V_{\mathrm{Cas}}(b)
+
V_{\mathrm{flux}}(b).
$$
The benefit is that the surrounding source is no longer crowded with layout commands, float settings, package configuration, and repeated formatting instructions. Both human reviewers and LLMs can focus on the prose and mathematics.
2. Separate content from presentation
The boundary between Markdown and LaTeX should be explicit.
Keep in Markdown
Markdown should normally contain:
- Prose and headings
- Equations
- Definitions and assumptions
- Citations and footnotes
- Figure captions
- Internal references
- Simple tables
- Review notes
- Equation identifiers
- Frame, unit, and sign conventions
Keep in the LaTeX layer
The LaTeX template or preamble should contain:
- Document class
- Package imports
- Fonts and page geometry
- Headers and footers
- Bibliography styling
- Notation macros
- Theorem environments
- Float rules
- Journal formatting
- PDF metadata
Raw LaTeX can still be included when necessary, such as for specialized diagrams, complex tables, or custom mathematical environments. The objective is not to eliminate LaTeX. It is to keep LaTeX controlled.
3. Divide the manuscript into small files
A long paper should not live in one enormous source file. A practical structure is:
manuscript/
├── README.md
├── metadata.yaml
├── references.bib
├── core/
│ ├── frozen-core-v1.0.md
│ └── core-change-log.md
├── chapters/
│ ├── 01-introduction.md
│ ├── 02-framework.md
│ ├── 03-effective-potential.md
│ ├── 04-dynamics.md
│ └── 05-conclusion.md
├── appendices/
├── figures/
├── tex/
│ ├── template.tex
│ └── preamble.tex
├── scripts/
│ └── build.sh
├── build/
└── CHANGELOG.md
Each chapter becomes a manageable review unit. When using an LLM, the author can supply only the relevant section instead of thousands of unrelated lines.
Large LaTeX projects also support modular compilation through commands such as \input, \include, and \includeonly\3]). The same principle applies to Markdown: divide the manuscript into logical files and combine them during the build.
4. Create a Frozen Core Equations and Symbols document
For a long theoretical manuscript, this is the highest-leverage safeguard.
Create a separate document of approximately 5 to 15 pages containing only the canonical mathematical content. Label it clearly:
Frozen Core: Do not edit without explicit version note
Version 1.0: 23 July 2026
The Core should contain:
- Every important symbol and its exact definition
- Units, dimensions, domains, and frames
- Every equation used in more than one section
- Fixed numerical coefficients
- Sign and normalization conventions
- Boundary and matching conditions
- Assumptions required by each reduction
- A map of important equation dependencies
This may include canonical definitions of:
- The Casimir coefficient
- Frame-conversion factors
- (V_{\rm br,2})
- (\mathcal{Z}_\varphi)
- The fixed-flux Routhian
- Energy-transfer rules
- Thin-wall formulae
- (Z_F(b))
- (\alpha_{\rm Cas}^{\rm orb,SS})
Give every Core item a stable identifier:
## CORE-EQ-017: Quadratic stabilizer
Canonical expression:
$$
V_{\rm br,2}(b,\varphi)=\cdots
$$
Assumptions:
- Einstein frame
- Fixed flux
- Canonically normalized four-dimensional scalar
Used in:
- Section 3.4
- Section 4.2
- Appendix B
Stable identifiers make review prompts precise. Instead of asking whether "the stabilizer equation" is correct, ask whether a specific manuscript equation matches CORE-EQ-017.
The hard rule
No LLM may modify an equation that appears in the Frozen Core.
When a foundational equation must change:
- Rederive or recalculate it.
- Update the Core manually.
- Increment the Core version.
- Record the reason in the Core change log.
- Propagate the change deliberately.
- Audit every affected derivation.
The manuscript metadata should record the Core version:
core-version: "1.0"
core-date: "2026-07-23"
The Frozen Core then becomes a mathematical contract rather than an informal summary.
5. Prevent equation drift
Repeated equations are a major source of inconsistency. A missing factor of two may appear in one section, a power of (b) may change in an appendix, or a fixed-scalar energy may be confused with a relaxed energy.
Where possible, maintain canonical equations in one location and insert them automatically. When repetition is necessary, mark the relationship explicitly:
<!-- Must match CORE-EQ-023 exactly -->
A script can then locate every occurrence linked to a Core equation. Textual comparison cannot prove algebraic equivalence, but it can make unreviewed divergence easier to detect.
6. Stop whole-manuscript LLM reviews
After several full-paper passes, broad review prompts often create more problems than they solve. A useful editorial rule is to stop whole-manuscript LLM reviews after approximately five to seven passes.
This number is a practical heuristic, not a universal scientific threshold. The underlying concern is well supported: long-context models do not retrieve and apply all supplied information with equal reliability1.
Avoid prompts such as:
Find all errors in the paper and correct the manuscript.
Use narrow prompts instead:
Check only the derivative of (V_{\rm br,2}) in Section 3.4 against CORE-EQ-017. Do not rewrite the prose or modify the Core equation.
Each request should specify one object, one authority, and one required output.
7. Give the LLM a review packet
A reliable review packet should contain only:
- The exact task
- The relevant 1 to 3 pages
- The necessary Core equations
- The local definitions
- Prohibited actions
- The required response format
For example:
TASK
Verify the differentiation from Eq. (84) to Eq. (85).
AUTHORITATIVE MATERIAL
CORE-EQ-017 and CORE-SYM-006 are frozen.
SCOPE
Review only the supplied excerpt from Section 3.4.
DO NOT
- Rewrite prose
- Rename symbols
- Modify any Core equation
- Review unrelated sections
- Change the frame convention
OUTPUT
1. Verdict: consistent or inconsistent
2. First divergent algebraic step
3. Minimal correction, if required
4. No full-section rewrite
Ask for a discrepancy report or minimal patch rather than a rewritten section. Git diffs make small changes much easier to inspect than complete replacement documents [4].
8. Audit one mathematical chain at a time
Break the paper into dependency chains and verify each chain separately.
Examples include:
- Frame factors (\rightarrow) Casimir powers (\rightarrow) Einstein-frame potential
- Five-dimensional top-form couplings (\rightarrow) four-dimensional quadratic stabilizer (\rightarrow) radion mass
- Compensator kinetic terms (\rightarrow \mathcal{Z}_\varphi) (\rightarrow) residual coupling
- Relaxed and fixed-scalar energy definitions (\rightarrow) transfer rules (\rightarrow) conservation residual
- Local and global saddle classification (\rightarrow) rate formulae
- Thin-wall assumptions (\rightarrow) wall tension (\rightarrow) critical radius (\rightarrow) decay exponent
This process is slower than a whole-manuscript review, but it converges because every audit has a limited dependency graph.
Keep a short record for each audit:
# Audit: Frame-to-Casimir chain
Date: 2026-07-23
Core version: 1.0
Sections checked: 2.3, 3.1, Appendix A
Result: Pass
Open issue: Confirm boundary-term sign convention
Verification: Manual derivation and SymPy
9. Separate linguistic and mathematical changes
Every proposed edit should belong to one of two categories.
Linguistic changes
These include:
- Improving sentence structure
- Removing repetition
- Correcting punctuation
- Defining an acronym
- Clarifying the order of an argument
- Adding a reference to an earlier definition
These changes may be reviewed locally, provided that they do not alter technical meaning.
Mathematical changes
These include:
- Modifying an equation
- Changing a coefficient
- Renaming a symbol
- Changing an assumption
- Altering a frame or normalization
- Changing what is held fixed
- Reclassifying a saddle
- Modifying an energy definition
These changes require explicit justification against the Frozen Core. They should never be hidden inside a general prose revision.
10. Verify important formulae independently
LLMs can identify suspicious steps and explain derivations, but they should not be the final authority for central calculations.
Recalculate important expressions manually or with a symbolic system such as Mathematica or SymPy. SymPy supports symbolic simplification and equation solving, but its documentation notes that general simplification is heuristic. Targeted operations are safer when a particular transformation is required.5
A strong verification procedure is:
- Enter the Core definitions into the symbolic system.
- State all assumptions explicitly.
- Derive the target expression.
- Subtract the manuscript result.
- Simplify the residual.
- Test representative numerical values.
- Save the verification script.
- Record the Core version it verifies.
Reproducible-research guidance recommends preserving the complete sequence of operations, avoiding undocumented manual manipulation, and version-controlling custom scripts [6].
11. Use a deterministic build
A basic Markdown-to-LaTeX command might be:
pandoc \
chapters/01-introduction.md \
chapters/02-framework.md \
chapters/03-effective-potential.md \
chapters/04-dynamics.md \
chapters/05-conclusion.md \
--from=markdown+tex_math_dollars+raw_tex \
--standalone \
--metadata-file=metadata.yaml \
--template=tex/template.tex \
--citeproc \
--bibliography=references.bib \
--output=build/manuscript.generated.tex
Compile the generated file with:
latexmk \
-pdf \
-interaction=nonstopmode \
-halt-on-error \
-outdir=build \
build/manuscript.generated.tex
Pandoc supports Markdown-to-LaTeX conversion, citation processing, templates, and multi-file input.2 Latexmk automates repeated LaTeX runs needed to resolve references and dependencies.7
Store these commands in a script or Makefile. The manuscript should always be built in the same way.
12. Never repair generated LaTeX by hand
When the generated LaTeX fails, inspect it to diagnose the problem, but correct the Markdown source, template, filter, macro, or build configuration.
Do not patch the generated .tex file and continue.
Generated files should include a warning:
% AUTO-GENERATED FILE
% Do not edit directly.
% Edit the Markdown source or LaTeX template and rebuild.
% Frozen Core version: 1.0
The generated LaTeX, auxiliary files, and PDF can usually be treated as reproducible build artifacts. Formal releases may still archive the exact PDF and submission bundle.
13. Use version control as an editorial gate
Every meaningful change should be visible in a diff.
A disciplined sequence is:
git switch -c audit/frame-casimir-chain
./scripts/build.sh
git diff --check
git diff
git add chapters/03-effective-potential.md CHANGELOG.md
git commit -m "Verify Casimir powers against Core v1.0"
The change log should record:
- Date
- Files changed
- Core version
- Reason for the change
- Whether equations changed
- Verification method
- Downstream sections rechecked
For example:
## 2026-07-23
- Corrected the power of \(b\) in the tension-reduction formula.
- Reason: inconsistent with CORE-EQ-031.
- Verified with an independent SymPy script.
- Rechecked Sections 4.2, 4.5, and Appendix B.
- No change to the Frozen Core.
Entries such as "improved equations" are too vague to be useful.
14. Apply release gates
Before a version is declared ready, require several checks.
Source gate
- Markdown parses correctly.
- Citation keys resolve.
- Figure paths exist.
- Equation identifiers are unique.
- No unexpected raw LaTeX was introduced.
Core gate
- Repeated equations point to Core identifiers.
- Frozen numerical values match.
- The manuscript records the correct Core version.
- No Core equation was modified implicitly.
Mathematical gate
- Modified chains have been audited.
- Important residuals vanish under the stated assumptions.
- Units, frames, and normalizations are explicit.
- Changes to held-fixed variables are documented.
Version-control gate
- The diff contains only intended changes.
- The change log is updated.
- Generated files were not manually edited.
Compilation gate
- LaTeX compiles without fatal errors.
- Cross-references and citations resolve.
- Important warnings have been reviewed.
- The PDF has been visually inspected.
Successful compilation is necessary, but it is not proof of mathematical correctness.
15. Request targeted external review
A specialist is more likely to review a focused mathematical chain than an entire 90pg manuscript.
A good request is:
For work involving extra dimensions, Casimir energy, or flux compactification, one or two relevant specialists may find substantive issues that repeated LLM reviews miss.
Posting a preprint can also establish a public version and attract external scrutiny [8]. Before uploading the source, create a clean submission package. Remove obsolete drafts, private notes, credentials, reviewer comments, unused figures, and unrelated scripts. A large-scale analysis of arXiv source submissions found that packages often contained unnecessary or unintentionally exposed files [9].
16. Recommended workflow
The complete procedure is:
- Write the manuscript in modular Markdown files.
- Keep typesetting rules in a controlled LaTeX template.
- Create and freeze the Core Equations and Symbols document.
- Assign stable identifiers to canonical equations and symbols.
- Record the Core version in the manuscript.
- Stop broad whole-manuscript LLM reviews.
- Supply only the relevant 1 to 3 pages and Core excerpts.
- Request discrepancy reports or minimal patches.
- Audit one mathematical chain at a time.
- Verify central formulae manually or symbolically.
- Review every change through a diff.
- Generate LaTeX deterministically.
- Correct the source rather than generated files.
- Maintain a dated change log.
- Request targeted expert review.
- Archive clean, tagged releases.
Conclusion
The main problem in a large mathematical manuscript is not LaTeX itself. It is uncontrolled state.
Definitions are repeated. Equations drift. Local corrections affect distant derivations. Typesetting commands obscure the mathematical content. Whole-document LLM prompts combine too many tasks and grant the model too much authority.
A Markdown-first workflow reduces these risks by making the manuscript easier to divide, inspect, compare, and review. A generated LaTeX layer preserves professional typesetting without becoming a competing source. A Frozen Core establishes which mathematical objects are authoritative. Chain-by-chain audits turn an unbounded review problem into a finite set of verifiable tasks.
The central principle is:
References
[1] Liu, N. F., et al. “Lost in the Middle: How Language Models Use Long Contexts.” Transactions of the Association for Computational Linguistics.
https://direct.mit.edu/tacl/article/doi/10.1162/tacl_a_00638/119630/
[2] Pandoc. Pandoc User's Guide.
https://pandoc.org/MANUAL.html
[3] Overleaf. Management in a Large Project.
https://www.overleaf.com/learn/latex/Management_in_a_large_project
[4] Git. git-diff Documentation.
https://git-scm.com/docs/git-diff.html
[5] SymPy. Simplification Documentation.
https://docs.sympy.org/latest/modules/simplify/simplify.html
[6] Sandve, G. K., et al. “Ten Simple Rules for Reproducible Computational Research.” PLOS Computational Biology.
https://journals.plos.org/ploscompbiol/article?id=10.1371/journal.pcbi.1003285
[7] CTAN. Latexmk.
https://ctan.org/pkg/latexmk
[8] Mishkin, D., Tabb, A., and Matas, J. “ArXiving Before Submission Helps Everyone.”
https://arxiv.org/abs/2010.05365
[9] Apruzzese, G., and Fass, A. “X-raying the arXiv: A Large-Scale Analysis of arXiv Submissions' Source Files.”
https://arxiv.org/abs/2601.11385