youcef3939/evalia

1. Overall shape

EVALIA is a small Next.js App Router application with a single end-to-end product flow: a user submits a pitch deck, the server evaluates it, and the UI displays investor-style feedback. There is no separate backend service; the main application and API live in the same repo.

2. Primary user interface

The frontend is centered in src/app/page.tsx, with shared app scaffolding in src/app/layout.tsx and global styling in src/app/globals.css. This is the presentation layer where users likely upload or paste deck content and see the evaluation result.

3. Server boundary

The main backend entry point is src/app/api/evaluate/route.ts. This route is the architecture boundary between the browser and the evaluation pipeline: it receives input from the UI, performs processing, and returns a structured assessment.

4. Input model

The README says the MVP accepts PDF or structured text. That means the system is designed around two ingestion modes, but both converge into text-based analysis rather than visual deck understanding.

5. Document extraction subsystem

src/lib/pdfExtractor.ts is responsible for converting PDF pitch decks into structured text. This is the first transformation step in the pipeline and acts as the bridge from raw document format to model-readable content.

6. Prompt and rubric subsystem

src/lib/prompts.ts holds the evaluation instructions used to steer the AI. Architecturally, this is important because the product’s behavior is defined less by code logic and more by the rubric: clarity, storytelling, and problem-solution fit.

7. Evaluation orchestration

src/lib/evaluator.ts likely coordinates the actual analysis call, assembling extracted deck text plus the prompt into a request for the LLM provider. The README indicates a prompt-driven reasoning system rather than a trained model, so this library is the core intelligence layer.

8. Data flow through the system

The likely flow is: UI input → API route → PDF extraction (if needed) → evaluation prompt assembly → LLM call → structured report response → UI render. This is the central architecture diagram path.

9. Output shape

The product returns a decision-oriented investor report rather than a generic summary. The key response categories are strengths, weaknesses, risks, and investor insights, aligned to the three evaluation dimensions described in the README.

10. External dependency boundary

The README mentions a Groq API key, so the evaluation layer depends on an external LLM service. That means the system’s core intelligence is network-bound and controlled by environment configuration rather than local ML inference.

11. Deployment/runtime

netlify.toml and public/_redirects indicate the app is intended to be deployed on Netlify. The repo is therefore a serverless-style Next.js deployment, where the API route is packaged as part of the hosting platform rather than a separate server process.

12. Configuration and environment

.env.example and the README’s .env.local instructions show that secrets are managed via environment variables, primarily for the Groq key. This is the main operational dependency needed to run the evaluation pipeline locally.

13. Product constraint that affects architecture

The README explicitly chooses text-based analysis over multimodal understanding. That design choice simplifies the architecture: there is no image, chart, or layout analysis pipeline, only extraction plus prompt-based reasoning.

14. What to draw in an architecture diagram

The main boxes should be: Browser/UI, Next.js API route, PDF extraction, prompt/rubric assembly, Groq LLM service, and structured evaluation response. The key boundary is between the app and the external model API; everything else is internal orchestration.