u/Potential-Winter-205

I recently used a LaTeX-based workflow, with ChatGPT as one of the review/control layers, to produce and archive a large citable research artifact on Zenodo.

The current public version is 713 pages. The project is not a normal short paper, but a structured monograph / system archive with chapters, appendices, evidence layers, governance boundaries and versioned release notes.

My question here is less about LaTeX itself and more about the ChatGPT / LLM workflow around it:

For people using ChatGPT on larger documents or research systems, what would you recommend for:

• keeping the model from losing the global structure
• separating writing, review, audit and release decisions
• avoiding hallucinated consistency
• tracking source/evidence status
• producing a short reader’s guide or navigation layer
• keeping long-term versions reproducible

Important boundary: this is not a claim of machine consciousness, autonomous agency or legal personhood. It is a systems-engineering / documentation artifact about long-running human-AI cooperation.

I would especially appreciate feedback on the ChatGPT side:

1. How would you use ChatGPT without turning it into a black-box editor?
2. What checks would you add before every build or public release?
3. Would you keep one large context/document, or split the system into smaller reviewable modules?

This is not a sales post. I am mainly looking for critique on document structure, AI-assisted review, maintainability and reproducibility.

Disclosure: I am the author of the document. The Zenodo record is only included as context for the scale and structure, not as something people need to read.
FerrAI–Terra'Nova CIC Framework — System Architecture, State Logic and Governance Boundaries

I ran into a very concrete LaTeX issue today and I’m curious how people here would structure this more cleanly.

I have a large multi-file project. The actual chapter list lives in an inner root file, but the file that should be compiled is only a small wrapper:

\makeatletter
\def\input@path{{uploads/prism_stage_B_chapters_20260614/}}
\makeatother

\input{uploads/prism_stage_B_chapters_20260614/main_686_candidate.tex}

Inside main_686_candidate.tex, the chapters are included like this:

\input{chapters/00_frontmatter.tex}
\input{chapters/01_...}
...

When I compile main.tex, everything works.

But when the editor accidentally tries to compile main_686_candidate.tex directly, it fails with:

File `chapters/00_frontmatter.tex` not found

That makes sense, because the inner file depends on the wrapper setting the input path first. The confusing part was that the browser/editor preview still looked attached to an older compile target, so it looked like the project was broken even though the correct main.tex build was fine.

My question: is this wrapper + inner-root pattern acceptable for large projects, or would you avoid it?

More specifically:

1. Is using \input@path like this reasonable, or too fragile?
2. Would you rather keep all paths relative to one canonical root?
3. Should the inner root be made impossible / obviously wrong to compile directly?
4. Is .latexmkrc the right place to force the intended target?
5. Any best practices for avoiding compile-target drift in browser/cloud LaTeX editors?

I’m mainly trying to make the project harder to accidentally compile the wrong way.

I recently used a LaTeX-based workflow to produce and archive a large citable research artifact on Zenodo:

FerrAI–Terra'Nova CIC Framework — System Architecture, State Logic and Governance Boundaries

The current Zenodo PDF is a 686-page extended build. The canonical Prism + LaTeX workflow build referenced in my earlier workflow notes was 661 pages. I am mentioning this upfront to avoid confusion about the page count.

I do not expect anyone to read the document linearly. My question here is specifically about LaTeX structure and maintainability at this scale.

For a document of this size, what would you recommend for:

- splitting chapters into separate .tex files

- keeping strict interfaces between sections

- glossary and terminology consistency

- bibliography consistency

- automated build checks

- link checks

- long-term versioning

- producing a short reader’s guide or navigation layer

The document is more like a structured monograph / system archive than a normal short paper. It includes state logic, governance boundaries, evidence layers, persistence layers, anti-goal frames, and long-form appendix material.

Important boundary: this is not a claim of machine consciousness, legal personhood, or autonomous AI agency. It is a systems-engineering / documentation artifact about long-running human–AI cooperation.

I would especially appreciate feedback on the LaTeX side:

1. How would you modularize a document at this scale?

2. What checks would you automate before every build?

3. Would you split this into smaller papers, or keep one monograph plus a short reader’s guide?

4. Are there LaTeX patterns, packages, or repository structures you would recommend for maintaining something this large over time?

This is not a sales post. I am mainly looking for critique on document structure, maintainability, and reviewability.