How it works — vmodel.eu

The review process

When you upload a PDF, it passes through a multi-agent pipeline. Each agent focuses on one aspect of your requirements specification. The entire process runs on EU-based infrastructure — your document never leaves Europe.

flowchart TB A["📄 Upload PDF"] --> B["🔎 Extract requirements"] B --> C["✅ Structure check"] C --> D["✅ INCOSE rule check"] D --> E["🤖 Quality review"] E --> F["🤖 Coverage check"] F --> G["🤖 Traceability check"] G --> GA["🤖 Alignment check"] GA --> H["⚗ Merge & Score"] H --> I["✉ Email feedback"] style A fill:#1a56db,color:#fff,stroke:#1444a8 style B fill:#7c3aed,color:#fff,stroke:#6d28d9 style C fill:#eff6ff,stroke:#1a56db,color:#1a56db style D fill:#eff6ff,stroke:#1a56db,color:#1a56db style E fill:#f0fdf4,stroke:#059669,color:#059669 style F fill:#f0fdf4,stroke:#059669,color:#059669 style G fill:#f0fdf4,stroke:#059669,color:#059669 style GA fill:#f0fdf4,stroke:#059669,color:#059669 style H fill:#fef3c7,stroke:#f59e0b,color:#92400e style I fill:#059669,color:#fff,stroke:#047857

■ Rule-based (instant) ■ AI model (2-4 min) ■ Extraction ■ Merge

How your PDF is read

Before the review agents run, the system needs to find and extract the requirements section from your PDF. This is harder than it sounds — reports typically contain introductions, methodology, test results, and appendices alongside the actual requirements.

flowchart TB A[PDF upload] --> B[Extract all pages\nas markdown] B --> C[Build section map\nheadings, tables,\nbold titles, keywords] C --> D{Find requirements\npages} D -->|Heading match| E[Heading-based\nextraction] D -->|Table match| F[Table-based\nextraction] D -->|Neither| G[Keyword density\nfallback] E --> H[Confidence\ncheck] F --> H G --> H H -->|Low confidence| I[Bounce back\nwith formatting tips] H -->|High confidence| J[Strip preamble\n& condense tables] J --> K[Detect domain\nML / embedded /\nembedded vision] J --> L[Find problem\nstatement section] K --> M[Requirements text\n+ domain] L --> N[PS text] M --> O[Review pipeline] N --> O N --> P[PS review] style A fill:#1a56db,color:#fff,stroke:#1a56db style I fill:#f59e0b,color:#fff,stroke:#f59e0b style O fill:#059669,color:#fff,stroke:#059669 style P fill:#059669,color:#fff,stroke:#059669

The system scans every page for requirements signals: section headings ("Requirements", "Eisen"), table headers with requirement-related columns, bold headings like "Functional Requirements", and requirement IDs (FR-01, NF1, etc.). It scores each page and selects the best match. It also auto-detects your project domain and finds the problem statement section for separate review.

When it can't confidently find your requirements, it bounces the submission back with formatting tips rather than reviewing the wrong section.

What each agent does

Six specialized agents review your document sequentially. The first two are instant (rule-based), the next four use AI models. After merging, a separate ML model scores your content quality. The rule-based checks also detect redundant requirements by comparing all pairs for content overlap.

sequenceDiagram participant S as User participant W as Web Server participant G as GPU Server S->>W: Upload PDF W->>G: Forward for review rect rgb(239, 246, 255) Note over G: Heuristic agents (~0.1s each) G->>G: Step 1: Structure detection G->>G: Step 2: INCOSE 42-rule checks end rect rgb(240, 253, 244) Note over G: AI agents (~3-5 min total) G->>G: Step 3: Quality review (27B model) G->>G: Step 4: Domain coverage (14B model) G->>G: Step 5: V-model traceability (14B model) G->>G: Step 6: PS alignment (27B model) end G->>G: Merge findings + compute scores G->>G: Content quality (ML model) G->>S: Email with feedback

The six review steps

Step	What it checks	How
1. Structure	Table format, requirement IDs, MoSCoW priorities, measurable thresholds, F/NF split, verification methods	Rule-based (instant)
2. INCOSE rules	Vague terms, escape clauses, subjective language, compound requirements, EARS pattern compliance, redundancy detection, SMART time-bound check, decomposition depth	Rule-based (instant)
3. Quality	13 quality anti-patterns per requirement with SMART labels: ambiguity, untestability, missing context, boilerplate, unrealistic absolutes, no evidence of RE process	AI model (Gemma 27B)
4. Coverage	Missing non-functional requirements for your domain (ML, embedded, embedded vision)	AI model (Phi-4 14B)
5. Traceability	Can each requirement be traced to a test? V-model alignment.	AI model (Phi-4 14B)
6. Alignment	Do your requirements actually address the problem statement? Finds uncovered needs, orphan requirements, and scope mismatches.	AI model (Gemma 27B)
After merge	Content quality: how your writing compares to 122 human-scored specifications	ML classifier

How scoring works

Your overall score is the average of four structure categories. Each category is determined by which structural elements are present in your document — not by the AI's opinion.

