Document Analysis Terminal

Project Blueprint: Document Analysis Terminal (DAT)

1. The Business Problem (Why build this?)

The financial sector, particularly investment analysis, asset management, and corporate finance, grapples with an immense volume of unstructured data in the form of regulatory filings like 10-K, 10-Q, earnings transcripts, and investor presentations. A significant portion of this data is locked within PDF documents, making it laborious and error-prone for financial professionals to extract, synthesize, and leverage for critical decision-making.

Current pain points for financial analysts and investors include:

• Manual Data Extraction: Extracting key financial figures (revenue, net income, EPS, cash flows), operational metrics, and qualitative insights (strategic initiatives, risk factors) from multi-hundred-page PDFs is a highly manual, time-consuming, and repetitive task. This often involves scanning documents, copy-pasting, and transcribing, leading to transcription errors and inconsistencies.
• Contextual Blind Spots: Analysts frequently miss crucial context or nuances embedded within the lengthy narratives of 10-K filings, which can significantly impact financial modeling assumptions and valuation. Identifying specific clauses, footnotes, or management discussions relevant to a financial metric is challenging.
• Lack of Auditability: When figures are extracted and used in models, it's often difficult to quickly trace them back to their original source in the document, hindering auditability and cross-verification. This is particularly critical in high-stakes financial environments.
• Fragmented Tooling: Financial professionals typically rely on a patchwork of tools: PDF readers, spreadsheets for modeling, and disparate data providers. There's no integrated solution that streamlines the entire workflow from document ingestion to model generation and report output.
• Time Sensitivity: Market opportunities and investment decisions are often time-sensitive. The speed at which an analyst can process new information directly impacts their ability to react and capitalize on opportunities.

The "Document Analysis Terminal" (DAT) aims to directly address these challenges by providing a comprehensive, AI-powered platform that transforms the way financial professionals interact with regulatory documents. By automating the data extraction, integrating with sophisticated financial models, and ensuring complete auditability, DAT will dramatically improve efficiency, accuracy, and decision-making speed for its users. This will enable analysts to focus on higher-value tasks like strategic analysis and scenario planning, rather than manual data entry.

2. Solution Overview

The Document Analysis Terminal (DAT) is a web-based, AI-driven application designed to be the central hub for financial analysts working with 10-K PDFs. It offers an intuitive interface to upload, analyze, model, and report on company financials directly from regulatory filings.

Core Functional Pillars:

1. Intelligent PDF Ingestion & Analysis: Seamlessly upload 10-K PDFs and have the system parse, understand, and index their content, making it immediately queryable. This includes handling the significant length and complexity of these documents.
2. AI-Powered Information Extraction: Utilize advanced Large Language Models (LLMs) to answer specific questions about the document, extract key financial data points, and summarize complex sections.
3. Integrated Financial Modeling: Provide direct functionality for core financial analyses, specifically a Discounted Cash Flow (DCF) calculator and Revenue Multiple analysis, pre-populating models with extracted data.
4. Verifiable Insights (Citation Generation): Crucially, every piece of information or derived figure will be traceable back to its exact source (page number, section) within the original PDF, ensuring transparency and auditability.
5. Customizable Reporting & Export: Generate professional, exportable PDF reports incorporating extracted data, model outputs, and user-generated analyses.

High-Level User Journey:

1. Upload: A financial analyst navigates to DAT, authenticates, and uploads a 10-K PDF for a target company.
2. Processing: The system ingests the PDF, extracts text, chunks it, generates embeddings, and stores it for rapid retrieval.
3. Query & Extract: The analyst uses a chat interface or structured prompts to ask questions (e.g., "What was the revenue for the last fiscal year?", "Summarize the key risks mentioned in the filing?"). DAT responds with accurate answers and precise citations.
4. Model & Analyze: The analyst initiates a DCF or Revenue Multiple analysis. DAT intelligently suggests initial assumptions based on document content, which the analyst can then review and adjust. The models calculate and display results, often with interactive charts.
5. Refine & Export: The analyst reviews all findings, makes further adjustments to models, and then generates a comprehensive PDF report consolidating all extracted data, model outputs, and user-AI interactions.

Key Differentiators:

• Deep Context Understanding: Leveraging Gemini's long context window to process entire 10-K filings without losing fidelity.
• Actionable & Auditable AI: Not just answers, but answers with provable sources, directly integrated into financial workflows.
• Integrated Workflow: A single platform for document analysis, modeling, and reporting, reducing tool switching and improving efficiency.
• FinTech Focus: Tailored specifically for financial documents, understanding their structure and typical data points.

