V-TEKI Technical Assessment · Study Case 1 Author: Felix Yustian Setiono · Position: AI Solution Engineer Scope: Design + reference scaffold for an AI-powered Document Intelligence platform for an Indonesian financial institution processing ~60,000 customer documents/day.
This repo holds two things:
- The design deliverable (
docs/) — the gradeable submission. It answers every part of Study Case 1 and contains the Executive Summary, architecture and pipeline diagrams, model recommendation, technology stack, risk analysis, and deployment strategy. Rendered to a single PDF viamake pdf→dist/VeriDoc-StudyCase1.pdf. - A runnable reference scaffold (
src/) — a FastAPI service that implements the shape of the pipeline (ingest → classify → extract → validate → fraud-screen → confidence-gate → route to human/auto). OCR/model inference is abstracted behind provider interfaces with deterministic stubs so the control flow, confidence gating, and validation logic run end-to-end without GPUs. This exists to prove the design is buildable, not to ship production weights.
The design doc carries the engineering argument. The code demonstrates the control flow is real.
| Decision | Choice | Why |
|---|---|---|
| OCR strategy | Hybrid, routed per document class — self-hosted PaddleOCR + custom KTP model for ID docs; cloud Document AI or self-hosted VLM for semi-structured docs | Single-vendor is the wrong answer here. KTP is a fixed template (custom wins on cost + residency); bank statements are variable (layout-aware model wins). OJK Reg 11/2022 forces a self-hosted path for residency-bound data. |
| Architecture | Event-driven, queue-decoupled | 60k/day is ~0.7 docs/s average but bursts 10–20× at payday/month-end. A queue absorbs bursts; synchronous OCR would collapse under peak. |
| Extraction | Three tiers — template/MRZ for fixed docs, layout model for semi-structured, schema-constrained VLM for the long tail | Matching the method to document structure beats forcing one model on all 10 types. |
| Trust boundary | Per-field confidence + validation + fraud signals → calibrated gate → HITL | The system's job is not "read the document" — it's "decide whether a human needs to look." Gating is the product. |
| Compliance | UU PDP No. 27/2022 + OJK Reg 11/2022 baked into the architecture, not bolted on | PII minimization, field-level encryption, audit trail, and onshore residency are design inputs, not afterthoughts. |
veridoc/
├── docs/ # ← the deliverable (one file per assessment part)
│ ├── 00-executive-summary.md
│ ├── 01-business-understanding.md # Part 1
│ ├── 02-ocr-pipeline.md # Part 2
│ ├── 03-model-selection.md # Part 3
│ ├── 04-document-classification.md # Part 4
│ ├── 05-information-extraction.md # Part 5
│ ├── 06-human-in-the-loop.md # Part 6
│ ├── 07-performance-measurement.md # Part 7
│ ├── 08-genai-vlm.md # Part 8 (bonus)
│ ├── 09-technology-stack.md
│ ├── 10-risk-analysis.md
│ ├── 11-deployment-strategy.md
│ └── diagrams/ # mermaid sources + rendered SVG
├── src/veridoc/ # reference scaffold (FastAPI)
│ ├── api/ # HTTP surface
│ ├── pipeline/ # orchestrator + stage contracts
│ ├── classification/ # document-type routing
│ ├── extraction/ # tiered extractors + MRZ/NIK parsers
│ ├── validation/ # deterministic field validators
│ ├── fraud/ # forensic + rule-based screening
│ ├── confidence/ # calibrated gating
│ ├── hitl/ # review queue + prioritization
│ └── schemas/ # Pydantic contracts
├── tests/
├── scripts/build_pdf.py # docs → PDF
├── docker-compose.yml # full topology (api, worker, redis, postgres, minio, triton)
└── Makefile
make install # pip install -e ".[dev]"
make test # run the pipeline + validation unit tests
make run # uvicorn — POST a sample doc to /v1/documents
make pdf # render docs/ → dist/VeriDoc-StudyCase1.pdfmake pdf # mermaid → SVG, markdown → HTML → PDF (weasyprint)Reference scaffold is illustrative. Production deployment requires the trained models, the GPU inference tier, and the security controls described in docs/11-deployment-strategy.md and Study Case 2.