Document Intelligence Subsystem

Context and intent

This document is preparatory material for brainstorming and early architecture alignment.

Primary use case: VMS / vessel vetting and clearance.

Working position for initial ideation: use n8n, but not as the core document-extraction engine.

Proposed hybrid architecture:

                    VMS
             Next.js + Express
                    │
                    ▼
              PostgreSQL
          system of record
                    │
          ┌─────────┴─────────┐
          │                   │
    Document Service        n8n
          │             orchestration
          ▼                   │
   Object Storage             │
   MinIO / S3                 │
          │                   │
          ▼                   ▼
   OCR / PDF parsing ──► AI extraction
          │                   │
          └─────────┬─────────┘
                    ▼
             Validation
                    │
             ┌──────┴──────┐
             ▼             ▼
          Accepted       Review
             │             │
             └──────┬──────┘
                    ▼
              VMS Database

Why this approach?

The problem isn't really "automate some PDF workflows."

It's closer to:

Build a controlled document intelligence subsystem for vessel vetting and compliance.

That distinction is important, especially before drafting the first blueprint.

n8n is excellent at:

• workflow orchestration
• webhooks
• scheduled processing
• calling APIs
• moving documents between systems
• notifications
• human approval workflows
• retry/error handling
• connecting AI/OCR services
• integrating email, storage and databases

But I wouldn't make n8n responsible for:

• your vessel/document data model
• document versioning
• audit history
• extraction schemas
• business rules
• clearance decisions
• permissions
• core transactional logic
• long-term document storage

Those belong in our use case.

Proposed architecture for initial discussion

For the first iteration, I would consider:

The critical architectural principle is:

n8n orchestrates; your VMS owns the data and business rules.

Document extraction boundary

Separate extraction from n8n orchestration.

For example:

                    n8n
                     │
              "process document"
                     │
                     ▼
              Document API
                     │
          ┌──────────┴──────────┐
          ▼                     ▼
     PDF parser              OCR engine
          │                     │
          └──────────┬──────────┘
                     ▼
              Normalized text
                     │
                     ▼
             Classification
                     │
                     ▼
              Extraction model
                     │
                     ▼
             Structured JSON
                     │
                     ▼
                Validator
                     │
              ┌──────┴──────┐
              ▼             ▼
           valid          uncertain
              │             │
              ▼             ▼
             VMS        Review Queue

This gives you something much more valuable than a workflow-only implementation:

A reusable document intelligence API

For example:

POST /documents/{id}/process

could eventually return:

{
  "documentType": "safety_equipment_certificate",
  "confidence": 0.97,
  "fields": {
    "vesselName": {
      "value": "Isola di Lussino",
      "confidence": 0.99
    },
    "imoNumber": {
      "value": "1234567",
      "confidence": 0.99
    },
    "certificateNumber": {
      "value": "SEC-2026-001",
      "confidence": 0.96
    },
    "expiryDate": {
      "value": "2027-04-15",
      "confidence": 0.94
    }
  }
}

And, importantly, retain the evidence:

{
  "field": "expiryDate",
  "value": "2027-04-15",
  "page": 3,
  "sourceText": "...valid until 15 April 2027...",
  "confidence": 0.94
}

For a compliance/vetting system, this is considerably more useful than simply storing extracted JSON.

Keep RAG out of the critical path (for now)

This is an important sequencing decision.

There is a tendency to build:

PDF → embeddings → vector database → chatbot

For your use case, I would initially build:

PDF → OCR → classification → structured extraction → validation → evidence → database

RAG can come later, after structured extraction and validation are reliable.

For example, suppose you upload:

Cargo Ship Safety Equipment Certificate

You don't primarily need a chatbot to answer:

"What does this certificate say?"

You need the system to reliably determine:

Document type
        ↓
Vessel
        ↓
IMO number
        ↓
Certificate number
        ↓
Issuing authority
        ↓
Issue date
        ↓
Expiry date
        ↓
Status
        ↓
Evidence
        ↓
Confidence

That's document intelligence, not primarily RAG.

Where n8n adds the most value

This is where n8n fits the project very well.

Imagine:

Vessel certificate received

Email / Upload
      ↓
     n8n
      ↓
Store original PDF
      ↓
Create Document record
      ↓
Classify document
      ↓