3. Architecture & Tech Stack Justification

The architecture for DAT is designed for scalability, reliability, and maintainability, leveraging a modern stack with a strong emphasis on Google Cloud services and the Gemini API for its core intelligence.

Overall Architecture Diagram (Conceptual):

+-------------------+      +-------------------+
|    User Frontend  | <--> |   Backend API     |
|     (Next.js)     |      |  (Next.js API/    |
+---------+---------+      |    Cloud Run)     |
          |                  +--------+----------+
          |                         |
          |             +-----------+----------+
          |             |   Data Processing    |
          |             |    (Cloud Functions/  |
          |             |       Cloud Run Jobs)  |
          |             +-----------+----------+
          |                         |
          |     +-------------------+--------------------+
          |     |          |          |          |          |
          |     v          v          v          v          v
          |  Cloud Storage  PostgreSQL   Vector DB    Gemini API  Recharts
          |  (Raw PDFs)  (Metadata, Users) (Embeddings) (LLM, Embeddings) (Client-side viz)
          +----------------------------------------------------+

Key Components & Tech Stack Justification:

1. Frontend: Next.js (React)

   • Justification: Next.js provides a robust framework for building performant and scalable React applications. Its support for server-side rendering (SSR) or static site generation (SSG) enhances initial load times and SEO (though less critical for an internal tool, it provides a solid foundation). API Routes simplify backend integration, allowing a single repository for frontend and API logic, especially for a V1. The React ecosystem offers a vast array of components and libraries for complex UIs, and Recharts is a natural fit for data visualization.
   • Responsibilities: User authentication, PDF upload interface, interactive chat/query dashboard, financial model input forms, dynamic charts, report preview, and export initiation.

2. Backend: Next.js API Routes / Google Cloud Run (Node.js/Python)

   • Justification: For V1, Next.js API routes can handle user authentication (e.g., via NextAuth.js), proxy requests to Gemini API, orchestrate PDF processing, and manage database interactions. As the application grows, specific functionalities (e.g., the core financial modeling engine, complex PDF parsing) can be refactored into dedicated microservices deployed on Google Cloud Run. Cloud Run offers serverless container execution, automatic scaling, and pay-per-request pricing, ideal for event-driven processing and API endpoints. Node.js is suitable for I/O-bound tasks and API orchestration, while Python can be introduced for specialized NLP/ML tasks if needed.
   • Responsibilities: User and document management, API gateway for Gemini, triggering PDF processing workflows, database CRUD operations, financial calculation logic (DCF, multiples), report generation orchestration.

3. Data Processing Pipeline: Google Cloud Functions / Cloud Run Jobs (Node.js/Python)

   • Justification: PDF ingestion and processing are asynchronous, resource-intensive tasks. Google Cloud Functions (for smaller, stateless operations) or Cloud Run Jobs (for longer-running, containerized tasks) are perfect for this. They are event-driven (e.g., triggered by a new PDF upload to Cloud Storage), scale automatically, and are cost-effective. Python is often favored here due to its rich ecosystem for PDF parsing (pypdf, pdfminer.six, unstructured.io) and general data processing.
   • Responsibilities: Downloading PDFs from GCS, text extraction, chunking, embedding generation via Gemini API, and storing results in the vector database.

4. Database: PostgreSQL (Google Cloud SQL) & Vector Database (e.g., pgvector or Pinecone)

   • Justification:
     • PostgreSQL: Robust, ACID-compliant, and widely adopted relational database. Ideal for storing structured metadata (user profiles, document details, analysis sessions, model assumptions, user queries, citations). Google Cloud SQL provides a fully managed service, handling scaling, backups, and replication.
     • Vector Database: Essential for efficient similarity search for Retrieval Augmented Generation (RAG). pgvector (PostgreSQL extension) is a strong candidate for V1, allowing us to leverage existing PostgreSQL infrastructure and simplify deployment. For higher scale or advanced vector operations, a dedicated managed vector database like Pinecone, Chroma Cloud, or Weaviate could be considered.
   • Responsibilities:
     • PostgreSQL: users table, documents table (id, name, original_gcs_url, status, upload_date), analysis_sessions table (user_id, doc_id, model_inputs, model_outputs), citations table (link to specific chunks).
     • Vector DB: document_chunks table (chunk_id, doc_id, page_num, section_title, chunk_text, embedding_vector).