flowchart TB subgraph Structure categories C[Completeness\nIDs + priorities +\nthresholds + verification] T[Testability\nMeasurable criteria\npresent?] S[Structure\nTable + IDs +\nF/NF split] K[Consistency\nRealistic priority\ndistribution] end C --> O[Overall\nscore] T --> O S --> O K --> O M[Content quality\nML model comparing\nto best specs] -.-> R[Reported\nseparately] style O fill:#1a56db,color:#fff,stroke:#1a56db style M fill:#f0fdf4,stroke:#059669

The content quality score is computed by a separate machine learning model that compares your requirements text to the best specifications we've reviewed. When it's higher than the overall score, it means your writing is stronger than your structure suggests — improving the format will raise your score.

Why multiple models?

Different tasks need different tools. Using one large model for everything would be slower, less reliable, and more expensive.

Approach	Used for	Why
Rule-based Python regex + heuristics	Structure detection, INCOSE rule checks	Deterministic — same input always gives the same result. Instant (<0.1s). An AI model would be overkill for checking "does this document have a table?"
Gemma 3 27B Large language model (local)	Quality review, PS-requirements alignment	Needs deep understanding of each requirement's meaning, context, and testability. The alignment check requires nuanced semantic matching between problem statement and requirements. The largest model produces the most accurate results.
Phi-4 14B Language model (local)	Coverage gaps, traceability	Focused checklist tasks that don't need the full 27B capacity. Faster to load, freeing GPU time for the quality review.
ML classifier Sentence embeddings + Ridge regression	Content quality score	Compares your text to 122 human-scored specifications using semantic similarity. Not a language model — it reads the overall shape of your document, not individual sentences. Trained on real engineering reports.

The AI models both analyze your requirements and write the feedback text (summary, findings, suggestions, rewrites) in a single pass. There is no separate "writing" model — the analysis and the explanation come from the same model run. A Python merge step then combines the outputs from all agents, computes your scores, and formats the email.

All models run locally on a GPU server in Europe. No data is sent to external AI services.

EARS requirement patterns

The EARS (Easy Approach to Requirements Syntax) patterns are used by Airbus, Bosch, NASA, and Rolls-Royce. We check what percentage of your requirements follow these patterns.

Pattern	Template	Example
Ubiquitous	The <system> shall <response>	The system shall respond within 200 ms
Event-driven	When <trigger>, the <system> shall <response>	When the user presses stop, the system shall halt playback
State-driven	While <condition>, the <system> shall <response>	While in standby, the device shall consume less than 1 W
Optional	Where <feature>, the <system> shall <response>	Where GPS is available, the system shall log position
Unwanted	If <error>, then the <system> shall <response>	If the connection fails, then the system shall retry 3 times
Complex	While <state>, when <trigger>, the <system> shall <response>	While connected, when the user presses stop, the system shall disconnect

Reading your feedback email

Your email follows a three-phase structure based on educational research (Hattie & Timperley, 2007):

flowchart TB subgraph "Phase 1: Feed-up" A["What we look for\nThe criteria your spec\nis measured against"] end subgraph "Phase 2: Feed-back" B["Summary\nOverall assessment"] C["Structure checklist\nWhat is present / missing\nwith explanations"] D["Scores\n5 categories + content quality"] end subgraph "Phase 3: Feed-forward" E["Top 3 improvements\nHighest-priority actions"] F["Improvement suggestions\nPer-requirement findings\nwith fix suggestions"] G["Upload revised version"] end A --> B --> C --> D --> E --> F --> G style A fill:#eff6ff,stroke:#1a56db style G fill:#059669,color:#fff,stroke:#059669

Section	What it tells you	What to do with it
What we look for	The criteria: table structure, IDs, priorities, measurability, testability	Compare your document against these criteria before reading further
Structure checklist	Which structural elements are present or missing, with an explanation of why each matters	Fix the missing elements first — they have the biggest impact on your score
Scores	Overall (average of 4 structure categories) + Content quality (how your writing compares)	If Content is higher than Overall, your writing is good — focus on improving the format
Top 3 improvements	The three highest-impact changes you can make	Start here. These are your next steps.
Improvement suggestions	Per-requirement findings with severity, explanation, suggestion, and standards reference	Work through these after fixing the top 3. Each links to the relevant standard.
Specification profile	EARS syntax %, time-bound %, decomposition depth, redundancy, alignment score, V-model readiness	Background stats showing how your spec compares to best practices. Focus on items at 0%.

Tip: Don't try to fix everything at once. Focus on the top 3 improvements, resubmit, and iterate.

Standards we reference

Findings in your feedback are linked to international requirements engineering standards:

IEEE 29148 — International standard for requirements engineering (ISO/IEC/IEEE 29148:2018)
INCOSE Guide — 42 rules for writing quality requirements
EARS — Easy Approach to Requirements Syntax (Rolls-Royce, 2009)
IREB — International Requirements Engineering Board quality criteria (consistency, non-redundancy, completeness, traceability)
V-model — Systems development model linking requirements to verification