10. Interview Prep Guide¶

2-minute architecture script¶

"DRT AI Platform is a FastAPI and Celery monorepo for tribunal PDFs. Upload stores the file in MinIO and creates a Postgres job. Workers run OCR, structured extraction, and merge as resumable stages with per-chunk status. On top of that, UC1 generates factsheets in three LLM phases and returns fields with provenance. The React console is an operator UI for documents, jobs, and factsheets. Search and auth are designed in docs but not wired in this checkout."

5-minute architecture script¶

Problem: DRT staff need structured data from messy case PDFs for applications and scrutiny.
Shape: Monorepo — React console, FastAPI /api/v1, Celery workers, Postgres, Redis, MinIO.
Pipeline: Chunked OCR → extraction → merge; engines pluggable (vlm / sarvam / layout).
State: Jobs, stages, chunks, artifacts are first-class tables so failures are partial and resumable.
UC1: Phase1 discriminators, Phase2 sub-models with entities-first fallback, Phase3 assemble + provenance.
Honest gaps: No router auth, no Qdrant/Meili usage yet, env/proxy drift in local setup, docs ahead of CI.

Likely system design questions¶

Question	Answer angle
How scale OCR?	More Celery workers; tune chunk size and parallel call caps; isolate GPU/OCR service for layout mode
Why not one LLM call per PDF?	Context limits, cost, partial failure; chunking + merge is more operable
How add UC3 search?	Index merged artifacts into Meili + Qdrant; new query API; keep write path in post-merge hook
Multi-tenant courts?	Not present — would need authz, tenant_id on documents, and storage prefixes

Likely backend questions¶

Celery vs BackgroundTasks / ARQ
Async SQLAlchemy inside sync workers (async_runner)
Idempotent re-run of stages
LiteLLM configuration for local vLLM vs cloud
Why create_all instead of Alembic today

Likely frontend questions¶

Polling strategy with React Query
Provenance UX for trust
Why no auth headers yet
Vite proxy port mismatch debugging

Likely infra / security questions¶

What Compose provides vs what runs on host
S3_* vs MINIO_* and Postgres 5433
CORS * risk
Court-data compliance gaps

STAR-style stories¶

Resumable OCR: Situation — long PDFs failed mid-OCR. Task — avoid full restarts. Action — stage/chunk tables + resume/re-run APIs. Result — operators retry only failed ranges.

Factsheet trust: Situation — clerks distrust LLM prefills. Task — show evidence. Action — provenance model + tooltip UI; confidence fallback path. Result — verifiable fields instead of opaque JSON.

OCR portability: Situation — vendor OCR quality varies. Task — swap engines. Action — OCR_ENGINE factory. Result — same job API, different backends.

Weak spots to acknowledge¶

Unauthenticated APIs
Search/vector advertised but unimplemented
Local env/docs inconsistencies
No CI workflows in repo
No frontend tests

Short answers¶

What was hard? Bridging async LLM/DB code with Celery and designing factsheet phases that stay schema-stable across documents.

What would you improve? Auth + audit first, then Alembic migrations, then wire UC3 indexing, then fix env/proxy drift and add CI.

What are you proud of? Chunk-level job operability and provenance-backed factsheet generation — practical for legal operators, not just a demo chat UI.