5. Storage: Google Cloud Storage (GCS)

   • Justification: Highly scalable, durable, and cost-effective object storage. Perfect for storing raw uploaded 10-K PDFs, intermediate processing files, and generated reports. Integrates seamlessly with Cloud Functions/Run for event triggers.
   • Responsibilities: Storing original PDF uploads, storing final generated reports for user download.

6. AI/ML: Google Gemini API (Pro/Ultra & Embeddings)

   • Justification: The core intelligence of DAT. Gemini offers state-of-the-art LLM capabilities, crucial for understanding complex financial documents. Its long context window is paramount for ingesting entire sections or even full 10-K filings, allowing for nuanced analysis without excessive summarization or information loss. The text-embedding-004 model provides high-quality vector representations for efficient semantic search. Leveraging a managed API reduces operational overhead for AI model deployment and maintenance.
   • Responsibilities: Semantic search, information extraction, summarization, Q&A, qualitative analysis, financial assumption suggestions, and potential calculation validation.

7. Charting: Recharts

   • Justification: A flexible and lightweight charting library built for React. It allows for customizable and interactive financial visualizations within the Next.js frontend, presenting DCF outputs, revenue trends, and other metrics clearly.

4. Core Feature Implementation Guide

4.1 Long-context PDF Ingestion & Retrieval

This pipeline is critical for DAT's ability to "read" and understand multi-hundred-page 10-K filings.

Ingestion Pipeline:

