Project Info
Inspiration
Biomedical AI starts with high-quality data, but preparing that data is often slow, repetitive, and difficult. Researchers spend countless hours cleaning biosignals, enhancing medical images, selecting preprocessing techniques, validating results, and documenting every step before training a single model. We wanted to build an intelligent assistant that automates this entire workflow while remaining transparent, reproducible, and trustworthy. Instead of replacing domain experts, BioPrep AI accelerates their work by generating validated preprocessing pipelines that can be inspected, tested, and deployed.
What it does
BioPrep AI transforms raw biosensor data into production-ready preprocessing pipelines. Users simply upload a biosignal (EEG, ECG, EMG, etc.) or biomedical image and describe their objective in plain English. The platform then: Audits the input data Detects quality issues automatically Generates a custom preprocessing pipeline using AI Executes the generated code in a secure sandbox Automatically retries if the pipeline fails Computes before-and-after quality metrics Explains the improvements Generates a complete HTML report Produces a Docker-ready deployment package The platform is available through both a command-line interface and an intuitive Streamlit web application.
How we built it
BioPrep AI combines deterministic scientific computing with modern AI. Our stack includes: Python OpenAI-compatible models (Codex/OpenAI API) Streamlit NumPy SciPy OpenCV Pillow PyTest Docker The workflow begins by profiling the uploaded data using deterministic signal processing or computer vision techniques. This profile is passed to an LLM, which generates a preprocessing pipeline constrained by trusted templates. Every generated pipeline is executed inside a sandbox, automatically tested, and repaired if necessary. Finally, quality metrics, reports, and deployment artifacts are generated automatically.
Challenges we ran into
The biggest challenge was making AI-generated code reliable enough for scientific workflows. Instead of trusting generated code directly, we designed a self-healing execution system that validates every generated pipeline. If execution fails, the system retries using the error context before falling back to trusted preprocessing methods. Another challenge was creating a unified architecture capable of handling both biosignals and biomedical images while producing consistent reports and outputs.
Accomplishments we're proud of
Built a unified preprocessing platform for signals and images Automated pipeline generation using AI Implemented self-healing pipeline execution Added automatic quality evaluation with before/after metrics Generated explainable HTML reports Created both a CLI and a modern Streamlit interface Enabled Docker-ready deployment for reproducible research
What we learned
This project reinforced that AI performs best when combined with deterministic validation rather than being trusted blindly. We also learned the importance of explainability and reproducibility in scientific software. Researchers need to understand why preprocessing improves data quality, not just receive cleaned outputs.
What's next
Our roadmap includes: Support for more biosensor modalities Automatic hyperparameter optimization Integration with cloud storage providers Collaboration features for research teams Expanded preprocessing libraries One-click deployment to cloud platforms Integration with downstream machine learning training pipelines
BioPrep-AI
A CLI tool and Streamlit web UI that takes a raw biosensor file (signal or image) plus a plain-English description of the sensor and goal, audits it (deterministic math for signals, vision model + CV fallback for images), then generates, self-tests, and containerizes a custom preprocessing pipeline — with a self-healing retry loop if generated code fails.
Built with Codex & GPT-5.6
Built for OpenAI Build Week 2026, using OpenAI's models in two distinct roles:
Development — Codex was used throughout development to generate and refine project files and code, including scaffolding the CLI structure and generated- pipeline templates, refactoring the sandboxing and self-test generation flow, and sharpening ideas during iteration (tightening error handling, fixing test isolation issues, improving the audit-report generator).
Runtime — GPT-5.6 is supported as one of several interchangeable, OpenAI- compatible LLM providers (see "LLM providers" below). When configured, it is used for interpreting biosensor files during audit (vision-based image analysis, signal reasoning), selecting preprocessing stages based on the sensor description and audit results, and explaining quality-impact metrics in plain language. If no LLM is configured, or a call fails/times out, the tool falls back to deterministic, offline-safe logic automatically.
Requirements
| Requirement | Version |
|---|---|
| Python | 3.11 or higher |
| OS | Windows, macOS, or Linux |
| Disk space | ~50 MB (dependencies) |
| Internet | Only needed for LLM providers (optional) |
Python packages (installed automatically)
Core (always installed):
numpy >= 1.26— array mathscipy >= 1.11— signal processing (bandpass, PSD, Savitzky-Golay)opencv-python-headless >= 4.8— image processingpillow >= 10.0— image I/Otyper >= 0.12— CLI frameworkpytest >= 8.0— test runnerrich >= 13.0— styled terminal output
Optional — LLM support:
openai >= 1.40— enables LLM-powered stage selection and metric annotations
Optional — Web UI:
streamlit >= 1.30— browser-based interface with file upload, preview, and downloads
Optional — file watcher:
watchdog >= 4.0— efficient file change detection for watch mode
Installation (step by step)
1. Clone the repo
git clone https://github.com/KharfiIslam/BioPrep-AI.git
cd BioPrep-AI-main
2. Check your Python version
python --version
# Must show 3.11 or higher
If you don't have Python 3.11+, download it from https://www.python.org/downloads/
3. Install all dependencies
Windows (double-click run.bat):
A launcher menu will appear — pick option 3 to install, then 1 or 2 to run.
Or run from terminal:
# Install everything (core + LLM + web UI):
python -m pip install -e ".[ui,llm]"
# Or install only core (no LLM, no web UI):
python -m pip install -e .
# Or use requirements.txt directly:
python -m pip install -r requirements.txt
4. Generate sample files (optional)
python scripts/make_samples.py
This creates demo files in samples/ (EEG CSV, ECG NPY, lateral-flow JPG).
5. Verify installation
python -m pytest tests/ -v
# Should show all tests passing
How to run
Option A: Launcher script (easiest)
Windows: Double-click run.bat — a menu appears:
============================================
preprocess-ops launcher
============================================
Choose an option:
1) CLI menu (terminal)
2) Web UI (browser)
3) Install / update dependencies
4) Run tests
5) Quit
Enter number (1-5):
Pick 1 for the terminal menu, 2 for the browser UI.
Linux / macOS:
chmod +x run.sh
./run.sh
Option B: CLI menu (interactive)
python -m preprocess_ops
A rich terminal menu guides you through:
- Audit a file
- Generate a pipeline (audit + sandbox + self-heal)
- Full demo (generate → test → build → report)
- Run tests
- Build Dockerfile
- Configure LLM
- Launch web UI
- Quit
Option C: CLI one-shot commands
# Audit a signal file:
python -m preprocess_ops audit samples/eeg_sample.csv \
--describe "3-electrode dry EEG, want it clean for seizure classification"
# Generate a pipeline (offline, no LLM):
python -m preprocess_ops generate samples/eeg_sample.csv \
--describe "dry EEG cleanup" --offline
# Generate with LLM + full report:
python -m preprocess_ops generate samples/lateral_flow_strip.jpg \
--describe "lateral flow strip quantification" --offline
# Run all tests:
python -m preprocess_ops test
# Build Docker image:
python -m preprocess_ops build --run
# Batch process a directory:
python -m preprocess_ops batch samples/ --describe "batch cleanup" --offline
# Watch for file changes:
python -m preprocess_ops watch samples/eeg_sample.csv --poll 2
Option D: Web UI (browser)
python -m streamlit run preprocess_ops/ui/streamlit_app.py
Opens http://localhost:8501 with four pages:
| Page | What it does |
|---|---|
| Home | Overview, feature summary, LLM status |
| Pipeline | Upload file → preview → configure → run → download artifacts |
| LLM Config | Set up provider, API key, model — save for reuse |
| Batch | Upload multiple files, process all at once |
What the tool produces
Every pipeline run creates these files in output/:
| File | Description |
|---|---|
profile.json | Audit results (shape, sampling rate, PSD peaks, lighting, blur, ROI) |
pipeline.py | Generated, inspectable, editable preprocessing script |
cleaned.npy / cleaned.png | Cleaned output (signal or image) |
cleaned.metrics.json | ROI coordinates or intensity metrics (images only) |
quality_comparison.json | Before/after quality deltas with percent changes |
audit_report.html | One-page HTML report bundling everything |
test_generated_pipeline.py | Pytest contract test for the generated pipeline |
test_result.json | Test pass/fail status and pytest output |
generation.json | Pipeline metadata (attempts, fallback status, sandbox transcript) |
Quality metrics
Every run computes before/after quality deltas:
╭──────────── QUALITY IMPACT ────────────╮
│ Noise (raw) 0.412 │
│ Noise (cleaned) 0.087 ▼ 78.9% │
│ Sharpness (raw) 152.7 │
│ Sharpness (clean) 210.3 ▲ 37.7% │
╰─────────────────────────────────────────╯
Metric annotations explain why each metric changed:
- LLM-generated — configured model explains each delta in plain English
- Rule-based — deterministic fallback using a stage-effect knowledge base
- Mixed — LLM explains some metrics, rule-based covers the rest
Audit report
The HTML report bundles everything into a single shareable document:
- Audit summary — modality, profiler, shape, sampling rate / lighting / blur / ROI
- Quality impact — before/after metrics with percent deltas
- Why metrics changed — LLM or rule-based annotations per metric
- Sandbox result — pipeline source, attempts, transcript
- Generated pipeline — full syntax-highlighted code
- Test results — PASSED/FAILED with pytest output
- Artifacts — file paths
Generate it with:
python -m preprocess_ops report --output-dir output/
LLM providers (optional)
Install LLM support:
python -m pip install -e ".[llm]"
| Provider | Setup |
|---|---|
| OpenAI | PREPROCESS_OPS_PROVIDER=openai + OPENAI_API_KEY=... |
| Groq | PREPROCESS_OPS_PROVIDER=groq + GROQ_API_KEY=... |
| OpenRouter | openrouter + key — Kimi, GLM, and many others |
| Kimi / Moonshot | PREPROCESS_OPS_PROVIDER=kimi + API key |
| GLM / Zhipu | PREPROCESS_OPS_PROVIDER=glm + API key |
| DeepSeek | PREPROCESS_OPS_PROVIDER=deepseek + API key |
| Together | together + TOGETHER_API_KEY=... |
| Ollama (local) | PREPROCESS_OPS_PROVIDER=ollama |
| LM Studio (local) | PREPROCESS_OPS_PROVIDER=lmstudio |
| Other | PREPROCESS_OPS_PROVIDER=other + PREPROCESS_OPS_BASE_URL=... |
Configure via CLI menu (option 6), web UI (LLM Config page), or environment variables. Settings can be saved to .preprocess_ops_llm.json for reuse.
CLI reference
| Command | Purpose |
|---|---|
python -m preprocess_ops / menu | Interactive numbered menu |
audit FILE | Write output/profile.json, print audit summary |
generate FILE | Audit + synthesize + sandbox + cleaned data + test + report |
report | Bundle artifacts into audit_report.html |
batch DIR | Process every supported file in a directory |
watch FILE | Re-run on file changes (Ctrl-C to stop) |
test | Run unit tests + generated contract test |
build [--run] | Render Dockerfile, optionally docker build |
web | Launch Streamlit UI |
Common flags: --describe/-d, --sampling-rate/-r, --offline, --output-dir/-o, --run-id, --roi "x,y,w,h", --json, -v/--verbose.
Architecture
User input: file (CSV/NumPy or PNG/JPG) + free-text description
↓
[Modality Dispatcher] — routes by file type
↓ ↓
[Signal Profiler] [Image Profiler]
deterministic (scipy) vision model call
sampling rate, PSD peaks, → on fail/timeout →
amplitude, noise floor CV fallback (OpenCV)
↓ ↓
profile.json (unified schema)
↓
[Pipeline Synthesizer] (any OpenAI-compatible LLM)
constrained stage plan inside fixed class template
↓
[Sandbox Execution + Self-Heal]
run on sample → error/NaN? → retry once → trusted fallback
↓
[Quality Metrics] — before/after noise, RMS, contrast, sharpness
↓
[Metric Annotations] — LLM or rule-based explanations
↓
[Test Generator] → pytest contract test
↓
[Audit Report] → single HTML page
↓
[Containerizer] → Dockerfile
Repo layout
preprocess-ops/
├── run.bat # Windows launcher (double-click)
├── run.sh # Linux/macOS launcher
├── requirements.txt # Dependency list
├── preprocess_ops/ # Python package
│ ├── cli.py # Typer CLI (menu + subcommands)
│ ├── service.py # Shared orchestration (run_pipeline)
│ ├── metrics.py # Before/after quality proxies
│ ├── annotations.py # LLM + rule-based metric explanations
│ ├── report.py # HTML audit report renderer
│ ├── present.py # Rich terminal UI helpers
│ ├── llm.py # OpenAI-compatible LLM client
│ ├── audit/ # Input file profiling
│ ├── filters/ # Trusted preprocessing stages
│ ├── synth/ # Pipeline code generation
│ ├── testgen/ # Contract test generation
│ └── ui/ # Streamlit web UI
│ └── streamlit_app.py # 4-page interface
├── tests/ # Test suite
├── samples/ # Demo input files
├── docker/Dockerfile.template
├── scripts/make_samples.py
├── output/ # Generated artifacts
└── pyproject.toml
Design principles
- Deterministic where precision matters. Signal audit is pure scipy; never LLM-guessed numbers.
- Scaffolded generation. The model chooses stages from a trusted whitelist; method bodies stay inside a fixed class template.
- Self-healing. Sandbox-run every pipeline → one retry with error context → trusted fallback.
- Same contract across modalities. Both profilers emit a shared
profile.jsonshape. - Quantified proof. Every run produces before/after quality metrics with percent deltas.
- Transparent explanations. Metric annotations show source (LLM / rule-based / mixed).
- Provenance by default. HTML report bundles everything into a single shareable document.
Quick troubleshooting
| Problem | Fix |
|---|---|
python not found | Use python3 instead, or add Python to PATH during install |
pip not found | Use python -m pip instead |
ModuleNotFoundError | Run python -m pip install -e ".[ui,llm]" |
| Streamlit won't start | Run python -m pip install streamlit>=1.30 |
| LLM not connecting | Check provider URL and API key, or use --offline |
| Tests fail | Run python -m pip install -e . first to install the package |
Analysis
View
Metric
- 19
- 1
Figures cover GitHub contributors during the hackathon window. A co-authored commit counts in full for each author, so per-member totals add up to more than the whole-team figures.
Technology
- OpenAIIn code
- PythonIn code
- StreamlitIn code
- CSSClaimed
- DockerClaimed
- HTMLClaimed
3 of 6 appear in the indexed code. 3 claimed on Devpost could not be matched to code, which may simply mean the tool leaves no trace in the repository.
AI coding agents
No AI coding agent signals were found in this repository.
Detected from committed agent config files and commit authorship. Absence of a signal is not proof an agent was unused.
Codebase size
Source size
167 KB
Source files
45
Counts recognized source files only; vendored directories, binaries and lockfiles are excluded, so this is smaller than the repository on disk.
Repository
KharfiIslam/BioPrep-AI
54 files · 267 KB · @ e1779d6
Structure
Interface
2 files · 4%Screens, components and styles rendered to the user.
Application logic
38 files · 70%Domain rules, services and shared utilities.
+1 more
Supporting
Layers are inferred from where files sit in the tree, not from reading the code. A project that names its directories unconventionally will read oddly here — open the file browser to check anything the diagram implies.
Languages
- Python88%
- Markdown11%
- Shell1%
Share of indexed source by file size. Binary and vendored files are excluded.
Dependencies
pyproject.toml
pypi · 10- numpy
- opencv-python-headless
- pillow
- pytest
- rich
- scipy
- typer
- +3 more
requirements.txt
pypi · 10- numpy
- openai
- opencv-python-headless
- pillow
- pytest
- rich
- scipy
- streamlit
- typer
- watchdog
Declared in the repository’s manifests at the indexed commit. A declared package is not proof it is used, and runtime dependencies are listed first.
This project’s features have not been analysed yet.
Export this project's context (description, README, evidence, key source files) to chat with an AI agent elsewhere.