# How-to: first review of technical documents with MAIA **Goal:** Quickly and thoroughly review incoming technical documents, customer specifications, standards, requirements documents, for the first time. **Prerequisites:** Access to MAIA, the document to be reviewed, optionally internal reference documents (standards, norms, your own specifications). **Time required:** \~15 minutes setup, then \~20 minutes per first review (instead of 2–4 hours). *** ## The problem: why first reviews consume so much time When a new technical document lands on your desk, whether it's a customer specification, an updated standard, or a requirements document, a process begins that every project manager and engineer in manufacturing knows all too well: systematically reading through, marking, comparing, and evaluating. In practice, this means: * **Documents with 50–200+ pages** need to be read and understood completely * **Cross-references to other standards and norms** need to be looked up and verified * **Deviations from internal standards** need to be identified * **Critical parameters** (tolerances, limits, material requirements) need to be extracted and evaluated * **Unclear or contradictory requirements** need to be recognized and documented Most professionals spend **2 to 4 hours per first review** - for complex specifications, often significantly more. The bulk of that time isn't spent on actual technical evaluation, but on searching, reading, and compiling the relevant information. ## Step by step: how to review technical documents with MAIA ### Step 1: prepare and upload documents Upload the document to be reviewed into MAIA. If you want to check it against internal standards or reference documents, upload those as well. **Recommended data collection:** * The incoming document to be reviewed (e.g., customer specification) * Your internal reference standards * Relevant norms or guidelines > **Tip:** Create a dedicated MAIA data collection "First review \[project name]" so the documents stay cleanly separated and you can refer back to them later. ### Step 2: conduct a structured initial analysis Start with a broad analysis to get an overview of the document. Use the following prompt template: ```plaintext I am a [role, e.g., project engineer] and I've received a new [document type, e.g., customer specification] that I need to review for the first time. Please create a structured initial analysis covering the following points: 1. DOCUMENT OVERVIEW: What is it about, who is the author/publisher, what is the scope, which version? 2. KEY REQUIREMENTS: What are the 5–10 most important requirements or parameters? 3. CRITICAL POINTS: Which requirements are particularly demanding, unusual, or potentially problematic? 4. CROSS-REFERENCES: Which external norms, standards, or documents are referenced? 5. OPEN QUESTIONS: Where are there unclear, contradictory, or missing specifications? ``` ### Step 3: detailed review of targeted areas Once you have the overview, dive deeper into the critical areas: ```plaintext Now focus on [specific section, e.g., "the material requirements in chapter 4"]. Extract all concrete parameters, limits, and tolerances in a clear table. Flag values that deviate from our internal standards. ``` ### Step 4: create a deviation report Have MAIA create a structured report you can use directly: ```plaintext Based on your analysis, create a first review report with the following structure: - Document identification (title, version, date) - Review summary (3–5 sentences) - Table of critical deviations (Requirement | Our standard | Deviation | Assessment) - List of open clarification points - Recommendation for next steps ``` ## Prompt templates to copy ### Quick completeness check ```plaintext Check the uploaded document for completeness. Are any typical sections missing that you would expect in a [document type]? List any missing or incomplete areas. ``` ### Standards comparison ```plaintext Compare the requirements in the uploaded document against the standard [standard designation, e.g., DIN EN ISO 9001]. Where does the document meet the standard requirements, and where are there gaps or deviations? ``` ### Parameter extraction ```plaintext Extract all quantitative requirements (dimensions, tolerances, temperature ranges, pressure values, material specifications) from the document and present them in a clear table. Sort by section. ``` ### Risk assessment ```plaintext Identify the 5 riskiest requirements in this document, those that are technically demanding, cost-intensive, or difficult to implement. Justify your assessment in 2–3 sentences each. ``` ## Real-world example: first review at a mechanical engineering company **Starting situation:** A mid-sized mechanical engineering company with \~250 employees regularly receives requirements documents and specifications from automotive industry customers. Each requirements document covers 80–150 pages and references dozens of standards. Previously, the responsible project manager allocated half a day to a full day per first review. **Implementation with MAIA:** The team created a data collection "Customer requirements" that contains the respective requirements document alongside internal design guidelines and relevant standards. Using a standardized prompt template for the initial analysis and deviation report, every new requirements document is now reviewed in approximately 20–30 minutes. **Results:** * Review time reduced from \~4 hours to \~25 minutes * Critical deviations are identified more reliably because MAIA systematically works through all sections * The project manager focuses on technical evaluation rather than compiling information * First review reports have a consistent structure and quality ## Pro tips **Verify answers:** Switch on “Verify answers” in the answer settings when checking critical technical values. You'll get direct quotes and source references from the documents and can quickly verify the results. **Maintain your glossary:** Upload a glossary of your company-specific technical terms and abbreviations into MAIA. Especially when reviewing external documents for the first time, this helps MAIA correctly map your internal terminology. **Save results as templates:** When you've generated a good first review report, export it and upload it as a TEMPLATE file back into MAIA. Next time, you can reference it: "Create the first review report in the same structure as TEMPLATE_FirstReview\.pdf." **Work iteratively:** Start broad with "Select all files" and narrow down after the initial analysis. Then selectively choose the most relevant documents for the detailed review. > **Next step:** Once you've mastered the first review, combine it with the Spec check - so you don't just review the document itself, but also compare the requirements directly against your product portfolio.