LaTeX
Enable an AI agent to recognise a LaTeX document system, assess whether its sources can produce the intended document reliably, and decide which editing, compilation and distribution actions are appropriate.
Research draft, second pass
A second pass drafted this model: the structure a model of this thing needs, and what is known about it in the world. The line under this one says how the second half was obtained - researched against sources, or recalled without web access, in which case nothing here was read anywhere and every claim is a lead to verify. Unreviewed either way.
Researched by: Codex + Grok
Purpose and description
Enable an AI agent to recognise a LaTeX document system, assess whether its sources can produce the intended document reliably, and decide which editing, compilation and distribution actions are appropriate.
LaTeX is a document-preparation system and macro package for TeX that lets authors describe the logical structure of a document so a typesetting engine can produce high-quality, consistently formatted output, especially for mathematics, scientific papers, and other structured publications.
It can be Identify the document entry point and distinguish authored files from generated intermediates.; Inspect and revise document structure, mathematical markup and custom macros while respecting class and package interfaces.; Resolve build requirements and run an authorised compilation workflow.; Diagnose compilation errors, unresolved references and typesetting defects.; Assess whether generated output satisfies the specified layout, accessibility and submission requirements.; Prepare a source handoff with the dependencies and build instructions needed to reproduce the document..
Distinguishing features
A .tex extension alone is insufficient: recognition requires evidence that the source targets the LaTeX format, such as document-class selection and a LaTeX document environment, or depends on a parent project that does.
LaTeX source expresses document structure and typesetting instructions through commands and environments; it is distinguishable from plain TeX by its reliance on LaTeX conventions and interfaces.
A rendered PDF is an output, not sufficient evidence of an available LaTeX source project or its build requirements.
A TeX distribution supplies engines and packages, while LaTeX is the document preparation system used through those components; the installed distribution and the document's required format must be distinguished.
Markdown or other source converted into LaTeX has a separate authoring origin; generated LaTeX must be distinguished from the source an agent is expected to edit.
Scope
+ Identification of LaTeX source and its intended document entry points
+ Document classes, packages, custom macros and their interactions
+ Semantic document structure, mathematical notation and cross-references
+ Engine requirements, bibliography and indexing workflows, and build dependencies
+ Compilation state, typesetting quality and source-to-output traceability
+ LaTeX-specific constraints on safe execution, collaboration and submission
- TeX engine internals and general programming-language semantics
- The correctness or evidential quality of the document's subject matter
- PDF format internals and general PDF editing
- General version-control, storage and software supply-chain management
- Independent models of fonts, images, datasets and other embedded assets
- Publisher business processes and editorial decisions
Characteristics
- Source role
- document entry point | included fragment | class | package | generated source Determines whether a file should be compiled directly, edited locally or changed through its upstream generator.
- Document class
- class name, options, origin and required version when known Establishes document conventions and constrains compatible layout changes.
- Required compilation engine
- pdfTeX | XeTeX | LuaTeX | other specified engine | unresolved Engine choice affects command support, font handling and package compatibility.
- Dependency resolution
- resolved | missing | conflicting | unverified A source tree cannot be judged buildable without its required classes, packages and external inputs.
- Build convergence
- not attempted | failed | rerun required | converged under recorded checks A successful engine invocation may still leave references, citations or generated lists incomplete.
- Unresolved references and citations
- count from the latest identified build Exposes broken links between document elements and incomplete bibliography processing.
- Typesetting diagnostics
- counts of overfull and underfull boxes, with locations and review status Identifies layout areas requiring inspection without treating every warning as an output defect.
- External execution requirement
- none identified | restricted execution required | unrestricted execution required | unknown Determines whether the intended build fits the available execution permissions.
- Output freshness
- matches recorded inputs | stale | provenance unknown Prevents an agent from judging or delivering output produced from an earlier source state.
Where this came from
wikidata · CC0 1.0
Also registered as vr.tr.latex
Drafted structure
Bundle to layer to finding to question, as the second pass will find it: 6 bundles · 11 layers · 18 findings · 28 questions.
Source identity and boundaries Establish what constitutes the LaTeX project and which files control the intended document.
LaTeX projects can contain multiple documents, reusable extensions and generated fragments whose editing and compilation roles differ.
Document entry points
Recognise the LaTeX format and locate compilable document roots.
LaTeX format and root evidence
Record the evidence that a source targets LaTeX and identify the root used for each intended output.
- Which commands, environments or parent-project declarations establish that this source targets LaTeX rather than plain TeX or another format? definition
- Which file is the entry point for each intended document, and which files are included fragments? boundary
Source authority
Distinguish editable source from generated content and externally maintained templates.
Authored and derived files
Identify where durable edits belong and where changes would be overwritten or break template expectations.
- Which .tex, .cls and .sty files are authored here, supplied externally or generated from another source? provenance
- Should the requested change be made in LaTeX source, an upstream generator or an allowed template customisation point? action
Document semantics and macros Capture how LaTeX markup expresses the document's structure and recurring notation.
Visually similar output can arise from structurally different markup, with different consequences for editing, numbering and reuse.
Structural markup
Assess the use of sectioning, environments, counters and labels.
Structure and reference integrity
Record how logical document elements are declared, numbered and referenced.
- Which commands and environments represent sections, figures, tables, equations and theorem-like statements? definition
- Which labels are duplicated or unresolved, and where does manually written numbering bypass LaTeX counters or references? measurement
Notation and command interfaces
Understand custom macros and mathematical markup before changing their definitions or uses.
Macro contracts and mathematical intent
Record the arguments, expected contexts and document-wide effects of recurring commands.
- Which custom commands encode recurring concepts or notation, and what arguments and text or math contexts do they require? definition
- Would changing a macro definition preserve its existing uses, spacing, numbering and behaviour in headings or captions? action
Class, package and engine contract Establish the LaTeX components and compatibility constraints that govern compilation and presentation.
A document's behaviour depends on the selected class, package interactions and engine capabilities, not source text alone.
Class and package composition
Identify the loaded extensions and the interfaces they expose or override.
Extension compatibility
Record class options, package options, loading order and relevant command redefinitions.
- Which class and packages are loaded, including local copies, and what options or loading-order requirements are evidenced? provenance
- Which observed errors or behaviour changes arise from option clashes, redefined commands or incompatible extensions? measurement
Engine, font and language support
Determine which compilation environment can support the document's typography and scripts.
Engine and text requirements
Record engine assumptions and the availability of required fonts, encodings and language support.
- What source declarations or build instructions establish the required engine, fonts and language configuration? provenance
- Are required glyphs, hyphenation patterns and writing directions supported in the tested environment? measurement
Compilation and derived state Represent the build sequence, its execution requirements and the validity of generated results.
LaTeX output may depend on repeated passes, auxiliary files and external processors whose state affects correctness.
Build recipe and execution
Identify the commands, inputs and permissions required to produce the intended output.
Complete build workflow
Record the compilation recipe, including bibliography, indexing and externally generated material.
- Which engine invocations and bibliography, index, glossary or graphics-processing steps are required, and in what dependency order? definition
- Does any step require shell escape, external executables or file access beyond the permitted build environment? boundary
Convergence and reproducibility
Distinguish a completed invocation from a stable, traceable document build.
Validated build state
Associate output and diagnostics with the source state and environment that produced them.
- After the prescribed build sequence, which errors, undefined citations, unresolved references or rerun requests remain? measurement
- Can a clean build from the recorded inputs and tool versions reproduce the intended output to the project's required level of equivalence? measurement
Typeset output and handoff Assess the rendered document and determine whether its source and output are ready for their intended use.
Compilation success does not establish acceptable pagination, readable mathematics, accessible structure or a usable submission package.
Rendered document quality
Connect build diagnostics to visual inspection and stated output requirements.
Layout and reading quality
Record visible defects and the evidence used to assess typography and document navigation.
- Where do rendered pages show clipped material, poor line breaks, misplaced floats, unreadable equations or missing glyphs? measurement
- Which requirements apply to links, bookmarks, reading order, tagging or mathematical accessibility, and which have been verified on the actual output? boundary
Submission and source handoff
Determine whether the deliverable matches recipient constraints and includes sufficient build material.
Deliverable readiness
Record the required submission form and identify missing or unsuitable handoff components.
- What class, engine, bibliography, asset and output constraints does the intended recipient impose? boundary
- Which authored sources, local extensions, assets, generated bibliography files and build instructions must be included for this handoff? action
Evidence and external alignment What the world already says about this thing, gathered so the model can be checked against it.
A model that cannot be lined up against existing standards, identifiers and practice cannot be adopted by anyone who already uses them.
Reported evidence
Findings from the breadth pass, kept separate from the structural claims.
Kinds and varieties
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- LaTeX 2.09 (historical format, superseded)
- LaTeX2e (current stable kernel, 1994-present)
- LaTeX3 / expl3 (programming layer and ongoing kernel rewrite)
- Plain TeX (related but not LaTeX)
- ConTeXt (related TeX format, not LaTeX)
- XeLaTeX (Unicode/OpenType engine path)
- LuaLaTeX (LuaTeX engine path)
- pdfLaTeX (pdfTeX engine path)
- Which of these kinds and varieties hold for the sense of LaTeX this model covers, and on what evidence? provenance
Identifiers and schemes
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- Wikidata - Q5310 - Primary item for the LaTeX document preparation system.
- CTAN package - latex - Canonical TeX archive package name for the LaTeX kernel.
- Library of Congress Name Authority - n92061002 - LCNAF identifier recorded on Wikidata for LaTeX.
- GND - 4259186-1 - German National Library subject heading for LaTeX.
- MIME type - application/x-latex - Common unofficial media type for .tex/.ltx source; not an IANA-registered type for LaTeX itself.
- File extension - .tex | .ltx | .sty | .cls | .dtx - Source, class/style, and documented-source file patterns used in LaTeX workflows.
- Which of these identifiers and schemes hold for the sense of LaTeX this model covers, and on what evidence? provenance
Standards and regulation
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- LaTeX2e kernel and documented interfaces - issued by the LaTeX Project / LaTeX3 team (not an ISO/IEC language standard).
- TeX engine behaviour (the substrate LaTeX macros run on) - Donald Knuth's TeX, with engine variants pdfTeX, XeTeX, LuaTeX maintained in the TeX community.
- ISO 32000 (PDF) - International Organization for Standardization; governs the PDF files that pdfLaTeX, XeLaTeX, and LuaLaTeX typically produce.
- ISO 32000-2:2020 (PDF 2.0) - ISO; current PDF language standard relevant to tagged/accessible PDF output from LaTeX.
- EPUB / W3C publishing notes - relevant when LaTeX is converted to HTML/EPUB; they govern the conversion target, not LaTeX source.
- No statute exclusively regulates LaTeX as a document language; journal and thesis class files act as de facto house standards.
- Which of these standards and regulation hold for the sense of LaTeX this model covers, and on what evidence? provenance
Real-world use
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- Authoring mathematics-heavy journal articles, preprints, and books, often submitted as .tex plus a journal class (e.g. elsarticle, IEEEtran, amsart).
- University theses and dissertations compiled with faculty or graduate-school .cls files.
- Conference proceedings and arXiv/institutional-repository deposits, commonly compiled with pdfLaTeX, XeLaTeX, or LuaLaTeX.
- Technical documentation, lecture notes, problem sheets, and beamer slide decks.
- Automated report generation from scientific pipelines (Rnw/knitr, Python+pylatex, pandoc targeting LaTeX).
- Publisher production: copy-editing and typesetting of STM content from author LaTeX through to PDF or XML.
- Overleaf and similar cloud editors as the common collaborative authoring surface.
- Which of these real-world use hold for the sense of LaTeX this model covers, and on what evidence? provenance
Typical measurements
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- Paper size - A4 (210×297) or US letter (8.5×11) - mm or in
- Type size (document class option) - 10, 11, or 12 - pt
- Text width / typeblock - about 120-160 on A4 article defaults - mm
- Baseline skip / leading - about 12-15 for 10-12 pt body - pt
- Engine TeX capacity (main memory, hash size) - engine- and distro-dependent; large documents may exhaust defaults - words (TeX memory units)
- Compile time - seconds for a paper; minutes for a book with indexes, bibliographies, and multiple passes - s
- Output PDF version - 1.4-1.7 commonly; 2.0 when explicitly requested - PDF version number
- Which of these typical measurements hold for the sense of LaTeX this model covers, and on what evidence? provenance
Failure modes and hazards
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- Undefined control sequence, missing package, or class/package version skew that stops compilation.
- Overfull/underfull hboxes and unbreakable math that produce poor line breaks or overflow into margins.
- Bibliography/citation failures (BibTeX vs biblatex/biber mismatch, unresolved keys).
- Engine mismatch: a document written for XeLaTeX/LuaLaTeX (fontspec, Unicode) failing under pdfLaTeX.
- Fragile commands in moving arguments (TOC, captions) causing expansion errors.
- Non-reproducible builds: implicit font, encoding, or package-version dependence across TeX Live/MiKTeX years.
- Unstable auxiliary files (.aux, .toc, .bbl) after a failed run, requiring a clean rebuild.
- Accessibility and archival risk: visual PDF without tagged structure, or source that cannot be recompiled later.
- Security: \write18 / --shell-escape enabling arbitrary command execution from a malicious .tex file.
- License/distribution confusion when mixing LPPL packages with non-free fonts or publisher classes.
- Which of these failure modes and hazards hold for the sense of LaTeX this model covers, and on what evidence? provenance
Regional variation
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- Paper and layout defaults: A4 and millimetre-based classes dominate outside the US; US letter and inch-based templates are common in North America.
- Language and hyphenation: babel vs polyglossia, and engine choice (pdfLaTeX vs Xe/LuaLaTeX) vary with script; CJK, Arabic, and Indic work typically requires XeLaTeX or LuaLaTeX plus language packages.
- Typography conventions: quotation marks, decimal commas vs points, and theorem-numbering styles differ by language community and publisher.
- Distribution: TeX Live is the default on most Unix-like systems and Overleaf; MiKTeX remains widely used on Windows.
- Naming: spoken as "Lay-tech" or "Lah-tech"; written LaTeX, LATEX, or latex; in some locales the TeX logo is not reproduced and "LaTeX" is used as plain text.
- Publisher practice: many European STM houses still require or strongly prefer LaTeX; some US humanities and legal venues do not.
- Which of these regional variation hold for the sense of LaTeX this model covers, and on what evidence? provenance
Neighbouring kinds and how to tell them apart
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- TeX - TeX is Knuth's typesetting engine and primitive language; LaTeX is a macro format on top of TeX. A file that begins with \documentclass is LaTeX; one that uses \shipout / plain primitives without a LaTeX kernel is TeX.
- Plain TeX - Plain TeX is Knuth's minimal format. Presence of \documentclass / \begin{document} vs plain macros (\proclaim, \eqalign) separates them; they are not interchangeable formats.
- ConTeXt - Another TeX format with its own kernel (\starttext / \setup…), not the LaTeX class/package model. Engine overlap (LuaTeX) does not make a ConTeXt document a LaTeX document.
- XeTeX / LuaTeX / pdfTeX - These are engines, not formats. XeLaTeX means the LaTeX format running on XeTeX. Engine can change while the source remains LaTeX; format is decided by the kernel (latex vs plain vs context).
- Markdown / pandoc - Lightweight markup often compiled *to* LaTeX. If the source of truth is .md plus a YAML header, it is Markdown; if it is a .tex file with a document class, it is LaTeX.
- Typst / Word / InDesign - Independent typesetting or DTP systems. They may import or export LaTeX-like math, but they do not execute the LaTeX kernel; round-trip is lossy.
- MathJax / KaTeX - JavaScript engines that parse a subset of LaTeX math notation for the web; they do not process a full LaTeX document (no classes, floats, or aux-file workflow).
- LaTeX the typesetting system vs latex the rubber polymer - Homograph only. In computing and publishing contexts, capitalisation (LaTeX) and file/engine artefacts (.tex, pdfLaTeX) identify the document system; the polymer is a material with CAS/ISO rubber identifiers.
- Which of these neighbouring kinds and how to tell them apart hold for the sense of LaTeX this model covers, and on what evidence? provenance
Sources
- LaTeX - A document preparation system - Official project definition of LaTeX as a TeX macro package, current LaTeX2e kernel, and LaTeX3/expl3 work.
- latex - A TeX macro package that defines LaTeX - Canonical package identity on CTAN, LaTeX2e as current version, historical 2.09, and relationship to TeX.
- LaTeX (Q5310) - Stable identifiers (Wikidata Q5310, Freebase, Library of Congress, GND) and classification as a document markup language / typesetting system.
- ISO 32000-2:2020 Document management - Portable document format - Part 2: PDF 2.0 - The principal interchange standard for the PDF files LaTeX engines commonly emit; not a LaTeX specification itself.
What the second pass must settle
- Does the registry intend LaTeX to denote the document preparation system alone, or also individual LaTeX source projects as model instances?
- Does an existing Vercy world model already own this concept or any of its document-build responsibilities?
- Which current authoritative LaTeX, engine and package documentation should support the compatibility and build-state criteria?
- Which accessibility targets and validation methods should determine readiness for the intended document uses?
- Should reproducibility mean equivalent content, equivalent layout or byte-identical output for this registry entry?