DRT AI Platform — Codebase Interview Dossier¶
Repository: drt/ai-use-cases (private)
Inspected checkout: repos/ai-use-cases (cloned 2026-07-09)
HEAD: 09411cb (2026-03-17)
Stack: Python 3.13 · FastAPI · Celery · PostgreSQL · Redis · MinIO · LiteLLM · React 19 · Vite · Tailwind v4 · shadcn/ui
Reading order¶
- Evidence Map — what was inspected and confidence levels
- Product & System Overview — what it does and how pieces fit
- Backend Deep Dive — API, Celery pipeline, OCR, factsheet
- Frontend Deep Dive — operator console, polling, viewers
- Data Model & Storage — Postgres entities, MinIO, artifacts
- Infra & Local Ops — Compose, Makefile, env pitfalls
- Security & Safety — auth stubs and court-data risks
- Testing & Quality — pytest coverage and gaps
- Unique Engineering Highlights — interview-worthy work
- Interview Prep — scripts and Q&A
- Risks & Next Steps — unknowns and hardening
Note: Chapter
02-agentic-ai-architectureis omitted. This codebase is a deterministic multi-stage OCR/extraction/factsheet pipeline with structured LLM calls, not an agent loop with tools or planning.
Preview and export¶
From projects/ai-use-cases/:
make serve # MkDocs live preview
make build # Static site → site-dossier/
make consolidate # Single Markdown file
make pdf # PDF via md2pdf (requires install-md2pdf)
Executive summary¶
DRT AI Platform is a document-processing monorepo for Debt Recovery Tribunal workflows. Operators upload PDFs; Celery workers run a chunked OCR → EXTRACTION → MERGE pipeline; results land in Postgres artifacts and MinIO. UC1 Automated Factsheet then runs a three-phase LLM pipeline over one or more documents and returns prefilled fields with field-level provenance.
UC2 (scrutiny) and UC3 (hybrid search over orders/judgments) are planned in plans/ but not implemented in application code. Meilisearch and Qdrant appear in compose-full and settings, but have no call sites in the backend. Auth helpers exist and are unused on routers.
The core engineering bet is a resumable, stage/chunk job model plus a discriminator-driven factsheet that prefers structured extraction over raw OCR when confidence is high.
System map¶
graph TD
classDef default fill:#1e293b,stroke:#38bdf8,stroke-width:2px,color:#f8fafc
classDef highlight fill:#065f46,stroke:#34d399,stroke-width:2px,color:#f0fdf4
classDef warning fill:#78350f,stroke:#fbbf24,stroke-width:2px,color:#fffbeb
UI["React operator console"]:::highlight
API["FastAPI /api/v1"]
PG[("PostgreSQL")]
R["Redis / Celery"]
W["Celery workers"]
S3["MinIO documents/"]
LLM["LiteLLM OCR + extract + factsheet"]
OCR["OCR engines<br/>vlm / sarvam / layout"]
UC1["UC1 factsheet<br/>Phase1→2→3"]
Q["Qdrant / Meili"]:::warning
UI --> API
API --> PG
API --> R
API --> S3
W --> R
W --> PG
W --> S3
W --> OCR
W --> LLM
W --> UC1
Q -.->|"planned, not wired"| W
linkStyle default stroke:#64748b,stroke-width:2px
The API is thin orchestration. Heavy work stays in Celery. Amber nodes are documented or configured but not used by app code.
Diagram index¶
| Diagram | Chapter |
|---|---|
| System map | this page |
| Upload → OCR → extract sequence | 01 |
| Factsheet phase pipeline | 01 / 03 |
| ER model | 05 |
| Local Compose topology | 06 |
Top 10 things to know¶
- Monorepo:
backend/+frontend/+infra/+ richdocs/andplans/. - Only UC1 factsheet is implemented; UC2/UC3 are roadmap.
- Document jobs are first-class: stages, chunks, retries, per-stage re-run APIs.
- OCR is pluggable via
OCR_ENGINE(vlm|sarvam|layout). - Factsheet Phase1 picks discriminators; Phase2 fills sub-models; Phase3 assembles + provenance.
- Postgres holds metadata and JSON artifacts; MinIO holds PDFs.
- JWT/OIDC helpers exist but no router requires auth.
- README diagrams show Qdrant/Meili; no indexing code in this checkout.
- Local Compose maps Postgres to host port 5433;
.env.examplestill says5432. - Vite proxy targets
8888while Makefile API default is8000.
Most impressive engineering¶
- Resumable chunked OCR/extraction job state machine
- Discriminator-driven multi-phase factsheet with provenance
- Entities-first extraction with confidence fallback to full OCR text
- Async SQLAlchemy/LLM bridged into sync Celery via a dedicated event loop
Report coverage¶
| File | Role |
|---|---|
| 00-evidence-map.md | Inspection scope and confidence |
| 01-product-and-system-overview.md | Product and architecture |
| 03-backend-deep-dive.md | API, workers, OCR, UC1 |
| 04-frontend-deep-dive.md | React console |
| 05-data-model-and-storage.md | Schema and storage |
| 06-infra-and-local-ops.md | Local ops |
| 07-security-and-safety.md | Security posture |
| 08-testing-and-quality.md | Tests and quality |
| 09-unique-engineering-highlights.md | Highlights |
| 10-interview-prep.md | Interview scripts |
| 11-open-questions-and-risks.md | Gaps and risks |
Open questions (preview)¶
Auth wiring, search/vector adoption, env naming mismatches (MINIO_* vs S3_*), and production deployment target remain open — see 11.