Run extraction
      ↓
Validate
      ↓
 ┌────┴─────┐
 │          │
Valid     Uncertain
 │          │
 ▼          ▼
Update     Review
Vessel     Queue
record
 │
 ▼
Check expiry
 │
 ▼
Notify responsible user

Then scheduled workflows can handle:

Certificate expires in 90 days
Certificate expires in 30 days
Certificate expired
Document missing
Extraction requires review
Vessel clearance blocked
New inspection document received

That's exactly the kind of work n8n is good at.

Alternatives to n8n (as the system matures)

Keep three alternatives in view as scale and requirements evolve.

1. Temporal

If the system eventually becomes very large and workflow execution itself becomes mission-critical, Temporal is worth considering.

It gives you durable workflows, retries, state and strong developer control.

But it is substantially more engineering-heavy.

For the current stage, I would not start with Temporal.

2. BullMQ

If you want something much simpler:

Express
  ↓
BullMQ
  ↓
Redis
  ↓
Workers

This is actually an excellent alternative if your workflows are primarily internal application jobs.

For example:

Document uploaded
       ↓
BullMQ
       ↓
PDF Worker
       ↓
OCR Worker
       ↓
Extraction Worker
       ↓
Validation Worker

The advantage is that everything remains TypeScript and under your control.

The disadvantage is that you have to build much more infrastructure yourself.

3. n8n

For the current stage, I'd choose n8n because it provides significant integration and orchestration capability without requiring a small team to build that layer from scratch.

But I'd put a clean API boundary around it.

Recommended VMS architecture (draft)

Use:

                    ┌─────────────────┐
                    │     Next.js     │
                    │      VMS UI     │
                    └────────┬────────┘
                             │
                             ▼
                    ┌─────────────────┐
                    │     Express     │
                    │   Domain API    │
                    └────────┬────────┘
                             │
              ┌──────────────┼───────────────┐
              ▼              ▼               ▼
        PostgreSQL       Document API     Auth/RBAC
              │              │
              │              ▼
              │         Object Storage
              │              │
              │              ▼
              │       Document Processor
              │              │
              │       ┌──────┴──────┐
              │       ▼             ▼
              │      OCR        PDF parser
              │       └──────┬──────┘
              │              ▼
              │       AI extraction
              │              │
              │              ▼
              │          Validation
              │              │
              └──────────────┤
                             ▼
                        Document DB
                             ▲
                             │
                           n8n
                    orchestration layer

Define four concepts explicitly

1. Original document

Immutable PDF/image stored in object storage.

2. Extracted document

Machine-readable representation.

3. Evidence

Where each extracted value came from.

4. Verified data

The value actually accepted by the VMS.

That last distinction is extremely important.

OCR/AI result ≠ VMS truth

Instead:

Original
   ↓
Extraction
   ↓
Validation
   ↓
Human verification where necessary
   ↓
VMS truth

That gives you an auditable chain, which is central for vetting and compliance use cases.

Bottom line

Working recommendation for brainstorming: proceed with n8n as orchestration.

But I would position it as:

the automation/orchestration layer of your Vessel Document Intelligence subsystem, not the subsystem itself.

Given your existing Next.js + Express + PostgreSQL + Prisma + self-hosted Hostinger/Dokploy architecture, I think this is a particularly natural fit.

This recommendation is intended to guide initial ideas, not lock final implementation decisions.

Choosing an OCR/Document Understanding Engine

The next architectural question is which OCR/document-understanding engine to place behind n8n. For vessel certificates and inspection documents, compare Mistral OCR, Azure Document Intelligence, Google Document AI, AWS Textract, and a self-hosted OCR/vision stack on extraction quality, tables, scan robustness, handwriting support, cost, privacy, and self-hosting fit.

For the brainstorming session, capture assumptions and open questions explicitly:

• What minimum extraction accuracy is acceptable by document type?
• Which fields require mandatory human verification regardless of confidence?
• What privacy and data residency constraints limit vendor options?
• What throughput and latency targets define MVP success?
• At what scale would we reconsider n8n in favor of Temporal or BullMQ?
• How will we handle updates or corrections to previously extracted documents?
• How will we ensure the auditable chain remains intact after corrections?
• How will we handle conflicts between human verification and automated extraction?