# Technical Audit Workflow > A pre-submission manuscript audit that checks math, statistics, data/table consistency, notation, and references before academic submission. The Technical Audit workflow is for academic researchers who want a precision-first check before a manuscript is submitted, circulated, or presented. Where the Referee Report workflow asks whether the paper is persuasive as scholarship, Technical Audit asks whether the manuscript holds together technically. It looks for the quiet defects that can weaken a paper even when the idea is strong: missing assumptions, table-text mismatches, notation drift, inconsistent references, unsupported statistical claims, and proof steps that do not follow as written. Use it when the manuscript is close enough to submission that internal consistency matters. --- ## What the workflow does Upload a PDF, Word document, LaTeX source, ZIP project, or pasted manuscript text. Corbis builds a structured view of the manuscript, extracts checkable claims, runs specialist audit passes, verifies the findings, and returns a severity-ranked technical report. The workflow focuses on: - mathematical derivations and proof logic - statistical specification and inference - table, figure, and text consistency - data definitions and numeric claims - notation, labels, cross-references, and appendices - findings that can be explained with a manuscript locus and a suggested fix The report is meant to be actionable. Each useful finding should tell you what is wrong, where it appears, why it matters, and what to change. --- ## Specialist agents Technical Audit uses a different agent graph from Referee Report. It is not trying to judge novelty or contribution. It is trying to reduce preventable technical risk. - **Claim mapper**: builds a manifest of sections, equations, tables, references, notation, and extractable checkable claims. - **Math auditor**: reviews derivations, assumptions, proof steps, theorem statements, and equation logic. - **Stats auditor**: checks specifications, estimands, standard errors, identification language, inference claims, and econometric consistency. - **Data/table auditor**: compares table values, captions, text claims, sample descriptions, variable construction, and reported magnitudes. - **Verifier**: challenges candidate findings, removes weak or advice-only items, deduplicates overlapping issues, and ranks the remaining findings by severity. This structure keeps the audit focused. A statistical specification issue should not be buried under prose advice, and a broken reference should not crowd out a major mathematical defect. --- ## What happens after upload 1. **Load sources** Corbis accepts manuscript files or pasted text. LaTeX source gives the workflow more structure for equations, labels, cross-references, and table logic. PDF and Word uploads are still useful, but source files usually provide better technical coverage. 2. **Map the manuscript** The workflow builds a document manifest: sections, equations, tables, notation, theorem-like objects, references, and candidate claims. This gives the auditors a structured map rather than a single unorganized text block. 3. **Audit in parallel** Specialist auditors examine math, statistics, data/table consistency, notation, and cross-document consistency. Each pass is designed to produce concrete findings anchored to a location in the manuscript. 4. **Verify and prioritize** Candidate findings are challenged, filtered, deduplicated, and sorted. The final report favors fewer, stronger findings over a long list of vague recommendations. 5. **Export the audit** The completed audit is saved with the run and can be reopened later. Where export actions are available, the report can be downloaded for revision planning or coauthor review. --- ## What the report is good for Technical Audit is useful when you want to catch issues that are hard to see after weeks or months inside the same draft. It is especially useful for: - final pre-submission checks - coauthor handoff before a revision sprint - validating equation numbering, references, and notation after major edits - checking that tables and text tell the same story - identifying missing assumptions in propositions, proofs, and empirical claims - catching statistical language that overstates what the specification supports The workflow is designed to help authors remove avoidable objections before a referee, discussant, or seminar audience finds them first. --- ## What the report is not Technical Audit is not a novelty review, literature review, or acceptance prediction. It also does not guarantee that: - every proof has been formally verified - every table value has been replicated from raw data - every bibliography entry is complete - every image-embedded equation has been parsed - every empirical result is externally reproducible For a broader scholarly assessment, use [Referee Report](/docs/referee-report-workflow). For flexible research exploration, use chat or Projects. For the full catalog, see [Guide to Structured Workflows](/docs/workflows-guide). --- ## How to get better results Use the richest source you can provide. Best inputs: - a LaTeX project ZIP with the main `.tex` file and included source files - a single `.tex` manuscript source - a PDF with selectable text - a Word document when source files are not available - pasted source text for quick checks Good optional context includes: - "Focus especially on the IV first stage and exclusion restriction." - "Check whether table captions, text, and variable definitions are aligned." - "Audit theorem statements and proof assumptions." - "Look for notation drift between the model section and empirical section." The workflow works best when the manuscript is already a serious draft. If the paper is still early and the main question is whether the research idea is promising, start with Referee Report or chat instead. --- ## When to choose this workflow Choose **Technical Audit** when the central question is: > What technical issues would embarrass or weaken this manuscript if they reached a referee? Choose **Referee Report** when the central question is: > Does the paper make a convincing scholarly contribution, and where would a referee push back? Used together, the two workflows cover different risks: Technical Audit reduces internal correctness risk; Referee Report evaluates the paper's contribution, argument, and revision priorities.