-
Notifications
You must be signed in to change notification settings - Fork 0
System Architecture
This page describes the high-level architecture of the IBF-SLM Application.
The IBF-SLM Application is a web-based platform built around three core pipelines: data ingestion and validation, reasoning-ready corpus preparation, and model evaluation. A FastAPI backend serves both a browser-facing dashboard and a REST API, backed by a PostgreSQL database.
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β Client Layer β
β Browser Β· REST API consumers β
βββββββββββββββββββββββββββββββββ¬ββββββββββββββββββββββββββββββββββ
β HTTPS
βββββββββββββββββββββββββββββββββΌββββββββββββββββββββββββββββββββββ
β FastAPI Application β
β β
β /auth /dashboard /data /corpus /eval β
β β
β ββββββββββββ βββββββββββββ ββββββββββββββββββββββββββββββ β
β β Auth β β Dashboard β β Core Pipelines β β
β β Router β β Router β β Ingestion Β· Corpus Β· Eval β β
β ββββββββββββ βββββββββββββ ββββββββββββββββββββββββββββββ β
βββββββββββββ¬ββββββββββββββββββββββββββββββββββ¬ββββββββββββββββββββ
β SQLAlchemy (async) β File I/O
βββββββββββββΌββββββββββββ βββββββββββββΌββββββββββββββββββββ
β PostgreSQL DB β β Data Storage β
β β β Raw Β· Annotated Β· Evaluated β
β users β β datasets (JSON / CSV) β
β datasets β βββββββββββββββββββββββββββββββββ
β annotations β
β evaluations β
βββββββββββββββββββββββββ
Users interact via a browser-rendered dashboard (Jinja2 templates) or programmatically via the REST API. Authentication uses httponly JWT cookies; API clients use Bearer tokens.
The FastAPI application is the single entry point. It is structured into routers grouped by domain:
| Router | Responsibility |
|---|---|
auth |
Registration, login, logout, JWT issuance |
dashboard |
Aggregated views, user stats |
data |
Dataset upload, validation, versioning |
corpus |
Annotation management, 5-score classification |
eval |
Model evaluation runs, result storage |
PostgreSQL stores all persistent application state. SQLAlchemy 2 with asyncpg provides async ORM access. Alembic manages schema migrations.
Core tables:
| Table | Description |
|---|---|
users |
Authenticated user accounts |
datasets |
Uploaded raw forecasting datasets |
annotations |
Human and model-generated reasoning annotations |
evaluations |
Stored model evaluation results and scores |
Raw and processed files (JSON, CSV) are stored on the local filesystem or object storage. The pipeline reads from and writes to versioned directories:
data/
βββ raw/ # Ingested source datasets
βββ annotated/ # Corpus after annotation
βββ evaluated/ # Model outputs and scores
Accepts forecast event data (extreme weather reports, impact assessments). Validates schema, deduplicates records, and stores to the datasets table and data/raw/.
Transforms validated records into annotated reasoning examples. Annotators assign a 5-score classification across impact dimensions. Outputs structured JSONL suitable for SLM fine-tuning or evaluation.
Runs registered small language models against the prepared corpus. Scores outputs across predefined metrics and stores results to the evaluations table for comparison in the dashboard.
- Passwords hashed with bcrypt
- Sessions managed via HS256 JWT tokens stored in httponly, SameSite cookies
- Protected routes validate the token on every request; invalid or missing tokens redirect to
/login
| Component | Technology |
|---|---|
| Web framework | FastAPI |
| Database | PostgreSQL 16 |
| ORM | SQLAlchemy 2 (async) |
| DB driver | asyncpg |
| Migrations | Alembic |
| Templating | Jinja2 |
| Auth | bcrypt + python-jose |
| Runtime | Python 3.11+ |
| Container (DB) | Docker Compose |
In production the application runs behind a reverse proxy (e.g. Nginx) with TLS termination. The FastAPI process is managed by a process supervisor (e.g. systemd or Docker). See the Deployment Guide for details.