A PyTorch/FastAPI service for seven-class facial-expression classification on FER-style 48x48 grayscale inputs. The supported production boundary validates uploaded images, loads reviewed state dictionaries, and exposes separate liveness and readiness probes.
Facial expressions do not reliably reveal internal emotional state. This project is for research and demonstration, not medical diagnosis or consequential decisions.
This section is the portfolio audit entry point for Facial-Emotion-Recognition-System. It describes an engineering promotion path; it is not a claim that the repository is already production-authorized.
flowchart LR
Client --> Gateway --> Services[API + workers] --> Events[(Event bus)] --> Store[(State)]
The supported local path should be reproducible from a clean checkout. The inferred stack for this repository is Python/platform services.
python -m venv .venv && source .venv/bin/activate && pip install -r requirements.txt
pytest -qIf the project uses external services, model artifacts, cloud credentials, or private data, start them through documented local fixtures or mocks. Never place secrets or identifiable records in the repository.
| Evidence | Required record |
|---|---|
| Correctness | Test command, commit SHA, runtime, and pass/fail result |
| Performance | Warm-up, sample count, concurrency, median, p95, p99, throughput, and memory |
| Data/model quality | Dataset version, split strategy, leakage controls, calibration, subgroup results, and uncertainty |
| Runtime | Image digest, health-check latency, resource limits, and rollback target |
| Security | Dependency, secret, SAST, container, and SBOM results |
A benchmark number belongs in a versioned artifact tied to a commit and hardware/runtime description. Engineering benchmarks must not be presented as clinical, financial, safety, or model-quality validation without the appropriate domain evidence.
What is production-ready for this repository?
A reproducible build, tested public contract, controlled configuration, observable runtime, documented security boundary, versioned artifacts, and a tested rollback path.
What must remain explicit?
The intended use, excluded use, data/credential handling, model or algorithm limitations, and which metrics are measured versus aspirational.
What should be completed next?
Use the linked production-readiness issue for this repository as the checklist. Resolve missing tests, deployment instructions, observability, supply-chain controls, and release evidence before attaching a production claim.
flowchart LR
U["JPEG / PNG / WebP"] --> V["Bounded validation"]
V --> P["48x48 preprocessing"]
P --> T["PyTorch inference"]
T --> J["Ranked emotion labels"]
W["Read-only versioned weights"] --> T
python -m venv .venv
source .venv/bin/activate # Windows: .venv\Scripts\activate
pip install -e ".[dev]"
pytestRun the API after placing reviewed weights at artifacts/models/emotion_model.pt:
pip install -e .
uvicorn src.api.main:app --host 0.0.0.0 --port 8000
curl http://localhost:8000/health/live
curl http://localhost:8000/health/ready| Metric | Verified value |
|---|---|
| Supported Python | 3.10-3.12 |
| Emotion classes | 7 |
| Input upload limit | 5 MiB default |
| Hardened boundary tests | 19 passing |
| Hardened boundary coverage | 100% branch coverage |
| Validation median latency | 92 microseconds (local) |
| Model accuracy | Pending reproducible evaluation |
| Inference latency/throughput | Pending versioned weights benchmark |
| Security findings | Published by CI |
| Docker image size | Published by CI/build system |
Pull requests run scoped formatting/linting, strict typing, tests and coverage, package/container builds, dependency and static security audits, secret scanning, license inventory, SBOM generation, CodeQL, and a reproducible benchmark. Optional profiles keep dashboard, training, vision, and LLM dependencies out of the minimal API installation.
See the audit before using legacy Streamlit, Kubernetes, Helm, Airflow, Snowflake, MLflow, RAG, or LLM prototypes.