1. User Upload (Frontend): User selects a PDF via a Next.js upload component.
2. API Upload & GCS Storage (Backend): The Next.js frontend sends the PDF as a multipart form data request to a backend API endpoint (e.g., /api/upload-pdf). The backend API then securely uploads this PDF to a designated Google Cloud Storage bucket. Upon successful upload, it records metadata (filename, user_id, initial status "UPLOADED") in PostgreSQL and returns a document_id to the frontend.
3. Asynchronous Processing Trigger: The GCS upload event can trigger a Google Cloud Function or a Cloud Run Job. Alternatively, the backend API can explicitly send a message to a Pub/Sub topic to initiate the processing.
4. Processing Service (Cloud Function/Run Job):
   • Download: Downloads the newly uploaded PDF from GCS using the document_id or GCS object path.
   • PDF Parsing: Uses a robust library (e.g., pypdf in Python, or a server-side pdf.js wrapper in Node.js, unstructured.io for advanced layout parsing) to extract raw text content from the PDF, page by page. This step should also attempt to identify page numbers and, if possible, major section headers.
   • Text Chunking:
     • Strategy: Utilize a "Recursive Character Text Splitter" (similar to Langchain's) for optimal chunking. This method tries to split by paragraphs, then sentences, then words, recursively, to maintain semantic coherence.
     • Chunk Size: Target ~2,000-4,000 tokens per chunk. This size provides sufficient context for Gemini while staying well within its multi-turn context window (e.g., 128K tokens for Gemini 1.5 Pro).
     • Overlap: Introduce a significant overlap (e.g., 10-20% of chunk size) between consecutive chunks to preserve context across splits.
     • Metadata: Each chunk must carry metadata: document_id, chunk_index, page_number_start, page_number_end, section_heading (if detected), original_text.
   • Embedding Generation: For each generated text chunk, call the gemini-pro-text-embedding-004 model via the Gemini API to generate a high-dimensional vector embedding.
   • Vector Storage: Store the chunk_text, embedding_vector, and all associated metadata into the Vector Database.
   • Status Update: Update the document status in PostgreSQL to "PROCESSED".

Retrieval Augmented Generation (RAG) for Querying:

1. User Query (Frontend): User submits a question via the chat interface (e.g., "What were the R&D expenses in 2023?").
2. Query Embedding (Backend): The backend API sends the user's query to the Gemini text-embedding-004 model to generate its embedding.
3. Vector Search: Performs a similarity search in the Vector Database using the query embedding. It retrieves the top-k (e.g., k=5 to 10) most semantically similar text chunks related to the document_id in question.
4. Prompt Construction: The backend constructs a comprehensive prompt for Gemini:
   • A clear system instruction (see Section 5).
   • The concatenated text of the retrieved chunks, clearly demarcated and including their metadata (e.g., "Context from Page X, Section Y: [Chunk Text]").
   • The user's original query.
   • An explicit instruction to cite sources.
5. LLM Call (Gemini API): Sends the constructed prompt to the gemini-pro model.
6. Response Parsing & Citation Extraction: The backend receives Gemini's response. It then parses the response to extract the answer and identify explicit citations (e.g., "Page X", "Section Y"). This might involve regular expressions or light NLP to match citations back to the metadata of the retrieved chunks.
7. Return to Frontend: Sends the AI-generated answer and associated clickable/highlightable citations back to the frontend for display.

# Pseudo-code for PDF Ingestion (Python, conceptual)
from google.cloud import storage
from google.generativeai.client import get_default_retrieval_service_client # placeholder
from pypdf import PdfReader # or unstructured.io for advanced parsing

def process_pdf_job(gcs_uri, document_id, pg_conn, vector_db_client, gemini_embed_model):
    # 1. Download PDF from GCS
    client = storage.Client()
    bucket_name, blob_name = gcs_uri.replace("gs://", "").split("/", 1)
    bucket = client.bucket(bucket_name)
    blob = bucket.blob(blob_name)
    local_path = f"/tmp/{document_id}.pdf"
    blob.download_to_filename(local_path)

    # 2. Extract Text & Metadata
    reader = PdfReader(local_path)
    full_text = ""
    page_texts = []
    for i, page in enumerate(reader.pages):
        text = page.extract_text()
        page_texts.append({"page_num": i + 1, "text": text})
        full_text += text + "\n"

    # 3. Text Chunking (simplified - actual needs recursive splitter)
    # Consider using a robust library like Langchain's RecursiveCharacterTextSplitter
    chunks = []
    current_chunk = ""
    current_page_start = 1
    max_tokens = 3000 # Example, actual needs tokenization
    
    for page_data in page_texts:
        page_text = page_data["text"]
        page_num = page_data["page_num"]
        
        # Simple split, more sophisticated logic needed for production
        if len(current_chunk.split()) + len(page_text.split()) < max_tokens:
            current_chunk += page_text
        else:
            chunks.append({
                "doc_id": document_id,
                "text": current_chunk,
                "page_start": current_page_start,
                "page_end": page_num - 1 # End of previous page
            })
            current_chunk = page_text
            current_page_start = page_num
    
    if current_chunk: # Add last chunk
        chunks.append({
            "doc_id": document_id,
            "text": current_chunk,
            "page_start": current_page_start,
            "page_end": page_texts[-1]["page_num"]
        })

    # 4. Generate Embeddings & Store
    for i, chunk_data in enumerate(chunks):
        embedding_response = gemini_embed_model.embed_content(
            content=chunk_data["text"],
            task_type="RETRIEVAL_DOCUMENT" # Specific task type for embeddings
        )
        embedding_vector = embedding_response.embedding.values
        
        vector_db_client.upsert_chunk({
            "id": f"{document_id}_{i}",
            "doc_id": document_id,
            "text": chunk_data["text"],
            "embedding": embedding_vector,
            "page_start": chunk_data["page_start"],
            "page_end": chunk_data["page_end"],
            # Potentially add section_heading
        })

    # 5. Update DB status
    with pg_conn.cursor() as cur:
        cur.execute("UPDATE documents SET status = 'PROCESSED' WHERE id = %s", (document_id,))
    pg_conn.commit()

# Pseudo-code for RAG Query (Node.js, conceptual)
async function handleUserQuery(documentId, query, pgClient, vectorDbClient, geminiClient) {
    const queryEmbeddingResponse = await geminiClient.embedContent({
        model: "text-embedding-004",
        content: { text: query },
        taskType: "RETRIEVAL_QUERY"
    });
    const queryEmbedding = queryEmbeddingResponse.embedding.values;

    const relevantChunks = await vectorDbClient.search(documentId, queryEmbedding, { k: 5 });

    let contextString = "";
    relevantChunks.forEach((chunk, index) => {
        contextString += `--- Context Chunk ${index + 1} (Page ${chunk.page_start}-${chunk.page_end}) ---\n`;
        contextString += chunk.text + "\n\n";
    });

    const prompt = `You are an expert financial analyst. Your goal is to extract precise information and perform accurate calculations based *only* on the provided context.\nIf the information is not explicitly available in the context, state that you cannot find it.\nAlways cite the source document by referring to the page number from the provided chunks.\n\n${contextString}User Query: ${query}\n\nAnswer:`;

    const modelResponse = await geminiClient.generateContent({
        model: "gemini-pro",
        contents: [{ role: "user", parts: [{ text: prompt }] }],
        safetySettings: [...] // Crucial for FinTech
    });

    const aiAnswer = modelResponse.response.candidates[0].content.parts[0].text;
    
    // Simple citation extraction, needs more robust implementation
    const citations = aiAnswer.match(/Page \d+/g) || []; 
    
    return { answer: aiAnswer, citations: citations };
}

4.2 DCF Calculator

The DCF (Discounted Cash Flow) calculator will be a core analytical feature, leveraging Gemini for intelligent data pre-filling and assumption generation.

Workflow:

1. Input Collection (Frontend): A dedicated UI allows users to input core assumptions:
   • Revenue Growth Rates (e.g., for explicit forecast years 1-5, and terminal growth).
   • EBIT Margin.
   • Tax Rate.
   • Capital Expenditures (CapEx) as % of Revenue.
   • Change in Non-Cash Working Capital (NWC) as % of Revenue.
   • Discount Rate (WACC - Weighted Average Cost of Capital).
   • Shares Outstanding (for per-share valuation).
2. Intelligent Defaults (Gemini Integration): Before the user inputs, DAT uses Gemini to suggest initial assumptions based on the ingested 10-K:
   • Historical Data Extraction: Prompt Gemini (using RAG) to find "Total Revenues", "Cost of Revenues", "Operating Expenses", "Depreciation & Amortization", "Capital Expenditures" from the last 3-5 fiscal years.
   • Growth Rate Suggestion: Prompt Gemini to calculate historical revenue growth and suggest a range for future growth based on past performance and management outlook in MD&A.
   • Margin Suggestion: Extract historical EBIT margins and suggest averages.
   • WACC (Future Scope/User Input): WACC is complex and often requires external data. V1 will likely require manual input, but future iterations could integrate with external APIs or use Gemini to find components (Cost of Equity, Cost of Debt).
3. Calculation Logic (Backend Service): A dedicated Node.js function (or Python if a microservice) will perform the DCF calculations:
   • Project Revenue: Base year revenue (extracted from 10-K) projected using growth rates.
   • Project Expenses: Based on projected revenue and EBIT margin, calculate Cost of Goods Sold and Operating Expenses.
   • NOPAT: Calculate Net Operating Profit After Tax.
   • Adjustments: Project CapEx, Depreciation & Amortization (D&A extracted or estimated), and Change in NWC.
   • Free Cash Flow (FCF): Calculate FCF for each explicit forecast year.
   • Terminal Value (TV): Use the Gordon Growth Model (FCF in last explicit year * (1 + Terminal Growth Rate) / (WACC - Terminal Growth Rate)).
   • Present Value: Discount all FCFs and the Terminal Value back to the present using WACC to derive Enterprise Value.
   • Equity Value & Per Share: Adjust Enterprise Value for Net Debt, Preferred Stock, Minority Interest (all extracted from 10-K if available or user input) to get Equity Value, then divide by Shares Outstanding.
4. Output & Visualization (Frontend): Display calculation tables (e.g., FCF breakdown by year), and interactive charts (using Recharts) for FCF trends, revenue growth, etc. Allow users to save their assumptions and results.

4.3 Revenue Multiple Analysis

This feature provides quick valuation insights based on comparable company multiples.

Workflow:

1. Data Extraction (Gemini):
   • "What was the Total Revenues for the latest reported fiscal year?" (cited)
   • "What is the current market capitalization of the company?" (requires user input or external API, as 10-K is historical).
   • "What is the total short-term and long-term debt as of the latest balance sheet?" (cited)
   • "What is the cash and cash equivalents balance?" (cited)
   • "What is the number of fully diluted shares outstanding?" (cited)
   • Calculations: Net Debt = Total Debt - Cash. Enterprise Value (EV) = Market Cap + Net Debt + Minority Interest + Preferred Stock.
2. Multiple Calculation (Backend):
   • Calculates the target company's EV/Revenue multiple.
3. Comparable Companies (Future Scope):
   • Identification (Gemini): Prompt Gemini to identify "key competitors" or "companies operating in similar industries" based on the business description and industry sections of the 10-K.
   • External Data Integration: Fetch market capitalization, latest revenue, and net debt for identified comparable companies from external financial data APIs (e.g., Alpha Vantage, Bloomberg, Refinitiv if available/licensed).
   • Multiple Calculation: Calculate EV/Revenue for comps.
4. Output (Frontend): Display the target company's calculated EV/Revenue multiple, along with an explanation of its components. If comparable data is available, present a table or chart comparing the target's multiple to its peers.

4.4 Citation Generation

Ensuring auditability is paramount in FinTech. Every piece of information derived from the 10-K must be traceable.

Mechanism:

1. Prompt Engineering: As detailed in Section 5, all Gemini prompts will explicitly instruct the model to cite its sources from the provided context chunks.
2. Chunk Metadata: Each text chunk stored in the Vector DB must include document_id, chunk_index, page_number_start, page_number_end, and potentially section_heading.
3. Response Parsing: The backend RAG orchestrator will specifically look for citation patterns in Gemini's response (e.g., "[Page X]", "(Source: Page Y-Z)").
4. Linking to Original: Once a citation is identified, the system will link it back to the exact chunk_id (or range of chunk_ids) and thus to the original page_number_start/end in the source PDF.
5. Frontend Display: When an answer is displayed, citations will appear as clickable links. Clicking a citation will:
   • Scroll the embedded PDF viewer to the relevant page.
   • Optionally highlight the specific text snippet within the PDF (requires advanced PDF viewer capabilities or overlaying text).
   • Display the raw text of the cited chunk in a sidebar or tooltip.

4.5 PDF Report Export

Users need to consolidate their analysis into professional, shareable reports.

Workflow:

1. Content Aggregation (Frontend): The frontend gathers all relevant data and rendered components:
   • Executive summary (AI-generated).
   • Key extracted financials (tables).
   • DCF model outputs (tables and Recharts visualizations).
   • Revenue multiple analysis.
   • Log of Q&A interactions with Gemini (questions and AI answers with citations).
   • Assumptions used in models.
2. Export Request (Backend API): The frontend sends a request to a dedicated backend API endpoint (e.g., /api/export-report), passing all the aggregated data and chosen report sections.
3. Server-Side PDF Generation:
   • The backend uses a PDF generation library. Options include:
     • puppeteer (Node.js): Renders a structured HTML template (populated with the aggregated data) to a PDF. This offers excellent control over styling and layout.
     • jsPDF / pdf-lib (Node.js): Programmatically creates PDFs. More granular control but potentially more complex for rich layouts.
     • ReportLab (Python): If a Python microservice is used for reporting, ReportLab is a powerful option for generating complex PDFs.
   • The generated PDF will adhere to a clean, professional template with company branding, consistent fonts, and clear data presentation.
4. GCS Storage & User Download: The generated PDF is uploaded to Google Cloud Storage. The backend then returns a temporary, signed GCS URL to the frontend, allowing the user to download the report directly. Generated reports could also be stored persistently under the user's account in GCS.

5. Gemini Prompting Strategy

Effective prompting is the linchpin of DAT's intelligence. Our strategy focuses on clarity, context, constraint, and citation.

Core Principles for All Prompts:

1. System Persona: Define Gemini's role clearly.
   • System: "You are an expert financial analyst and a highly skilled document interpreter. Your primary goal is to provide precise, factual, and auditable information *only* from the context provided. Avoid speculation or external knowledge."
2. Context Injection: Always include the relevant retrieved document chunks.
   • Context: [Retrieved text chunks, clearly labeled with page numbers and sections]
3. Output Format Specification: Guide Gemini to produce structured or easily parseable outputs.
   • "Provide the exact numerical value.", "List items as a bulleted list.", "Output in JSON format with keys 'figure' and 'citation'."
4. Constraint & Guardrails: Explicitly tell Gemini what not to do.
   • "If the information is not explicitly present in the provided context, state 'Information not found in document.'"
   • "Do not provide investment advice or make forward-looking statements beyond what is explicitly stated in the document."
5. Citation Demand: Mandate the inclusion of source citations for every extracted fact.
   • "Always cite the source by referring to the page number or section from the provided chunks (e.g., 'Source: Page X', 'As per section Y on Page Z')."

Prompt Examples for Core Features:

• Information Extraction (e.g., Revenue):

  System: You are an expert financial analyst. Your goal is to extract precise numerical information from the provided context. If the information is not explicitly available, state "Information not found in document." Always cite the source by referring to the page number from the context.
  Context:
  --- Page 12 ---
  "Net sales for the fiscal year ended December 31, 2023, were $12.5 billion, compared to $10.2 billion in 2022."
  --- Page 87 (Notes to Consolidated Financial Statements) ---
  "Revenue recognition policies are detailed here..."
  User: What was the 'Net Sales' (or 'Total Revenues') for the fiscal year ended December 31, 2023?
  

  Expected Output: $12.5 billion (Source: Page 12)

• Quantitative Reasoning / Simple Calculation (e.g., Growth Rate):

  System: [Standard system instructions with emphasis on showing calculation steps]
  Context:
  --- Page 12 ---
  "Net sales for the fiscal year ended December 31, 2023, were $12.5 billion, compared to $10.2 billion in 2022 and $8.5 billion in 2021."
  User: Based on the provided context, calculate the year-over-year percentage growth in Net Sales from 2022 to 2023. Show your calculation.
  

  Expected Output: Calculation: ($12.5 billion - $10.2 billion) / $10.2 billion = $2.3 billion / $10.2 billion = 0.22549 or 22.55%. The year-over-year growth in Net Sales from 2022 to 2023 was 22.55% (Source: Page 12).

• Summarization (e.g., Key Risks):

  System: You are an expert financial analyst summarizing key information for an investor. Summarize the critical risks mentioned in the following context. Focus on distinct risks and their potential impact.
  Context:
  --- Page 30 (Risk Factors) ---
  "Our business is subject to intense competition..."
  "Reliance on third-party suppliers..."
  "Impact of regulatory changes..."
  User: Summarize the primary risk factors identified in this document.
  

  Expected Output: (Bulleted list of risks, each with a concise summary, followed by a general citation for the section)

• Assumption Suggestion (DCF):

  System: You are an expert financial analyst providing data-driven suggestions for DCF modeling. Based *only* on the provided context, suggest a reasonable range for the company's long-term EBIT margin. Justify your suggestion with specific references.
  Context: [Financial statements, MD&A sections discussing margins, cost structure, future outlook]
  User: Suggest a reasonable range for the long-term EBIT margin for [Company Name] and explain your rationale.
  

  Expected Output: Based on the past three years' reported EBIT margins of X% (Page Y), Z% (Page A), and B% (Page C), and management's stated focus on cost optimization in the MD&A (Page D), a reasonable long-term EBIT margin range could be 15-18%.

Prompt Chaining for Complex Workflows:

For a DCF, instead of one massive prompt, chain multiple smaller prompts:

1. Extract Financials: "Extract key financials (revenue, COGS, operating expenses, D&A, CapEx) for the last 5 fiscal years in a JSON format."
2. Suggest Growth Rates: "Based on the extracted revenue data and any forward-looking statements in the MD&A, suggest 5-year revenue growth rates (Year1-5, Terminal)."
3. Validate Assumptions: "Given these revenue projections, does the 10-K mention any specific events (e.g., M&A, new product launches) that might significantly alter these assumptions? If so, cite them."

Temperature and Top-P Settings:

• Deterministic Tasks (Extraction, Calculations): Use a low temperature (0.1-0.3) and top_p (0.1-0.5) to encourage precise, factual, and less creative responses.
• Summarization, Qualitative Analysis, Assumption Suggestion: Slightly higher temperature (0.5-0.7) and top_p (0.7-0.9) can allow for more nuanced and comprehensive summaries, while still being grounded in facts.

Safety Settings:

Crucially, configure Gemini's safety settings. While financial documents are not typically "unsafe," it's vital to prevent speculative investment advice or misinterpretations that could lead to financial harm. Adjust filters to allow factual financial discussion while blocking any potentially harmful or misleading generated content.

6. Deployment & Scaling

DAT's deployment and scaling strategy leverages Google Cloud's serverless and managed services for cost-effectiveness, automatic scaling, and reduced operational overhead.

1. Frontend (Next.js):

• Deployment:
  • Vercel: The ideal choice for Next.js applications, offering seamless deployments, automatic scaling, global CDN, and excellent developer experience.
  • Google Cloud Run: Alternatively, containerize the Next.js app and deploy it to Cloud Run. This provides more control within the Google Cloud ecosystem.
• CI/CD: Use GitHub Actions or Google Cloud Build to automate testing, building, and deploying the Next.js application upon code merges to the main branch.

2. Backend (Next.js API Routes / Node.js Service):

• Deployment:
  • Google Cloud Run: Recommended for stateless API services. Cloud Run automatically scales instances up/down based on request load, ensuring high availability and cost efficiency (pay-per-request).
  • Google Kubernetes Engine (GKE): For future versions if a complex microservice architecture emerges requiring fine-grained orchestration and resource management. Not necessary for V1.
• CI/CD: Integrate with GitHub Actions or Cloud Build for automated container builds and deployments to Cloud Run.

3. Data Processing Service (PDF Ingestion):

• Deployment:
  • Google Cloud Functions: For lightweight, short-lived tasks (e.g., parsing simple PDFs, triggering embeddings).
  • Google Cloud Run Jobs: For longer-running, more resource-intensive tasks (e.g., parsing very large 10-Ks, complex chunking, multiple embedding calls). Triggered by Cloud Storage events or Pub/Sub messages.
• Scaling: Both services automatically scale horizontally to handle concurrent PDF uploads, processing multiple documents simultaneously.
• Queueing: Use Google Cloud Pub/Sub to decouple the upload API from the processing service, providing resiliency and buffering against spikes in ingestion volume.

4. Database (PostgreSQL & Vector DB):

• PostgreSQL:
  • Deployment: Google Cloud SQL for PostgreSQL. A fully managed service that handles provisioning, patching, backups, replication, and scaling (vertical scaling, read replicas for read-heavy workloads). This offloads significant operational burden.
  • Scaling: Configure appropriate machine types and storage capacity. Monitor CPU and memory utilization to scale up vertically. For high read loads, provision read replicas.
• Vector Database (e.g., pgvector):
  • Deployment: If using pgvector, scaling is tied to Cloud SQL.
  • Alternative (Managed Vector DB): If using a dedicated service like Pinecone, its managed nature handles scaling automatically based on configured indexes and throughput.

5. Storage (Google Cloud Storage):

• Deployment: GCS is inherently scalable. No specific deployment steps other than creating buckets.
• Scaling: Automatically handles arbitrary amounts of data and request volumes. Choose appropriate storage classes (e.g., Standard for frequently accessed, Coldline/Archive for long-term storage of older documents/reports) and regionality (e.g., multi-regional for high availability and global access, regional for cost optimization and data residency).

6. Observability:

• Logging: Centralize all application and service logs to Google Cloud Logging (Stackdriver Logging). Implement structured logging (JSON format) to easily query and analyze logs for errors, performance issues, and user activity.
• Monitoring: Utilize Google Cloud Monitoring (Stackdriver Monitoring) to track key metrics for all services (CPU, memory, request latency, error rates, Gemini API usage). Set up custom dashboards and alerts for critical thresholds or anomalies (e.g., high error rates, slow response times, excessive token usage).
• Tracing: Implement Google Cloud Trace to get end-to-end visibility of requests across different services (frontend, backend, processing services, database calls, Gemini API). This is invaluable for debugging and identifying performance bottlenecks in a distributed architecture.

7. Security:

• Authentication & Authorization: Use NextAuth.js with strong providers (e.g., Google OAuth, email/password with secure hashing). Implement Role-Based Access Control (RBAC) in the backend to ensure users only access their own documents and permitted features.
• API Key Management: Store all sensitive credentials (Gemini API keys, database credentials) in Google Secret Manager. Never hardcode secrets. Ensure Cloud Run/Functions access Secret Manager securely via IAM roles.
• Network Security: Utilize Google Cloud VPCs, firewalls, and private IP connections (e.g., Cloud Run to Cloud SQL via Serverless VPC Access) to isolate resources and minimize public exposure.
• Data Encryption: GCS encrypts data at rest and in transit by default. Cloud SQL also encrypts data at rest. Ensure all client-server and inter-service communication uses HTTPS/TLS.
• Least Privilege: Configure IAM (Identity and Access Management) roles with the principle of least privilege, granting services and users only the permissions necessary for their functions.

8. Cost Management:

• Gemini API: Monitor token usage closely. Implement rate limiting or usage quotas if necessary.
• Cloud Run/Functions: Leverage their pay-per-request model, but ensure processing logic is efficient to minimize execution time and resource consumption.
• Cloud Storage: Use appropriate storage classes and lifecycle policies to automatically transition older, less-accessed data to cheaper storage tiers.
• Cloud SQL: Right-size instances and consider read replicas only when necessary.
• Budget Alerts: Set up Google Cloud budget alerts to proactively monitor spending and prevent unexpected costs.